Subject: [xsl] XQuery (was Designs for XSLT functions) From: "Evan Lenz" <elenz@xxxxxxxxxxx> Date: Tue, 20 Feb 2001 11:57:34 -0800 |
Jeni Tennison wrote: > > I must admit to being completely confused by XQuery. It seems like > > reinventing XSLT but without XML syntax for programming constructs > > (admittedly a fair step to take). I thought that it might be that > > XQueries are for building XML from things other than XML, but the > > XPath-like syntax seems to imply that the source (e.g. database) is > > accessed as a node tree anyway. I feel sure that I must be missing > > something. Michael Kay replied: > I think XQuery and XSLT/XPath are on convergent paths: they are > tackling the > same problems, and if each follows its natural course they will > end up with > broadly equivalent functionality. But they are coming from different > traditions, and as a result they currently have different strengths and > weaknesses, as well as different syntactic appearance. What a delightfully neutral-sounding paragraph, so matter-of-fact! :) The question in my mind is: should the W3C recommend two different languages which provide "broadly equivalent functionality"? And they're not just equivalent, but they have almost indistinguishable data models and processing models. And I think once they come up with an XML syntax, it will be even harder to look at XQuery with a straight face, with XSLT 1.0 having been published for well over a year. What's more is that it seems that the XPath 2.0 and XSLT 2.0 requirements are trying to fill the gap with regard to whatever slight differences there currently are between XSLT and XQuery. My simplistic analysis is that XQuery = XSLT - templateRules - nonAbbreviatedXPathAxes Regarding XQuery and XPath, David Rosenborg wrote: "In my opinion they have obfuscated XPath. Instead of describing the XQuery language as an extended subset of XSLT/XPath they went inventing their own syntax and semantics which are similar but not compatible with XSLT/XPath." I completely agree with this sentiment. "Ordered forests" instead of unordered node-sets, etc. etc. And new extensions that IMHO reflect a lack of understanding of XPath, such as: empty($node-set) instead of not($node-set) @mgr->* instead of id(@mgr) chapter[RANGE 2 TO 5] instead of chapter[position() >= 2 and position() <= 5] And XQuery's allowance for defining a default namespace for XPath expressions is pure evil. And I was hurt by the distinction between "a human-readable query syntax and an XML-based query syntax". I could go on (and will at XSLT-UK, but that will hopefully be more than a mere rant). The areas where XQuery arguably introduces new functionality are matters of convenience. While possible in XSLT, they are easier to specify in XQuery. Each of these areas, with a possible exception of the BEFORE and AFTER operators, are currently addressed in the XPath and/or XSLT 2.0 requirements (grouping, intersection, etc.) In my opinion, XSLT and XQuery, if they don't end up being the same thing, should at least build from a common semantic and syntactic base. And I don't mean the "abbreviated syntax of XPath," which is basically the extent of the explanation of XQuery's relationship to XPath. So, no, Jeni, you're not missing something. Evan Lenz XYZFind Corp. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Designs for XSLT functions (Was, Michael Kay | Thread | Re: [xsl] XQuery (was Designs for X, Francis Norton |
Re: Designs for XSLT functions (Was, David . Rosenborg | Date | [xsl] Re: Re: Designs for XSLT func, Dimitre Novatchev |
Month |