Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XQuery - The truth comes out!
 Hi Jonathan, On Sat, 24 Feb 2001, Jonathan Robie wrote: >At 03:20 PM 2/24/2001 -0800, Evan Lenz wrote: > >Take the following observations, each of which either has been > >demonstrated by Joe English or me on this list, or has been proclaimed > >as the official position of the W3C XML Query and XSL WGs: > > Well, by my tally you quote yourself three times and quote Joe English > once, coming to different conclusions than I believe Joe would for his > quote. I don't know which official positions you feel you have heard > from either Working Group, I certainly hope that you are aware none have > been expressed on XML-Dev during this discussion. I'm sorry if this statement was misleading. What I should have said is #1-3 have been demonstrated on this list. #4 is an offical position of the XML Query and XSL WGs. And, yes, I recognize that you and others from the WG that might be participating in this discussion are expressing their own opinions and not necessarily those of the WG. > > >1. Template rules are a sophisticated form of syntax sugar and can be > >expressed as an XQuery function - > >http://lists.xml.org/archives/xml-dev/200102/msg00585.html > > Well, yes, you said this. But do you know the difference between syntactic > sugar and a processing model? The fact that a recursive XQuery function > that iterates over all the nodes in a document can compute the same result > as XSLT templates does not mean that an XQuery implementation is going to > be optimized for that, or that the two languages use the same processing > model. The clearly do not. Or do you believe that Lisp and SQL have the > same processing model? It's not about computing the same results. It's about *expressing the same meaning*. Two queries that express the same meaning will, of course, always compute the same results. And, of course, there are many queries which express different meanings, use a different processing model, etc., but only *happen* to compute the same result. My assertion regarding #1 (as well as #2), is that there are equivalent XQuery queries that not only compute the same results, but express the same meaning. What I mean by "express the same meaning" could probably be defined as "algorithmically convertible from one to the other at compile-time". All the arguments I've heard about the optimization problems of XSLT are regarding compile-time analysis. If there is an equivalent (same meaning) XQuery for every XSLT stylesheet, then this argument does not hold much water. Of course, I make a bigger claim as well, that not only is virtually any XSLT query algorithmically convertible to XQuery at compile-time, but that many of them, in particular those that only use "down-reference pull" are not only trivial to convert, but the conversion is obvious to the user. An example may be helpful. A series of IF THEN statements in a recursive FUNCTION definition certainly does not look like the same sort of thing as a set of template rules. This conversion, though determinate, is not obvious to the user. Likewise, but to a lesser extent, the conversion of ancestor::foo to a recursive ancestor() FUNCTION definition a la Joe English's demonstration, is not an obvious conversion either. But the conversion of xsl:for-each, xsl:variable, xsl:copy-of, etc. is not only algorithmically convertible to an equivalent XQuery query, but that conversion is also obvious to the user. These queries not only have the same meaning with respect to my definition of "same meaning" above, but they also have the same meaning with respect to syntax appearance, etc. This, of course, uses a more subjective and relative definition of "same meaning", insofar as not all users are the same. The exclusion of template rules and the other XPath axes from XQuery would provide a deterrent from expressing certain kinds of queries, but not a preclusion from the possibility of expressing those kinds of queries, even if the language is not particularly optimized for them. That's the primary point I'm making, and that's why I called it a "sophisticated form of syntax sugar". > > >3. XSLT 1.1 introduces composability by making arbitrarily constructed > >trees first-class citizens - > >http://lists.xml.org/archives/xml-dev/200102/msg00587.html > > Well, I think this demonstrates that you did not understand what Michael > Rys meant by compositionality. My understanding is that compositionality, or composability, refers to the central importance of *expressions* and that expressions can be composed into other expressions, which can in turn be composed into other expressions, etc. Michael Rys correctly pointed out that there is an issue of syntax with regard to XSLT's being made composable. Whereas in XQuery you may simply put parentheses around a FLWR expression and access it as an expression, in XSLT 1.1 you have to basically give the expression a name (using xsl:variable) before you can syntactically use it. I don't believe the important thing about composability is how many characters you have to wrap around what's considered to be an expression, but rather what objects you can and can't access as an expression. Is this not a correct understanding? I don't presume to know what Joe English's conclusions are, but he also made this observation, in a separate post: http://lists.xml.org/archives/xml-dev/200102/msg00519.html > > Or does your statement about subsets mean that they should share a common > expression language, XPath 2.0, as we are already doing? If so, I agree > with you. No, I think that the subset used by XSLT and XQuery (assuming one must have features the other doesn't have) should extend beyond the path expression language (which will have the same syntax) into the result construction language (which may have different syntaxes). This result construction language, the flow control, the iteration, the conditional statements--these should all have the same meaning and should be defined in terms of each other. I haven't yet seen a good reason why they should not. XSLT currently lacks a bunch of XQuery features, yet these are almost entirely related to XML Schema datatypes. The XSLT 2.0 and XPath 2.0 requirements working drafts indicate that XSLT will support these datatypes as well, thus closing that particular gap. I am happy that XPath 2.0 will be common to XSLT and XQuery. I think this is a good good thing, but it just doesn't go far enough. Despite the sometimes alarmist ring to my postings, I have hope that the commonality will in fact go further, as issues between the two WGs are resolved with regard to their common use of XPath 2.0. I think a good deal of XQuery's subtle differences from XSLT lie in the fact that the semantics of its path expression language are decidedly different from those of XPath 1.0. Once XQuery and XSLT share a common path expression language, the reasons for defining at least most of the rest of the two languages in the same terms will be even more compelling. In this scenario, XSLT's syntax, or a large portion of XSLT's syntax (such as what can go in one template rule), could be used as the XML syntax for XQuery. This syntax could be used, as long as it *means* the same thing as the XQuery "human-readable" syntax. > > >All of the work done by the Query WG on algebra and query optimization can > >be leveraged and applied to XSLT as well as XQuery. > > Certainly much of it can be - but I thought you were taking us to task for > creating our own algebra and data model. Are you now suggesting that XSLT > should be defined in terms of the Query algebra? By the "work done" on the XML Query algebra, which is still a working draft, I mean to indicate the research and the query optimization principles that have been learned and are being learned. Insofar as the algebra was created without considering the semantics of XSLT, which has the same basic requirements as a query language, I indeed would be critical. But I don't presume to know to what extent XSLT was "consulted". What I'm saying is that if XQuery is any representation of that algebra, then it turns out that, whether XSLT was consulted or not, it came darn close to the semantics of XSLT and what XSLT (1.1, 2.0) is becoming. To that extent, there should be no reason why these principles can't be utilized in XSLT implementations over large data sets. > Evan, I am impressed by the instantaneous nature of your conclusions Apart from a summary of what I am learning in this debate, and a slightly modified restatement of my original opinions, my posting didn't contain much new. The provocative nature of my subject line was mostly to get a rise out of you, Jonathan -- jk ;-) Best regards, Evan 
|
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
|
|||||||||
