[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XQuery - The truth comes out!
At 08:33 PM 2/24/2001 -0800, Evan Lenz wrote: >On Sat, 24 Feb 2001, Jonathan Robie wrote: > >At 03:20 PM 2/24/2001 -0800, Evan Lenz wrote: > > > >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? > >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. [ !! SNIP !! ] > 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". [ !! SNIP !!] If there is an equivalent (same meaning) >XQuery for every XSLT stylesheet, then this argument does not hold much >water. 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. I do not think that XQuery should attempt to do everything XSLT does and in the same way. 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. >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. Many of them are. Many of them are not. An exercise for the reader: take Norm Walsh's DOCBOOK stylesheet in XSLT, rewrite it in XQuery, and write a Python script that can automate this conversion. We can then try applying that to some other stylesheets and see how well it works. 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. > 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. XQuery is not that large a language. There is a lot of interest in making our XML construction look just like XML. The XPath 2.0 requirements (http://www.w3.org/TR/xpath20req) hint that some of what XQuery does now could be taken up into XPath, if we can find a good way to do this that works for both languages. How much? Well, that depends on a lot of answers to a lot of questions we are just now starting to ask. >The provocative nature of my subject line was mostly to get a >rise out of you, Jonathan -- jk ;-) Well, I think you succeeded. But I wonder if we are really saying anything new in the last few emails. Are we reaching the point that both of our positions are clear? Jonathan
|
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
|