Re: Nested sequences in XPath

At 11:17 PM 4/7/2003 -0700, Paul Prescod wrote:

>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.

Hi Paul,

The example in the spec is rather abstract. Perhaps you have some more 
concrete example that can illustrate the usability problem you see?

>>... 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.

This part I do not understand. XPath and XQuery are designed for operations 
on forests of XML nodes or values. XML does not have anything like nested 
lists - it does have nested elements, which we support. Given the rich data 
structures already available in XML, people can easily create intermediate 
structures if they need them. For instance, if you are frustrated by not 
being able to create nested sequences like (1, (2, 3), ( ) ), you can 
create the following:

  <temp><i>{ 1 }</i><i>{ 2, 3 }

If we really needed something along these lines, I suppose we could use 
subscripts for this:

let $c := (1, (2, 3), ( ) )
return <out>
              <c1>{ $c[1] }</c1>
              <c2>{ $c[2] }</c2>
              <c3>{ $c[3] }</c3>
           </out>

At first blush, you might expect the following output:

         <out>
              <c1>1</c1>
              <c2>2 3</c2>
              <c3/>
           </out>

Is that what you are thinking of?

If so, I don't think that parentheses should be the list constructor that 
supports nested lists, because we use them for precedence in expressions, 
and I think the two meanings would conflict. If we added such a feature, I 
would hope we would use a different syntax.

For instance:

     list(1, list(2,3), ())

But this would require big changes to the language and the data model, and 
I have not yet seen a strong case for this feature. Most of the features in 
XQuery have been justified by use cases like those in our use cases 
document. The best way to lobby for a feature is to write up a set of use 
cases that strongly demonstrate the need for that feature. At this stage in 
our development, they should point out real problems that would result if 
we did not add the feature.

>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?

Lisp and Python are significantly different languages than XQuery, though 
there are similarities. I think XQuery probably omits at least several 
important features found in any given language. Which is a good thing, of 
course.

>>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))

Just what it does now, I think. If we want to add your suggested feature in 
the future, we could have list constructors, eg:

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

At any rate, parentheses in XPath or XQuery already have several meanings, 
and I would hate to overload them with yet another meaning.

>>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.

If we added this feature, I would hope we would not do it using parentheses 
as the syntax. I know that parentheses have that meaning in Lisp. I like 
Lisp. I don't think XQuery is Lisp.

>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

I read the URL. The author is saying that you need richer data types than 
Perl 4 had. XQuery has much richer data types than Perl 4, since it is 
based on XML, which can model just about anything.

It's quite possible that we will find other types that we could add in 
future versions of XQuery, but I don't see an overwhelming argument for 
this feature in XQuery 1.0. Let's ship what we have and get some industry 
experience first.

Jonathan

Received on Tuesday, 8 April 2003 10:56:33 UTC