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

Subject: Re: [xsl] Should "//ename[n]" mean "/descendant::e name"?]
From: Jonathan Robie <jwrobie@xxxxxxxxxxxxxx>
Date: Thu, 20 Dec 2001 11:57:03 -0500
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


Current Thread