Re: [xsl] Re: Re: Re: Re: order of UNIONs

[Jeni Tennison <jeni at jenitennison dot com>]

Hi David,

> the natural function to apply to lists is "map" which takes a list
> of X and a function from X to Y and produces a list of Y by applying
> the function to each elemnt in the list. This naturally produces a
> list of equal length to what you started with. So to remain
> isomorphic to the set operations you start to add duplicate removal
> and re-ordering semantics to the operators, which is fine, but then
> you realise why you wanted to have sequences in the first place was
> to handle sequences that might contain duplicates and might not have
> any notion of document order (simple values, for instance). Again
> it's always possible to specify something but not necessarily easy
> to make everything work in a natural way.

I see your point. Taking = as the operator, if {1, 2, 3, 4} is a list
then:

  {1, 2, 3, 4} = 2

should give {false, true, false, false} whereas if {1, 2, 3, 4} is a
set then:

  {1, 2, 3, 4} = 2

should give... um... well true for the sake of argument :)

And if you start using operators/functions that return lists then you
naturally end up with lists of lists.

> The main use case for sequences (as stated in the requirents doc) is
> for schema list types, ie lists of simple values. Simple values
> don't have identity (any integer 3 is the same as any other one)
> Node sets in xpath are sets over node-identity (a function, somewhat
> strangely not actually available in xpath 1) rather than node value.
> You can have two nodes in a node set with the same value, they just
> can't be the same node. Thus merging these two things (and the
> operations on them) isn't as simple as you seem to suggest. (But
> it's not my problem as I'm not in the WG:-)

(Sometimes I think that it's more our problem than it is many of those
in the WGs because we're the people that are going to have to use
whatever it is they come out with whereas they can happily go on to
write more specs.)

So the question is which is going to be more confusing - having
sequences cover both node sets and simple value sequences, with
operations working over sequences as if they were sets over
node-identity; making the distinction between node sets and simple
value sequences but having the same operations (including XSLT
instructions) working differently for node sets than they do for
simple value sequences; or breaking backwards compatibility?

I think that comes down to whether you want the functions and
operations that work over simple value sequences to treat them like
lists or not. If you do, such that:

  {1, 2, 3, 4} + 2         => {3, 4, 5, 6}
  {1, 2, 3, 4} = 2         => {false, true, false, false}
  key('foo', {1, 2, 3, 4}) => {{$node1, $node4}, {$node3, $node5},
                               {$node2, $node8}, {$node6, $node7}}

and so on, then you either need to keep node sets separate from simple
value sequences or destroy backwards compatibility (which isn't really
an option).

If you don't, such that you want:

  {1, 2, 3, 4} + 2         => 3
  {1, 2, 3, 4} = 2         => true
  key('foo', {1, 2, 3, 4}) => {$node1, $node2, $node3, $node4,
                               $node5, $node6, $node7, $node8}

then I think you can group node sets and simple value sequences
together.

My feeling is that while the former treatment of simple value lists is
theoretically purer, more generic and more extensible, for the
'normal' users of XSLT, the latter is more intuitive.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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