--- Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > I sent a pointer to the SiXDML language since they > were talking about an > SQL-like query language and thought they might not > be aware of it.
Cool. Please let me know what how the it is received because I'm always looking for feedback about SiXDML. > I dare to disagree. XSLT was designed to be a > transformer of SAX events > (events flow in, they get changed depending on the > stylesheet > information, events flow out). XQuery was designed > to be a generator of > SAX events (the query comes in, the events flow > out). > > Sure, XSLT can be made to act as a generator and > XQuery can be made to > act as a transformer, but both appear hacks to me > and go right against > the need for two different things, one for > transformation and one for > generation. As someone who's day job requires working intimately with XQuery and the W3C folks designing it, I can say that the only distinction that I really see between XQuery and XSLT is syntactic. Considering that XSLT 2.0 will use XPath 2.0 which is _currently_ just XQuery - let & where expressions - query prolog (schema importation, func definitions, namespace decls) + reverse & namespace axes - element construction - sorting ,I think that the distinction grows more and more hazy. > I think the 'select' statement should have the > ability to use XQuery > right inside the 'select' statement, not as a > post-process facility, > which is the place for XSLT. > > XPath, can be used as a simplified version of XQuery > inside the select > statement. As standards mature, I fully expect for the next iteration of SiXDML to leverage XPath 2.0, however my goal was to create a simple, understandable language and I think adding XQuery to the mix may defeat that purpose. However, my research paper does describe how to augment XQuery to be more SiXDML-like which I'm sure will be an interesting perspective to some. > > However with the advent of XPath 2.0 which > currently > > looks like it will be a large subset of XQuery > then > > the need to create such layering of query engines > will > > be unnecessary. > > Yes XPath 2.0 will simplify layering of all those > things. Agreed. This is what I'll shoot for in the next iteration of SiXDML. However, I do have some concerns about how complex XPath 2.0 is becoming which were shared by many on XML-DEV[0] > > Piping query results to XSLT and other query > engines > > may be expensive performance wise since the way I > > originally conceived it involves obtaining all the > > results from the XPath query then passing those to > the > > XSLT or other engine and in fact that's how it is > > currently implemented in the reference > implementation. > > Yes, this is my concern entirely and also shows some > architectural > problems that IMO originate from the very design of > the SiXDML language. The entire purpose of the having the layered framework was to get around the lack of transformation/complex querying in XPath. This may no longer be the case if XPath 2.0 or as you suggested XQuery is used as the query language in a SELECT statement. [0] http://lists.xml.org/archives/xml-dev/200205/threads.html ===== THINGS TO DO IF I BECOME AN EVIL OVERLORD #79 If my doomsday device happens to come with a reverse switch, as soon as it has been employed it will be melted down and made into limited-edition commemorative coins. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
