W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2002

Re: Comments on XPath (30th April)

From: David Carlisle <davidc@nag.co.uk>
Date: Tue, 21 May 2002 18:43:14 +0100
Message-Id: <200205211743.SAA10932@penguin.nag.co.uk>
To: Michael.Kay@softwareag.com
CC: public-qt-comments@w3.org

> The justification that's used is that the type of the result can be
> determined statically, which it can't for id().

well yes but personally I don't think that's sufficient justification
but also I only know that at all because I have W3C access (or because
you just told me), the documents as written just inflict the syntax with
no suggestion as to why it is there.

> It doesn't actually mean quite the same
you can't always replace << by following:: but I think in this case
it means the same (after coercing to boolean) doesn't it? and in other
cases (involving attributes or multiple documents you can do _something_)

> You think we should allow "let" in XPath?
I'm not sure, it's just a comment. (An alternative is to take out for
and move iterating over sequences to xslt, as per Jeni's suggestion)
The disability to bind variables does mean that if you are doing
anything very complicated you are going to have to re-evaluate
expressions, or try to move the looping to XSLT anyway. It's easier to
point out problems with the current situation than to suggest fixes...

> I don't much like the alternative of introducing a
> second pair of operators. I'm more inclined to solve it by having a rule
> at the XSLT level, 

Hmm OK if XSLT compatibiliy can be recreated then perhaps this isn't so


This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
Received on Tuesday, 21 May 2002 13:44:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:09 UTC