Re: A beef with XSLT Sometimes too complicated

> That depends upon your definition of right.
> A SAX parser is less portable.

yes and no, you need _something_ to parse the Xquery and that's got to be
written  in something. In the case of xq2xml that something is a bunch
of java supplied by the WGs (esp Scott Boag). which has (at my
suggestion) the option of outputting the tree as a string (or file)
with the XML markup of an XML view of XQuery.  Since it's java anyway it
could (except I'd have to write it) output sax events instead and save
the following step of getting a java xml parser to parse the xml.

If I wanted to move this all to .net or Eiffel or something then
the hard part of making the xquery parser would still have to be ported
whether or not the output was an xml document or some API that made it
look like a native XML parser on that platform.

In any case I think that the version that goes by way of an explict XML
document should be the one specified (and probably also implemented)
as that is the one most amenable to specification and verification.
It's just that on any given platform it probably makes sense to skip
that step and go straight from the text being parsed straight to an XML
API without serialising an explict XML document.

Of course this applies (or does not apply) for any non-xml text that it
is being parsed, whether it be XQuery (my xq2xml), html (John Cowan's
tag soup), gedcom (Mike's example in his book) etc.

David