[Xpath-ng] Proposal for definition of values/lists

[Jeni Tennison]

Hi Robin,

>>   Lists are cast to strings and numbers by converting the first value
>>   in the list to a string or number; if the list is empty you get an
>>   empty string or NaN. Lists are cast to boolean true if they contain
>>   any values, boolean false if they do not.
>
> Defaulting to the first item seems counter intuitive to me.
>
>>   [Issue: Should lists be converted to strings by concatenating the
>>    string value of each value, with spaces as separators?]
>
> Yes, I think that is more user friendly (and of course doesn't
> preclude us from providing a separate join() function).
>
> In addition to that, I think that lists should numify to the number
> of their items (flatly, not taking into account the length of their
> content), and thus that empty lists should numify as 0, not NaN. An
> empty list is still a list, even if it's a list of nothing. NaN is
> not a number, but zero is (I hope the parallel is clear).

I think that this would be tricky given that you also wanted a
sequence with only one item to be equivalent to an item on its own.
Should casting the sequence (4) to a number return 1 (the sequence
holds a single item) or 4 (the value of the item is 4)? That said,
converting to a boolean() already has this feature.

These choices would be very backwards incompatible. That's not to say
that we shouldn't make them, just that we should be aware of the
payoffs.

XPath 1.0 converts a node set to a string by taking the string value
of the first node in the set (in document order), and to a number by
taking the numeric value of that string.

XPath 2.0 can only convert single items (or sequences containing
single items) to a string; if a sequence has more than one item, or
holds a node whose typed value is a sequence of more than one item,
then it throws an error.

XPath 2.0 also makes the distinction between casting to a boolean and
the "effective boolean value" of an expression. The former casts
a sequence that holds a single node with a typed value of boolean
false to false, whereas the latter would cast the same sequence to
true (since the sequence holds a node).

In XSLT 2.0, <xsl:value-of> (with a separator attribute) converts its
argument to a string by doing the concatenation described above, such
that:

  <xsl:value-of select="(1, 2, 3)" separator=" " />

creates a text node with the value "1 2 3".

I'm ambivalent about whether relying on the first-item semantics of
XPath 1.0 is a bad thing to do and whether forcing people to use [1]
when they want to pick the first item in a sequence is too much of a
burden. I don't know what others think?

>>   [Issue: Do we need any more built-in data types?]
>
> The only one I can think of is functions. A language that can't pass
> those around is very quickly limited.

I agree that we need a module that has functions as a data type and
the functions, operators etc. to back that up. I don't think that a
function data type belongs in the core, though -- the core should just
about cover the very basic things that people want to do without being
too much of an implementation burden; it's OK if that's limited.

Cheers,

Jeni

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