RE: [DM]Some doubts/comments

> 3) In Section 2.5 "Sequences" its mentioned, "If
> sequences are combined, the result is always a
> flattened sequence. In other words, appending (d e) to
> (a b c) produces a sequence of length 5: (a b c d e).
> It does not produces a sequence of length 4: 
> (a b c (d e)), such a nested sequence never occurs"
> 
> I would have wished nested sequences! I am curious to
> know, why nested sequences are not allowed in the
> language ? 

This came up as a detailed proposal during the last call stage, and I think
the proposal failed to win support at that stage for three main reasons: (a)
because it was too disruptive (we all want to get finished), (b) because the
facility was felt to be unnecessary feature creep, and (c) because nested
sequences don't seem to correspond to anything that exists in XML.

The data model supports sequences of nodes because they arise naturally in
XML and are useful as the result of a query. It supports sequences of atomic
values because they correspond to XML Schema list types, and because they
are useful as intermediate results when doing aggregations (e.g. sum(),
max(), min()). It supports sequences that mix atomic values and nodes
because on balance it is better to allow them than to impose a restriction -
they are handy in constructs such as max((@a, 0)). But nested sequences
don't arise naturally in XML, in fact they provide a data structure that
competes directly with XML trees. It would give you two different kinds of
tree structure in the data model, with different constraints and different
operators, which I think would be very confusing to users. It's already
confusing enough to many people that you can't access nodes in a sequence
using the sibling axis. (It wouldn't make sense, because a node can be a
member of any number of different sequences, but it can only belong to one
XML tree.)

Michael Kay
(speaking for himself)

Received on Tuesday, 9 November 2004 14:17:37 UTC