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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format