RE: [xsl] An issue with XPath 2.0 sequences (Was Re: RE: Muenchian method, and keys 'n stuff)

["Michael Kay" <michael dot h dot kay at ntlworld dot com>]

> Mike Kay wrote:
> > I asked some questions about how this decision came about from
> > colleagues on
> > the various working groups. The basic rationale is that
> it's a consequence
> > of the XML schema type system. Sequences were added to the XPath
> > data model
> > because XML Schema supports sequences of simple values.
> Schema doesn't
> > support sequences of sequences, so we don't either; if you want a
> > hierarchic
> > structure, you use a complex-valued element. So it comes
> down to the fact
> > that we're designing a language for processing XML documents, not a
> > general-purpose programming language.
>
> This particular rationale is rather weak, because XPath 2.0 sequences
> already represent a large superset of what can be represented in
> XML+Schemas.

I think I hinted in my explanation that I knew it was weak: it's a
description of how we got here, not a justification or a claim that it's the
best possible solution.

Nevertheless, I'm reasonably comfortable with it. We're basically doing two
different things with sequences: we're extending the node-set capability of
XPath 1.0 (to handle ordering), and we're modeling sequences of
simple-values, as required by XML Schema, and as required by some common use
cases such as the infamous sum(price*quantity). Non-nested sequences are
sufficient to serve those two purposes; and nested sequences would serve
merely to increase the overlap and inconsistency between the "trees" part of
the model (which is about handling XML documents) and the "variables" part
of the model (which is about doing computations).

Mike Kay
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list