RE: Behaviour of fn:string on sequences

> Is there an 
> overview document that explains what all the different specifications 
> are for and is a good place to start learning about it. At 
> the moment I 
> am blindly jumping between them looking for the bits and 
> pieces that I need.

The XPath language spec is the best place to start. Read that until you find
something you don't understand, then look in the other documents to see if
they help.
> 
> So let me get this straight (ignoring XPath 1.0 compatability mode).
> 
>   o  An empty sequence results in an empty string.
>   o  A sequence with one item is the same as passing in a single item.
>   o  A sequence with more than one item is an error.
> 
> That seems very inconsistent to me. Why does fn:string not take a 
> sequence ? It could return a string consisting of the 
> concatenation of 
> the results of applying fn:string to each item in the sequence with 
> possibly a space separator between them, although the 
> separator could be 
> supplied as an optional second parameter.

That specification might feel like a good one to you, but it would be
completely incompatible with XPath 1.0. The fact that compatibility mode is
off doesn't mean we can throw backwards compatibility out of the window: we
have to make it feasible for people to move forwards.
> 
> How do I get the string representation of a sequence ?
> Is there another function to do this ?

Yes, the string-join function is there for this purpose.
> 
> On a similar note, the specification for fn:boolean says ".... If 
> $srcval is an atomic value ....". However, fn:boolean takes a 
> sequence 
> so I presume that $srcval is an 'atomic value' if the 
> sequence contains 
> a single item. However, this behaviour does not appear to 
> have any real 
> meaning when applied to a sequence.

I'm not sure what you mean by "real meaning".

> e.g. I often want to be able to tell whether a sequence is empty. In 
> XPath 1.0 if I gave it a node set then it would return false 
> if it was 
> empty and true otherwise. This is also how it behaves in XPath 2.0. 
> However, if I give it a sequence of atomic types (as opposed to a 
> sequence of nodes) then it does not tell me whether the sequence is 
> empty as a non empty sequence containing a single atomic value could 
> evaluate to false.

Correct. In XPath 2.0 the values that return false when supplied as
arguments to the boolean function are exactly the same as the values that
returned false in XPath 1.0: an empty node-set, the boolean false, a numeric
zero, and the string "".

If you want to test whether a sequence is empty, don't use the boolean()
function, use the empty() function.
> 
> I understand that this is a consequence of treating a sequence 
> containing a single item and that item the same. However, is 
> that really 
> a good idea given the strange behaviour that it causes in relatively 
> simple functions such as these two.

I think the strangeness in these two functions is because they were both
carried forward from XPath 1.0 which had a different data model. This
doesn't make the data model wrong. The reason that a single item is the same
as a sequence of length one in the XPath model is because that's the way it
is in XML Schema.

Michael Kay