> > 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?
Certainly. :)
<xsl:template match="order">
<!-- Generate invoice header with customer's name, address, etc. -->
<xsl:for-each select="item">
<xsl:apply-templates select="document('products.xml')//product[@id = current()/@ref]">
<xsl:with-param name="item" select="."/>
</xsl:apply-templates>
</xsl:for-each>
</xsl:template>
<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.
|
Previous Message
Up
