Re: [Chicken-users] Namespace issues in SXML

[Peter Bex]

On Mon, Mar 25, 2013 at 01:58:48PM -0600, Matt Gushee wrote:
> SXML itself is clearly a good thing, and the tools
> seem to work very well. And yet, looking at the APIs, there are these
> maddening inconsistencies, and even looking at each egg in isolation
> ... for example, what's up with the name 'SRV:send-reply'. How does
> that relate to anything? So I'm wondering if it wouldn't be a good
> idea at some point for those who work with sxml-tools and its
> descendants to get together and design a more unified and usable
> API(s).

Hi Matt!

Glad you're suggesting this.  The idea of rewriting/polishing SSAX
has been idly raised in #chicken a few times.  I think we all (that is,
from the Chicken side of things) agree that the SXML tools really need
an update, but nobody has enough time to put in the massive effort this
would require.  And, speaking for myself only, I don't have nearly
enough knowledge of the underlying XML technology to approach this task
on my own.

I haven't yet asked this on the official SSAX mailinglist because it
would be rude to suggest improvements without willing to put in time
and effort to at least help out.  At least I've raised a few concerns
about the confusing multitude of APIs (there are at least 3 different
APIs for doing SXML transformations in the SSAX tree), but this was
seen as an advantage; each API has its own strong points.

I think with the R7RS module system, the awkward API could be mostly
simplified and the weird prefixes dropped.  Then, for example, each
alternative sxml-transformation implementation could be a different
module implementing the same API.  Switching would simply be a matter
of changing the imported module.  This would require proper
modularisation, though.  Currently the SSAX project is a sprawling set
of files which are very tightly coupled.  We've tried to untangle these
as much as possible, which is why we have several eggs rather than one
"SSAX kitchen sink" egg.  However, we've also gotten some criticism for
doing so.

By the way, there's also some inconsistency as to how auxiliary
information is stored.  At one point the spec defined an "aux-list" to
be (@@ (X Y)), and later it was generalized a little to (@ (@ (X Y))).
However, some of the tools still only accept the earlier notation.
Also, none of the tools consistently produce or even consume "*parent*"
pointers, which could make things even more powerful and on par with
the "official" DOM spec from the W3C (but this would require a
post-processing step after the SXML is generated from quoted list input).

Finally, some of the SSAX assume support for an arbitrary count of
arguments in the host Scheme system.  We've had to do some surgery
in a few places to remove these limitations (Chicken, as you probably
know, supports only a guaranteed number of 128 arguments with plain C,
and 1024 (IIRC) with the optional assembly "manyargs" apply-hack).

Unfortunately, the main sxml-transforms API itself is written with this
limitation to the core, rules accepting varargs bound to a node's
contents, which limits the size of XML documents Chicken SSAX code
can handle.  We've provided additional variants (ending with a *)
which implement a slightly modified API that passes the node contents
in a list.  All these things make for a very weird, nonstandard SSAX
implementation in Chicken and makes it hard to share code.

I've never really needed namespaces much, but you're right, some
of the APIs don't even deal with namespaces *at all*, like sxml-modif
one, as I found out when writing a blog post about the SXML design, at
http://more-magic.net/posts/lispy-dsl-sxml.html
Others just don't handle them consistently.  All this is a consequence
of them being an afterthought.  A clean solution should be found for
this, because the current approach of just sticking a namespace prefix
onto the symbol doesn't scale, and is hard to deal with programmatically.

The above things are the minimum of things to be addressed in a
reimplementation/"SSAX improved".

> I know sxml-fu is intended to address that need, but it seems
> kind of ad-hoc and limited scope. Just a thought.

Actually, it isn't really.  It only aims to provide a few convenience
procedures.  It's also mostly dead, because the API is, as you pointed
out, rather ad-hoc and messy, and too special-purpose to be of any
real use.

Cheers,
Peter
-- 
http://www.more-magic.net