[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XPath's role (Was: Re: Re: . in for)
> > As I understand it, XQuery is designed to be used on its own, not > embedded in any other language, and is meant to handle all types of > queries and construct new nodes and so on. If XQuery were embedded in > XSLT, I think that the only contribution XSLT would have would be a > wrapper xsl:stylesheet element (and even that will be discarded, since > (as discussed on XML-Dev) XQuery is really not designed for being > embedded in an XML document)! 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. > > But I think I'm missing a few things here: > > 1. An example that demonstrates XSLT+XPaths's inability to cope > with non-hierarchical queries. You are of course right about this. The work Evan Lenz did on translating the XQuery examples into XSLT shows it looks really unlikely that XSLT+XPath couldn't do it. What may be more correct is that it can't do it over large data sets comfortably. > > 2. An argument that demonstrates that XSLT+XPath is the appropriate > tool for this non-hierarchical query example, rather than XQuery. > I don't think I can oblige here but I will have a go at the counter argument. I am defiantly no expert on XQuery, but since I haven't seen any good reference to why XQuery can not be done with XSLT (shouldn't the working groups be mandated to provide some justification for what they do?). Apologies to those who see this as an obvious case. Taking a example from the XQuery document, <descriptive-catalog> for $i in document("catalog.xml")//:item, $p in document("parts.xml")//part[partno = $i/partno], $s in document("suppliers.xml")//supplier[suppno = $i/suppno] return <item> { $p/description, $s/suppname, $i/price } </item> sortby(description, suppname) } </descriptive-catalog> This is clearly a three way join, that (I think) could be represented efficiently in XSLT by, <descriptive-catalog> <xsl:for-each select="document("catalog.xml")//item"> <item> <xsl:value-of select="description"/> <xsl:value-of select="document("suppliers.xml")//supplier[suppno = ./suppno]/suppname"/> <xsl:value-of select="document("parts.xml")//part[partno = ./partno]/price"/> </item> </xsl:for-each> <descriptive-catalog> Assuming each part always has one and only one part and supplier. Now add a where clause restricting to suppliers starting with 'A'. This is trivial in the XQuery case while in the XSLT case you need to change it to something like (ignoring sort order). <descriptive-catalog> <xsl:for-each select="document("suppliers.xml")//supplier[starts-with(suppname,'A')]"> <xsl:variable name="supplier" select="current()"/> <xsl:for-each select="document("catalog.xml")//item[suppno=$supplier/suppno]"> <item> <xsl:value-of select="description"/> <xsl:value-of select="$supplier/suppname"/> <xsl:value-of select="document("parts.xml")//part[partno = ./partno]/price"/> </item> </xsl:for-each> </xsl:for-each> <descriptive-catalog> 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. > 3. An argument that demonstrates that it is XSLT+XPath that should > be altered to be able to manage this query example, rather than > XQuery being improved to make it the appropriate tool for the > job. > 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. Apologies for taking up so much bandwidth on a XSLT list talking about XQuery but I think its important to establish the strengths/weaknesses of the languages. Sorry if this has been covered before elsewhere, it just wasn't clear to me. Regards, Kev. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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
|