- 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