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 12:05:48 +0000
Hi Dimitre,

>> In a way I'm quite looking forward to having node sequences rather
>> than node sets, since it's a frequent trap that beginners fall
>> into, and it will one less thing for David to get mathematical
>> about ;)
> You lose one distinct datatype and put two that are quite different
> into one -- I wouldn't call that a step forward.

The main reason I can see for the introduction of the sequence data
type is to enable us to iterate over, count, sum and get the minima
and maxima of lists of numbers (and other data types) without using
recursive templates. I think that this is a reasonable requirement
that will increase the usability of XSLT.

To gain this functionality, I guess that other alternatives (aside
from 'sequence') would be:

  - to have a general type called 'set', which could contain values of
    various kinds rather than just nodes as in XPath 1.0
  - to only allow nodes within sets and treat the items in a list as
    separate sibling text nodes.
  - to have a distinct 'list' type that could only hold primitive
    values (not nodes) in a sequence.

I think the third option is messy because it doesn't make sense for
simple values to be treated that differently from nodes - the items in
a list have just as much 'order' to them as the children of an element
(whether the order is significant depends on the markup language).

The second option is a bit messy too, because it changes the
definition of text nodes and the appearance of the node tree pretty
fundamentally. Plus what happens to the spaces?

The problem I guess with the first option is that you'd have to enable
the 'set' to contain duplicate values, even if it couldn't contain
duplicate nodes. For example:

  <scores>5.6 5.7 5.9 5.7 5.8 5.7</scores>

would create a 'set' that contains six values, three of which are 5.7.
I think using 'set' to describe such a collection would be confusing.

Can you think of another design that would work?

> What about a template that expects a parameter of type "node-set
> sequence" but gets called with just "sequence"? It doesn't seem
> straightforward and natural to detect such cases and take the
> necessary corrective action. This is what you get when mixing two
> different datatypes together.

I agree that not being able to detect the type of the value passed to
a parameter is a distinct problem in XSLT. (In most cases, the problem
is one that comes with weak typing, and the implicit coercion to the
required type works OK. The worst, in my opinion, is getting a string
when you expect a node set, because there's no way to detect the fact
and recover gracefully.)

This case is roughly on a par with the kind of recovery you currently
have to do when you expect a parameter to be a whitespace-normalized
string, a string in a particular format or a number between certain
values. You can do:

  <xsl:param name="nodeSequence" select="/.." />
  <xsl:variable name="nodeSet"
                select="$nodeSequence | $nodeSequence" />

Or you can document the template and trust that the people using it
are sensible enough to pass it node sequences without duplicates, or
are making an educated decision not to if they don't.

Of course XSLT 1.0 templates won't contain this kind of code because
it isn't a distinction in XSLT 1.0. To cope with that, I think having
a template in a stylesheet whose version is 1.0 should lead to some kind
of backward compatibility mode kicking in to make sure that node
sequences are converted to node sets automatically (and numeric data
types to numbers, xs:booleans to booleans and everything else to



Jeni Tennison

 XSL-List info and archive:

Current Thread