Subject: RE: XPath 2.0: Collection-Valued Expressions (Was: Re: [xsl] XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0) From: "Michael Kay" <mhkay@xxxxxxxxxxxx> Date: Sun, 9 Sep 2001 00:27:39 +0100 |
> Would I be correct in thinking that the for/in/return above is a FLIR > expression and that the first syntax also introduces variable > assignment within XPath expressions? I share Dimitre's fear that XPath > 2.0 will become a new programming language rather than a simple > expression syntax, especially where the functionality of the new > syntax mirrors something that already exists in XSLT 2.0. The second > syntax seems much more compatible with the division between XPath and > XSLT as I understand it. The "for" is indeed a subset of what XQuery calls FLWR expressions (for/let/where/return), and it's likely that some subset of FLWR syntax will find its way into XPath 2.0. Some of the requirements published for XPath 2.0 are implicitly saying that people want XPath to be relationally complete in Ted Codd's sense - that is, equivalent in power to first-order predicate calculus. I don't believe you can do this without introducing range variables into XPath. For example, you can't currently join two node-sets based on any condition other than equality of string-values (this is because of the "existential" semantics defined for "=", which is not available for other functions). Doing general joins requires range variables. We may in the end decide that the complexity of adding range variables into XPath isn't justified by the increased power, but there's certainly a good case for needing them. As for the division between XPath and XSLT, I think the best way of rationalising the split is that XPath is for selecting information from the source document, XSLT is for constructing the result document. It should never be necessary to use multiple instructions at the XSLT level in order to extract a single piece of information from the source document. I entirely agree that the terse style of XPath 1.0 expressions and the more verbose style of keyword-based syntax from XQuery (and derived from SQL traditions) don't mix all that elegantly. All I can say is that attempts to extend the functionality while maintaining the terseness have failed: they produce syntax that people find unreadable, misleading, or both. You quickly run out of punctuation characters, or find yourself using them in ways that are unrelated to readers' expectations. For example, at one stage the syntax allowed the expression 1/2, whose value would have been 2. > > > There is an aim to have a much more rigorous type system in XQuery > > and XPath 2.0 than is present in XPath 1.0, with much more scope for > > static type checking and optimization. Unfortunately this makes the > > addition of dynamic features to the language, such as the ability to > > create expressions from strings, rather more difficult. Although > > this feature is much wanted, there was an explicit decision not to > > include it in the XSLT 2.0 or XPath 2.0 requirements. > > Oh, OK, I didn't realise. Guess it's our fault for letting the > multiple requests for dynamic evaluation and its inclusion in several > XSLT processors speak for themselves rather than making a formal noise > about the requirement. Can I request now that it's on the requirements > list for XPath 3.0 (assuming we get that far)? You can request that it's added to the requirements for 2.0 if you want (by commenting on the published 2.0 requirements). Whether your request will succeed, I cannot say... > Can you (or someone) reassure me that there will still be automatic > conversions between value types such that we won't have to be > casting/constructing specific data types all over the place? This is a matter of intense debate. I wish I could give you such an assurance but you'll have to wait and see what gets published. Mike Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XPath 2.0: Collection-Valued Ex, Michael Kay | Thread | Re: XPath 2.0: Collection-Valued Ex, Jeni Tennison |
RE: XPath 2.0: Collection-Valued Ex, Michael Kay | Date | [xsl] Re: xsl hex conversion, Mike Brown |
Month |