- From: Josh Spiegel <josh.spiegel@oracle.com>
- Date: Thu, 8 Oct 2015 07:09:43 -0700 (PDT)
- To: Michael Kay <mike@saxonica.com>
- Cc: "Robie, Jonathan" <jonathan.robie@emc.com>, Public Joint XSLT XQuery XPath <public-xsl-query@w3.org>
Makes sense. Let’s also make the enclosed expression optional and modify string-join to accept xs:anyAtomicType* instead of xs:string*.
Thanks,
Josh
> On Oct 8, 2015, at 1:45 AM, Michael Kay <mike@saxonica.com> wrote:
>
>
>> On 8 Oct 2015, at 03:53, Josh Spiegel <josh.spiegel@oracle.com> wrote:
>>
>>
>>> each string constructor interpolation $i is evaluated, then converted to a string using the expression string-join($i ! string(.))
>>
>> I agree with Mike about atomization and lean towards separating the values with spaces because it seems more consistent with the behavior of constructor content (3.9.1.3 Content, e. iii) and sequence normalization. e.g.
>>
>> ($i ! (. cast as xs:string)) => string-join(‘ ‘)
>
> I’m OK with that. (Can’t help feeling that’s what string-join() itself should do: string-join(1 to 4, ‘ ‘) => “1 2 3 4”.)
>>
>> (the cast expr will atomize)
>>
>>> StringConstructorInterpolation ::= "`{" Expr "}`"
>>
>>
>> Can we make it “Expr?” instead of “Expr”
>
> If we do that, I think we should do it in EnclosedExpr as well.
>
> Michael Kay
> Saxonica
Received on Thursday, 8 October 2015 14:10:18 UTC