Re: XPath's role (Was: Re: Re: . in for)
Kevin Jones wrote: > Without something like template support XQuery is never going to be > as flexible as XSLT at output generation. We all know the trouble > you get into trying to exclusively use for loop constructs to create > XML. I can see quite a lot uses for XSLT as a post-processing stage > to a query along with its traditional use. I *think* that most of the problems that you encounter due to using xsl:for-each to generate output arise when the structure of the source document is unpredictable and you want the result to follow the ordering of the source. This really only occurs in more document-oriented structures, where you get mixed content and recursive nesting. The other distinction between xsl:for-each and xsl:template is the fact that xsl:for-each is nested within templates whereas xsl:template elements are top-level elements; but in XQuery you manage this nesting problem by calling functions (and you can also handle it in XSLT in this way - by calling templates by name). > While I am sure its possible to make the XSLT queries more > efficient, that is not the point. The issue is that in XSLT you > explicitly encode the access mechanism required for your query while > in FLWR you don't. This means the XQuery processors is going to take > responsibility for query optimization which in XSLT is near > impossible for a processor to do once you get beyoond using a sible > instruction. In this case a XQuery optimizer might decide there are > so few items we might as well search all of them and just check the > supplier names starts with 'A' or it might take a similar approach > to the XSLT of restricting the suppliers first knowing it has a > quick way of finding items for a supplier. In either case we > shouldn't know or care how it does it. For small data sets this does > not matter at all, but as data sets gets larger its much better to > use a query optermised FLWR than XSLT instructions. Thank you very much for that example, which demonstrates the power of the FLWR expression (and XQuery) very neatly. For interest, I'd have probably done it in XSLT using keys; it would have made the change involved in handling supplier names starting with 'A' a bit easier (change the match attribute for the relevant key). But it still wouldn't have been optimisable in the same way as the XQuery, I imagine. > I think this leaves me in a position where I think XQuery is going > to be more efficient and user friendly for certain types of query > but lacking the expressive output control of XSLT templates. Hence > the view that XSLT+XQuery might be a better combination than > XSLT+(an upgraded)XPath. Ignoring the 'XQuery is not XML' issue and > the overlap in element construction capabilities. Of course, a FLWR > like statement could always be added to XSLT but why bother if that > can be pinched from XQuery. I guess a database implementation of > XQuery will be rather different than a XSLT based impmentation > because of the different data source characteristics but that's just > what a particular implementation is optimized for. It depends on what you mean by XSLT+XQuery. I like the idea of using XQuery to construct a simple XML document from a database, and having that simple XML document passed on to an XSLT stylesheet to create the desired result. A bit like the way XSQL (from Oracle) works. But using XQuery as the query language in XSLT instead of XPath is a bad idea, I think. I imagine that XQuery's optimisability and efficiency is much helped by the fact that it doesn't have to worry about axes other than self, parent, child, descendant, descendant-or-self, and attribute. But if you removed these axes from the set that XSLT can handle, it will become useless for many document-oriented transformations. I think that at the ends of the transformation spectrum the choice between XQuery and XSLT should be clear: XQuery for large data-sets and efficient joins; XSLT for document-oriented transformations. The middle ground (transformations involved small data-oriented XML documents) will be won by the technology that is easiest to learn and use, and the one with the best implementation support. I'm concerned that blurring the line between the roles of XSLT and XPath will make XSLT 2.0 harder to learn and use and harder to implement, while XQuery at least has consistency. In the end, I fear that this will sideline XSLT into document-oriented transformations that, while important, aren't the bulk market in this area. For those who have a vested interest in XSLT, this should be worrying. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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