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

> Sorry if that's a bit of a rant. It just frustrates me that XPath
> seems to be developing into a cut-down XQuery rather than XQuery being
> built on top of XPath (the XQuery WD even shares parts of the XPath WD
> rather than referring to it). Let XQuery develop into the
> strongly-typed optimiser's-dream of a query language for those that
> need it, but let XPath remain an elegant, embeddable, usable, sweet
> little expression language for the rest of us.

I tend to agree that the justification for the flow control additions, 'for'
and to a lesser extent 'if', is somewhat suspect in an expression languages.
Perhaps there is an issue here about the pre-concieved expectations of each
languages role. XQuery appears to me to be just a superset of XPath in which
case you could replace XSLT+XPath with XSLT+XQuery, i.e.

	XSLT uses XQuery implements XPath
	XPointer uses XPath
	XForms uses XPath

Although I doubt if this is at all practical today it would resolve the
issue of the positioning of the three languages. XSLT is particularly strong
in output generation but weak in non-hierarcical queries. Using XQuery
within XSLT could change this and avoid the need for duplication of
facilities between XSLT and XQuery, e.g. is xsl:for-each usefull when you
can use XQuery FLWR instead? The alternative, as you point out, is query
functionality creep in XPath/XSLT so that it can perform better on complex
data sets.

There is an interesting article by James Clark on the merging of XSLT +
XQuery, at http://www.jclark.com/xml/construct.html. I don't think I would
like to see things go that far but its a good read.

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