[
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?
Absolutely.
>OK...
Thanks...
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
statements?
> - 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)
Agreed.
>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.
Jonathan
|
