Re: Fixes to string constructors now in internal WD

I don’t think the spec is really clear on what happens when an interpolated expression evaluates to a sequence, and I don’t think we’ve decided what we want to happen.

The example

``[`{ $i, ``[literal text]``, $j, ``[more literal text]`` }`]`

which supposedly evaluates to

"1 literal text 2 more literal text”

implies (a) that the interpolated expression is allowed to evaluate to a sequence, and (b) that the items in the sequence are output space-separated.

This might be what we want to do, but it doesn’t seem consistent with what the spec says earlier:

"each string constructor interpolation $i is evaluated, then converted to a string using the expression string-join($i ! string(.))”.

For what it’s worth, the spec I assumed when writing tests was, in effect:

* The result is the concatenation of the strings obtained from the fixed (StringConstructorChars) and variable (StringConstructorInterpolation) parts, in order

* The string obtained from a fixed  (StringConstructorChars) part comprises the characters in StringConstructorChars

* The string obtained from an interpolated expression E is the value of xs:string(data(E)) (that is, the result of evaluating the expression, atomizing the result, and casting the result to a string).

To put it another way, if the sequence of fixed and variable parts is represented as F1 V1 F2 V2 … Fn then the result of the expression is

concat(F1, V1, F2, V2, … Fn)

I’m not saying that’s only possible or best possible spec, but if we want something else then we need to be rather more clear about exactly what it is. Consistency with concat() seems to have some merit.

Using string(.) without atomization seems a bad idea. We have very few operations that use the string value of a node rather than the atomized value, and I don’t see why this expression shouldn’t follow the normal default of atomization.

Michael Kay
Saxonica


> On 6 Oct 2015, at 22:18, Robie, Jonathan <jonathan.robie@emc.com> wrote:
> 
> The fixes to string constructors that we discussed in today's call are now in the internal Working Draft.
> 
> Josh Spiegel is now listed as an editor.
> 
> Jonathan

Received on Tuesday, 6 October 2015 22:20:45 UTC