- From: Paul Prescod <paul@prescod.net>
- Date: Sun, 06 Apr 2003 17:38:15 -0700
- To: public-qt-comments@w3.org
- CC: evan@evanlenz.net, michael.h.kay@ntlworld.com
XPath 2 does not allow nested sequences. I believe that this is a
mistake and one which will be difficult to correct in the future. I
don't know how widely this has been discussed, but I found this:
http://www.biglist.com/lists/xsl-list/archives/200201/msg01723.html
It didn't exactly warm my heart. Nobody could justify the current
situation as anything more than "the way things evolved". "I accept that
the above isn't a conclusive argument that we've done the right thing; I
present it more as a post-hoc explanation of how the language came to be
like it is."
It seems to me that this is the same sort of "simplifying" arbitrary
limitation that left real sequences out of XPath 1. Once you've said
that nested sequences are flattened it will be VERY hard to fix in XPath
3! I can't off the top of my head think of a relatively clean way to
evolve from the current model and syntax to one that allows true nested
sequences. So let's get this right the first time!
The specification itself has the following example:
"The following example transforms the input document into a list in
which each author's name appears only once, followed by a list of titles
of books written by that author."
for $a in distinct-values(//author)
return ($a,
for $b in //book[author = $a]
return $b/title)
It seems much more likely that you'd like a sequence of pairs.
Otherwise, how do you differentiate the authors' names fro the book
titles in the sequence that is returned? There are very few
circumstances under which you would just not care about the distinction.
I can already imagine myself gritting my teeth working around these
sorts of situations.
Furhermore, it makes the language harder to learn (and perhaps
implement!), not easier, because people are used to nested sequences
from every other sequence manipulation language going back to the
fifties (with the possible exception of Perl 4).
Paul Prescod
Received on Sunday, 6 April 2003 20:38:41 UTC