Re: Nested sequences in XPath

Kay, Michael wrote:
> I think that very few use cases have come up over the last couple of years
> that require nested sequences, which justifies the original decision not to
> provide them.

Then I'd suggest you remove the example from the specification because 
it clearly calls out for something more than what is in XPath 2.0.

> ... I also think it would be quite confusing to have two separate
> mechanisms for managing trees in XPath, one based on XML and the other based
> on nested sequences, but supporting a completely different set of
> constraints and operators.

There is no need for a mechanism to "manage trees." People who put 
sequences within sequences end up with trees, just because that is how 
the underlying universe works. People uncomfortable with that notion 
will simply not put sequences within sequences.

XPath already has formidable tree manipulation constructs for the same 
reason Lisp and Python are great at dealing with trees. Lists of lists 
are managed with the same tools as lists of simple values. What other 
features would you need?

> If we do ever want to add nested sequences, I don't think it's difficult; we
> would just add a new kind of item called a sequence-reference.

And what would this expression mean in this hypothetical XPath 3:

(a, (b, c), d, (e, f))

> It's certainly too late to contemplate this kind of change at this stage of
> the proceedings, without a much better justification than an unwarm heart.

It may be late but it would be wrong of me to not say that I expect this 
is going to lead to problems.

You don't have to put the feature in, but I would strongly suggest you 
don't make it difficult for yourself to fix the mistake if it turns out 
to be one. Reserve sequence within sequence syntax and semantics.

In my mind, you are defying 40 years of practical experience in computer 
science with the decision that the expression above should be flattened. 
I could be wrong but I believe that Perl 4 did that flattening trick and 
Perl 5 had to hack around that decision by introducing a "reference" 
feature. The result was a total mess.

"For a lot of people (including me), this was one of the hardest things 
to pick up in Perl. But once you learn it, you open up a lot of 
possibilitites. If you're a programmer, try to imagine programming C 
without data structures! That was what things were like in Perl 4. Now, 
with Perl 5, we can make data structures, but it had to be implemented 
in such a way that Perl 4 code would still run properly. As a result, 
sometimes there is a little bit of inconsistency."

http://www.alumni.caltech.edu/~svhwan/prodScript/perlRefsArbitraryStruc.html

  Paul Prescod

Received on Tuesday, 8 April 2003 02:17:36 UTC