Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 07:35 AM 2/26/2001 -0700, Uche Ogbuji wrote: > > IMHO, the current XQuery spec. tries to much: it wants to select > > _and_ transform, although selection would be enough. If I like to > > transform the query results I use XSLT. This way XSLT and XQuery > > would have a clear scope: One for transformation and the other for > > selection. > >This is, I think, an important take on the discussion. I think most of >the pro-XQuery arguments (excepting the syntactical arguments, which I >think are s much less important) point to efficiency of selection. > >So would there be anyproblem with making XQuery a super-selector for XSLT? >That way the result-tree mechanism could be re-used, and there could be >crucial clarity in exactly how XQuery builds on XPath. I think that almost all of XQuery, with the exception of element construction, is plausible for use in XPath, which would make it common between XQuery and XSLT. Element construction is a small part of the language, and very convenient for writing short queries. >If XSLT got, in addition to its current path selection, the ability to >crunch cartesian products of information element containers, along with a >lazy-evaluation scheme that allowed for efficient handling of interim >results, wouldn't this address both camps' concerns? Yes. >BTW, thanks to Jonathan Robie for his reasoned and patient arguments. >I've not come all his way yet, but I've learned much and amended some of >my views on the matter. Thanks! I will sometimes drop out of the conversation for a few days or a week, but I'll be in and out on an ongoing basis. Jonathan
|
