[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: XPath's role (Was: Re: [xsl] Re: . in for)


Subject: RE: XPath's role (Was: Re: [xsl] Re: . in for)
From: "Kevin Jones" <kjouk@xxxxxxxxxxx>
Date: Sun, 6 Jan 2002 23:49:26 -0000

>
> 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 @... address at http://mail.yahoo.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords