Re: [xsl] Should "//ename[n]" mean "/descendant::e name"?]

[Jonathan Robie <jwrobie at mindspring dot com>]

At 03:06 PM 12/19/2001 +0000, David Carlisle wrote:
>I'm frankly shocked and concerned that the WG should even consider such
>a strange idea as to so radically change the semantics of such a core
>Xpath feature, keeping the syntax legal but changing its meaning.
>If compatibility is of such low concern it does not bode well for XSLT 2.

Let me be real clear: I was not speaking for the WGs or acting on their 
behalf in asking this question. I was gathering data. I ask a lot of 
questions. I brainstorm a lot. That's the way I work.

>In this case the proposed definition seems far less useful than the
>current definition, but even if it was conceptually an improvement it
>would be years too late to change. If you need to add a new feature then
>please use a new syntax, don't abuse existing syntax.

As you point out, my idea would not cover all the axes, so it is broken. 
Since virtually every query I write involving // and subscripts requires 
parentheses to come out right, I would love to come up with a definition 
that would allow //para[1] to mean the first paragraph in the document, but 
my proposed definition does not do that cleanly.

Again, speaking for myself, I do think that some things in XPath 1.0, such 
as the first semantics for set comparisons, are problematic for a strongly 
typed query language, so I think that integrating XQuery 1.0 and XPath 2.0 
might lead to some incompatibilities with XPath 1.0. And if we do make 
changes that lead to incompatibilities, we should avoid changes that are 
likely to break stylesheets, and also assume that we will likely not have 
the opportunity to do so again.

Jonathan



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list