This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: XPath 2.0: Collection-Valued Expressions (Was: Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0)


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]