Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XQuery - The truth comes out!
 Jonathan Robie wrote: > This reformulation is helpful for me - I think I understand > better what you > are saying. I think that XSLT and XQuery can and should share: > > 1. A common data model > 2. An algebra that defines operations on that model, and which > defines the > static type of the result (as far as possible). > 3. A common path expression language - basically the stuff that > is in XPath > 1.0. We may be getting somewhere here. What you've stated above goes a lot further than what I've seen you or the Query WG say before (and I recognize you're voicing only your own thoughts here). If XSLT down-reference pull and XQuery minus the parent axis end up sharing a common algebra as well as data model, then shouldn't they simply be defined as different syntaxes for the same thing? > I do not think that XQuery should attempt to do everything XSLT > does and in the same way. So far, the only real thing that I've seen that might truly benefit XQuery over XSLT in terms of implementation and optimizability techniques would be if XQuery supported only a down-reference path language. Note also that, if XQuery dispenses with the parent axis, the algorithmic convertability of XSLT template rules to XQuery queries would be lost (the parent axis is necessary for match pattern evaluation). Despite my affinity for template rules, I'm perfectly willing to grant that such a move might be necessary. Also, despite my being comfortable with XSLT's syntax (for the most part), I am starting to see the demand and hence need for a different syntax, such as an SQL-like syntax. I believe that another syntax could be created for XSLT down-reference pull, and the similarity between XSLT and XQuery would become even more apparent. (Paul Tchistopolskii's work on XSLScript might be leveraged here.) Many people have had trouble learning XSLT, due to the difficulty of figuring out how template rules work. By taking template rules (push) out of the equation, XSLT would be *much* easier to learn (as well as a great deal less powerful). I'm, of course, not proposing that template rules be removed from XSLT. Instead, I'm suggesting that XSLT minus template rules, or down-reference pull, i.e. an XSLT subset, be formally defined, without regard to syntax, or with regard to two syntaxes, the XSLT syntax and the XQuery syntax. This may slightly disrupt the current XQuery model, but not by much at all. *That* is the primary point I've been trying to make. (BTW, the XSLT syntax for down-reference pull is already defined in a self-enclosed way as "Stylesheet as Literal Result Element"). XSLT 1.1 is well on its way to closing the gap between the two languages regarding composability. The XPath 2.0 requirements are well on their way to closing the gap between the two languages regarding datatypes. And the user requirements among the XSLT community for a function definition mechanism (more powerful than named templates, recursive or not) are becoming clear, as is shown by current activity on the XSL-List. In fact, we've already seen implementations of this, such as extensions like saxon:function. > Even if XSLT is algorithmically convertible to XQuery and > vice versa (which may or may not be true, we haven't worked > through all the > details, and that would take some time), we still might not know the > algorithms to do this for all cases, or we might not know algorithms that > produce a result that would execute efficiently, or we might know > the best > available algorithms and still find that the resulting queries are slow > simply because XSLT is optimized for template processing and XQuery > implementations probably will not be. Believe it or not, I agree with all of the above, as long as you're talking about template rules. But in the case of XSLT down-reference pull, on the other hand, that translation should be trivial. My agreement with you here doesn't detract from the primary point I've been trying to make. > Look, we're trying to define a query language, we are not trying to > replace XSLT. If we require ourselves to take on this task, we'll > never finish our query language. This is not the problem we need to > solve. On the contrary, this is the problem that you needed to solve, and that you apparently did not realize was the problem you needed to solve. Why? Because XSLT is a query language. How is that? Among all of the XML Query Requirements use case examples, I haven't seen one that would be inappropriate for XSLT, especially when considering the convenient features that will be added in future versions of XSLT. > XQuery is not that large a language. By that standard, neither is XSLT. The perception that XSLT is a larger language than XQuery really is a skewed one, particularly if you take template rules away. Jonathan, I'm learning a great deal from this discussion, and I very much appreciate your willingness to not only participate, but your open-mindedness in doing so. Evan Lenz XYZFind Corp. Disclaimer: Opinions expressed here are mine and mine alone, not necessarily those of XYZFind. 
|
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
|
|||||||||
