OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath 2.0 - how much of XQuery should it include?

[ Lists Home | Date Index | Thread Index ]

At 12:44 AM 5/10/2002 +0100, Jeni Tennison wrote:
>Hi Jonathan,
> > And what other features of XPath 2.0 do you think are overkill for
> > XPath?
>Do you really want to hear?




Mike Kay forwarded your email to our internal lists. I will try to 
summarize the results of this thread for the XPath task force, and ask for 
this to be put on our agenda.

 > XPath 2.0 incorporates a number of *statements* that are already
>provided by XSLT 2.0. The for "expression" and the if "expression"
>would be classed as statements in any other language.

The reason they are not called statements in XPath 2.0 is that XPath 2.0, 
like XQuery, is a functional language, and it doesn't really have 
statements. They do resemble traditional statements syntactically, but 
these are expressions to be evaluated, not statements to be executed. Is 
the syntactic form the problem - that it looks too much like the XSLT 

>   - for expressions, because XSLT has xsl:for-each, although I do
>     think that a simple mapping operator would be essential if there
>     weren't for expressions
>   - conditional expressions, as they currently are, because XSLT has
>     xsl:if and xsl:choose, although I do think that a simple
>     conditional expression (i.e. test ? true : false) would be vital
>     if there weren't if expressions

For these two, you are essentially asking for a simpler syntax to be used 
in XPath to express a subset of the functionality of existing expressions 
in XQuery. I am a little allergic to this, because that means that XQuery 
would probably have to support both, moving the duplication out of XPath 
and into XQuery. Is changing the syntax of if and for important enough to 
justify this?

>   - quantified expressions, because you could replicate them with a
>     simple mapping operator, and in my experience you don't often
>     need to test that every $x satisfies something when doing a
>     transformation (and the existential qualification of the existing
>     comparisons covers the 'some' expression)


>Other things I feel less strongly about; I wouldn't abandon XPath 2.0
>if they remained, but I don't particularly see the point of them (or
>the requirement, if you want to go by use cases):
>   - comments in XPaths -- if an XPath gets long enough that you need
>     to embed comments in it, you should break it up and use XML
>     comments instead

Or perhaps we need to think about how to use XQuery and XSLT together, so 
that people can use XQuery when they need complex expressions like these.

>   - dereferences -- id(), which does basically the same thing, is
>     very rarely used because people tend to want to make their
>     stylesheets robust in case DTDs aren't available for some reason,
>     so use key() instead. I don't see that dereferencing will be any
>     different, although if it used XML Schema identity constraints it
>     would be a lot more compelling

Or if it used simple links that can cross document boundaries. The 
dereference operator is already under heavy scrutiny. It may well be 
dropped. If simple XLinks come to exist, it may be reintroduced with more 
general functionality.

>   - the "union" operator -- when is it ever a good idea to have more
>     than one symbol for the same operator?

Would you want the 'intersect' operator in XPath? If so, I would rather use 
'union' and 'intersect' than '|' and 'intersect'.

>   - eq/ne/lt/gt/ge/le -- these do exactly the same as =/!=/</>/>=/<=.
>     The only difference for XPath (as far as I can see) is that if the
>     arguments are sequences then they (due to fallback processing)
>     compare the first of the items in those sequences rather than
>     every combination of values of those sequences. I can't think of
>     any occasion in which that's useful.

I bet you rewrote that last sentence three times before you came up with a 
formulation this polite ;->

>   - one of the pair of <</>> or precedes/follows -- but you knew that;
>     I have no idea which one, because most of the time you need to do
>     that kind of test, you know that neither of the nodes is an
>     ancestor of the other so the distinction doesn't apply.

Yes, we do know this. I'm writing a presentation on the subject right now...

>You didn't want me to go into the functions, did you?...

Oh yes!!! The status quo is that XPath is going to inherit the entire 
function library. If you don't want this, let's hear the feedback.

>If I were to guess, I'd say that users want XPath 2.0 to be
>much like XPath 1.0, with a few small changes to address the
>requirements that we've discovered, through usage, over the past
>couple of years. They want regular expressions and date formatting.

So far the feedback from others on this list is consistent with yours. Does 
anybody strongly disagree?

I wonder if anybody has time to raise this subject on 
xsl-list@lists.mulberrytech.com. I don't have time to participate in 
another active discussion, but it would be interesting to see whether those 
people agree.

The main reason that has been given for including all these features in 
XPath is the claim that XSL users really want them. If that's not the case, 
I really think we should keep XPath simpler.

>(Honestly, they want dynamic evaluation, but we've already been told
>in no uncertain terms that that's not going to happen, so really I
>should stop carping on about it.)

Dynamic evaluation is another reason I don't want to show my face on 
xsl-list@lists.mulberrytech.com ;->

>Ahh... it's nice to feel someone might be listening... Let me know if
>you want me to expand with some use cases.

Oh, yes!!!! I'm always a sucker for use cases.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS