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

["Evan Lenz" <elenz at xyzfind 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. In fact, most sequences of elements consist of elements that
are not siblings to each other in some source document; this can't be
represented in XML Schemas. When a sequence is copied, yes, they end up as
siblings, but that's part of the magic of element constructors, not a
property of the original sequence itself. Moreover, even sequences of simple
values in XPath 2.0 can't all be represented in XML Schemas. Most use cases
that involve sequences could be reformulated using temporary trees (i.e.
XML). Ultimately, sequences are provided as a convenience so you're not
forced to represent everything as XML.

Given that sequences in XPath 2.0 *are* meant to provide the convenience of
a programming language without requiring everything to be processed as XML
(IMHO), and given that they can't generally be represented in XML Schemas,
it's not that huge of a leap to allow hierarchical sequences and to say
that, when copied (e.g. inside an element constructor), each member is
copied top-down, left-to-right. Right now, the story is that they're copied
left-to-right.

My point isn't to argue for hierarchical sequences (because I both am not
convinced they are necessary and am not sure what kinds of additional
compatibility problems would arise), but just to say that this particular
rationale is pretty bogus.

Evan


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