[
Lists Home |
Date Index |
Thread Index
]
Hi Jonathan,
> And what other features of XPath 2.0 do you think are overkill for
> XPath?
Do you really want to hear? OK...
The fundamental thing is that XPath is used by XSLT as an expression
language. It's used in XSLT to provide values for instructions, not as
a programming language in its own right. This is reflected in the fact
that it is embedded in attribute values, not used in content.
If you have an XPath that's going over several lines, then something's
going wrong (not that the XPaths I write don't sometimes go over
several lines, just that when they do so it usually indicates either a
deficiency in the language, or that I'm trying to show off). At a
practical level, line breaks in attribute values aren't maintained by
XML parsers, so you're likely to lose all that nice formatting if your
XSLT stylesheet is ever treated like the XML that it is.
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. XPath 2.0 also
replicates other functionality that's already supported in XSLT:
sorting, for example, and variable assignment (though obviously XPath
2.0 can only carry out variable assignment in limited contexts,
something that in my opinion undermines the idea that for expressions
can solve all the problems of sequence construction in XSLT 2.0).
Obviously XQuery needs this -- it has to have statements because it
isn't embedded in something that does -- but XPath 2.0 doesn't (or
wouldn't if XSLT 2.0 was adjusted to enable it to create sequences of
atomic values, something that I believe is entirely feasible).
Most of what I believe is overkill for XPath 2.0 is stuff that's
simply too complicated for an expression language:
- 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
- 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
- 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
- the "union" operator -- when is it ever a good idea to have more
than one symbol for the same operator?
- 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.
- 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.
You didn't want me to go into the functions, did you?...
Don't get me wrong -- there are some things that I think are good in
XPath 2.0. Sequence construction has the promise of being really handy
if it's easy -- it's one of those things where we'll appreciate a lot
more when we're able to use it. Being able to compare the identity of
two nodes is fabulous (although to be honest, it's mainly used for
grouping, and that's built-in to XSLT 1.0). General steps... [sound
that Homer (Simpson, not the poet) makes when he thinks of beer] ;)
> Is it a mistake for XPath to try to incorporate so much of XQuery,
> or is this what users really want?
To a certain extent, it's hard to answer this question. We won't know
what we want until we start trying to work with XPath 2.0. In
particular, sequences of atomic values are such a radical change that
anything we say now about what we need in order to manipulate them are
guesses. 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.
(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.)
I do think that it's a lot easier to add features to a language than
it is to take them away; XPath 2.0 should be *core* functionality, not
XQuery minus node-constructors. And the other users of XPath --
XPointers, XForms, XML Schema, should be considered as well.
Ahh... it's nice to feel someone might be listening... Let me know if
you want me to expand with some use cases.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
