> However you cannot pass the result from document
> through the XSLT template processor. You can
> insert the result in the output - anything else
> is quite tedious.
Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of anything in the XPath 1.0 or XSLT 1.0 specs that prevents this. Please correct me if I'm mistaken on this.
> The difference is that that XQuery allows
> element construction, document input, and
> node selection/extraction to be combined
> and nested much more flexibly.
This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly? Again, examples of use cases (or pointers to them) where XQuery provides a significantly easier or more efficient solution than XSLT would clarify your point.
> Compactness is an important value in a
> programming language. Programming errors tend
> to be proportional to program length, and
> productivity as measured in tokens per
> programmer-day seems to be relatively
> language-independent.
> While XML is a good syntax for documents and
> data, it is (I think) a terrible syntax for a
> programming language.
Agreed. Every attempt to create a programming language based on XML syntax has either been too awkward to use or has invented some "alterations" to XML to make it more usuable, such that it really isn't XML anymore. In a way, XSLT falls into the latter category. A good bit of the logic in XSLT is expressed in XPath, which uses a non-XML syntax. As seen in the XPath 2.0 and XSLT 2.0 drafts, even more power is being put into XPath. As I've said, I think there's a good balance there, so it satisfies both the compact-syntax-desiring programmer in me and the markup fanatic in me. Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it really is from my favorite scripting language with a good XPath library.
One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements that will be coming with XSLT 2.0? Given that XQuery uses XPath 2.0, and thus benefits from lessons learned with XPath 1.0 and XSLT 1.0, it would hardly be fair to compare to the older standards.
[ Side note: Does xml.com have some way to get notified when someone replies to your post? This discussion is getting drawn out quite a bit as I keep forgetting to check back for responses. ]
> Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of
> anything in the XPath 1.0 or XSLT 1.0 specs that prevents this.
Perhaps we're talking about different things. Could you give an example of how you do this?
> This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly?
XQuery allows you to nest element constructor expressions (XML syntax) inside complex XQuery expressions, and you can conversely nest complex
XQuery expressions inside element constructors.
With XSLT, you can nest XPath expressions inside
XML, but you can't nest XML constructors inside
XPath expressions. So a loop or recursive
function that returns new XML nodes is difficult
to write.
> Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it
> really is from my favorite scripting language with a good XPath library.
The big difference is how easy it is to *create*
XML nodes using XQuery, and then process them
just like nodes from an input document.
With e.g. JSP you create *text*, not *nodes*.
See my later article:
http://www.xml.com/pub/a/2002/12/23/xquery.html
> One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements
> that will be coming with XSLT 2.0?
I'm trying to, though I don't have as good a picture of XSLT 2.0.
> Side note: Does xml.com have some way to get notified when someone replies to your post? This
> discussion is getting drawn out quite a bit as I keep forgetting to check back for responses.
I know I as an author get notification, but I
don't know if you can request it.
> > Actually, I use template rules to process nodes from other documents regularly, and I'm not aware of
> > anything in the XPath 1.0 or XSLT 1.0 specs that prevents this.
> Perhaps we're talking about different things. Could you give an example of how you do this?
<xsl:template match="product">
<xsl:param name="item"/>
<!-- Generate invoice line-item for this product, using information from both the current node (product), as well as the item node from the order document -->
</xsl:template>
This, of course, is just one way in which this sort of thing can be done. Is this what you had in mind?
> > This is a very vague statement. *How* does XQuery allow these things to be combined more flexibly?
> XQuery allows you to nest element constructor expressions (XML syntax) inside complex XQuery expressions, and you can conversely nest complex
> XQuery expressions inside element constructors.
> With XSLT, you can nest XPath expressions inside
> XML, but you can't nest XML constructors inside
> XPath expressions. So a loop or recursive
> function that returns new XML nodes is difficult
> to write.
It is possible to set a variable to a result tree fragment, then use that variable in another XPath expression, though you're right that it can't be done directly, and RTFs are a pain to work with, anyway, due to the restrictions on them.
However, RTFs go away with XSLT 2, and everything is a node set, so generating XML nodes that can be used just as if they came from an input document will be easier. Also, the addition of standard support for XPath extension functions defined in XSLT will provide another flexible way to do this.
As for loops and recursive functions, I create these regularly using <xsl:call-template>. The syntax does make it a little awkward, but not unreasonable, and this will also get easier with the new extension function support in XSLT 2.
> > Given the almost complete abandonment of XML syntax in XQuery, I'm not sure how different it
> > really is from my favorite scripting language with a good XPath library.
> The big difference is how easy it is to *create*
> XML nodes using XQuery, and then process them
> just like nodes from an input document.
> With e.g. JSP you create *text*, not *nodes*.
I suppose I can see that. Offhand, I can't think of an example of where this would be important to me, but maybe I just don't have the right kind of application in mind. *shrug*
> > One final question. In comparing XSLT and XQuery, are you keeping in mind the improvements
> > that will be coming with XSLT 2.0?
> I'm trying to, though I don't have as good a picture of XSLT 2.0.
The current draft spec seems to outline the changes fairly well. I think the most important aspects, at least for this discussion, are the improvements in XPath 2.0, with which you must be quite familiar, the elimination of result tree fragments and the standardization of XPath extension functions written in XSLT.
I'm still eager to see some examples that show how XQuery can solve the same problem better than XSLT. Can you point me to something like this? I really am interested in the possibility of applying XQuery in my own work, but haven't found the compelling reason to use it over XSLT.
The XSLT 2.0 draft spec 6.2 says "The xsl:apply-templates instruction takes as input a sequence of nodes in the source tree". One could argue that prohibits your usage, since the nodes aren't in the "source tree". But I think it's
just a poor choice - I agree it *should* be allowed.
The main advantage of XQuery is that everything
nests. You can iterate over one of more
data-sets (i.e. a join), construct elements
containg arbirary expressions based on each
value of the "loop", and pass arbitary data
as arguments and results of user-defined functions. I don't offhand know if there is
a set of XQuery programs you can't express
in XSLT, but think many of them will be a lot
more natural and compact using XQuery.
For now we'll just have to disagree, at least
until there is more experience with XQuery, or
I read a good analysis of their relative "power".
>The big difference is how easy it is to *create*
>> XML nodes using XQuery, and then process them
>> just like nodes from an input document.
>> With e.g. JSP you create *text*, not *nodes*.
> I suppose I can see that. Offhand, I can't think of an example of where this would be important to
> me, but maybe I just don't have the right kind of application in mind.
Think of filters, where you're passing data from
one transformation to another. If the data are
nodes rather than text, not only can you express
a transformation chain very compactly and
naturally as a set of function calls, but it
also should be more efficient than continuously
formatting and parsing the data.
> I'm still eager to see some examples that show how XQuery can solve the same problem better than
> XSLT. Can you point me to something like this? I really am interested in the possibility of
> applying XQuery in my own work, but haven't found the compelling reason to use it over XSLT.
Well, perhaps for you, who are fluent in XSLT,it's not that compelling. But I'd be curious to see
how you'd the photo album application. See
http://xml.com/pub/a/2002/12/23/xquery.html
- the latest version version of the XQuery source is
http://www.gnu.org/software/qexo/qalbum/pictures.xql
and an example showing most of the features is
http://pics.bothner.com/2002/BristleconePines/ .)
Previous Message
Up
