Re: Fixes to string constructors now in internal WD

I filed bugs to track the issues in this thread:

    Bug 29184 - Modify fn:string-join to accept xs:anyAtomicType* instead of xs:string*
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=29184

    Bug 29185 - The expression inside curly braces should be optional
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=29185

    Bug 29186 - The StringConstructorInterpolation expression should be atomized and converted to a space separated string
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=29186

    Bug 29187 - [editorial] Errors in string constructor examples
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=29187

Thanks,
Josh

> On Oct 8, 2015, at 7:23 AM, Robie, Jonathan <jonathan.robie@emc.com> wrote:
> 
> I like both changes. 
> 
> 1. Changing EnclosedExpr to "{" Expr? "}" is obviously a grammar change (@mdyck), and would require WG approval on Tuesday, I think.  I really like it, because I often write a set of empty functions before I write the function expression, e.g.
> 
> declare function local:dingsbums($x)
> {
> };
> 
> With the current grammar, I have to put something in there, so I write something like this:
> 
> declare function local:dingsbums($x)
> {
>    1
> };
> 
> 2. Changing string-join to accept xs:anyAtomicType* is definitely more convenient. Should string-join() also use ' ' as the default separator?  I can always specify string-join($x, '') if I don't want that.  
> 
> Jonathan
> ________________________________________
> From: Josh Spiegel [josh.spiegel@oracle.com]
> Sent: Thursday, October 08, 2015 10:09 AM
> To: Michael Kay
> Cc: Robie, Jonathan; Public Joint XSLT XQuery XPath
> Subject: Re: Fixes to string constructors now in internal WD
> 
> 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:56:59 UTC