[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Thursday, May 09, 2002 4:44 PM
> To: Jonathan Robie
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XPath 2.0 - how much of XQuery should
> it include?
>
>
> 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.
>
XPath as XQuery - node constructors + a few more axes nodes might as
well be called XQuery-reduced instead of XPath 2.0 since instead of
being an incremental version of XPath it is primarily XQuery on training
wheels.
--
PITHY WORDS OF WISDOM
Two wrongs are only the beginning.
This posting is provided "AS IS" with no warranties, and confers no
rights.
You assume all risk for your use. (c) 2002 Microsoft Corporation. All
rights reserved.
|
