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

Subject: Re: [xsl] Re: Re: Re: Re: order of UNIONs
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Fri, 16 Nov 2001 14:24:49 +0000
Hi Dimitre,

> However, putting foxes and hens together and calling them all hens
> and treating them just as hens-- this will have such consequences
> as:
>
> 1. The hens, the foxes, or both will suffer (foxes from
> over-eating).
>
> 2. To say that hens are laying eggs will no longer be true.
>
> 2. Some hens will have feathers, others -- fur.
>
> 3. A new branch of zoology dealing with 'foxhens' will emerge.
>
> 4. There would be a lot of feathers in the air.

:)

It comes down to whether you view 'node sets' as being a subset of
'node sequences'. If they are viewed like that, then the analogy is
closer to putting birds and hens together and inventing ornithology.
There might still be lots of feathers in the air, and we should
certainly educate people so that they can tell the difference between
hens and other birds, but there's no danger of the hens being eaten
(well, aside from by the hawks I guess, but I've lost track of what
they're analogous to).

Now I haven't yet seen a conclusive practical argument against viewing
node sets as a subset of node sequences (although a mail from David's
just come in that might change my mind). I understand the mathematical
difference between sets and lists and bags, but my argument would be
that:

 - the set of node-sequences-that-don't-contain-duplicates is a subset
   of the set of node sequences

 - if order doesn't matter, then it doesn't matter if they're ordered,
   therefore for practical purposes, node sets are equal to the set of
   node-sequences-that-don't-contain-duplicates (though to make
   position() and xsl:for-each work with other sequences, node sets
   are actually equivalent to
   node-sequences-that-don't-contain-duplicates-and-are-in-document-order).

> In XSLT 2.0 you could do a lot of processing, wasting a lot of time,
> until you reach item no. 999 which is a number and not a node -- not
> even a run-time error will occur to save you from this.

*Ahh*. That's a very good point, and it rests on whether there are
such things as sequences that contain both nodes and simple values.
It is stated that they can in the Introduction to the data model:

  "A sequence is an ordered collection of nodes, simple values, or any
  mixture of nodes and simple values."

I seem to remember seeing somewhere something (possibly an issue from
Mike in the F&O WD) that implied that it was still an open issue, but
I agree that it's a potential problem. Have you written to
www-xml-query-comments@xxxxxx about it?

> Now, in order to prevent such a scenario you will have to include
> additional code in your templates -- something that you didn't have
> to do in XSLT 1.0.

Well, you still come up against it in some situations. What about all
those templates for getting the minima that went through a node set
until they got to node 999 that contains something that can't be
converted into a number?

I agree that mixed sequences makes that worse because after all that
work the transformation halts on an error, but that's more to do
with the problem of not being able to tell if something is a node or
not (or of not being able to use strings/numbers as the starting point
for a location path, depending on your point of view).

Cheers,

Jeni

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


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


Current Thread