Re: Fixes to string constructors now in internal WD

> 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(‘ ‘)

(the cast expr will atomize)

> StringConstructorInterpolation	   ::=   	"`{" Expr "}`"


Can we make it “Expr?” instead of “Expr”

In the past, users have complained that they can’t comment out the content of an enclosed expression without creating a syntax error.  e.g. 

   <div> 
      ….      
      {
        (: TODO fix this query 
        for $x in …
        return …
        :)
      }
      ….
   </div>

The above example produces a compile error because you need an Expr in the enclosed expression. 

I prototyped string constructors and ran your examples.  I noticed the following typos:

(1)

    This is missing a back tick in the close of the string constructor:

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

(2)

This example is a mix of XQuery and JSON:

    {
      "name": "Chris",
      "value": 10000,
      "taxed_value": 10000 - (10000 * 0.4),
      "in_ca": true
   }

Should it be?

   map {
      "name": "Chris",
      "value": 10000,
      "taxed_value": 10000 - (10000 * 0.4),
      "in_ca": true()
   }

(3) 

This example:

declare function local:prize-message($a) as xs:string
{
``[Hello `{$a.name}`
You have just won `{$a.value}` dollars!
…

Has the wrong lookup operator syntax.  It should be:

declare function local:prize-message($a) as xs:string
{
``[Hello `{$a?name}`
You have just won `{$a?value}` dollars!
…

(the same applies to the following 2 prize-message functions)

(4) 

For the <div> example, there are two spaces before the closing </div>.  I would remove the two spaces and then correct the output whitespace to this:

<div>
    <h1>Hello Chris</h1>
    <p>You have just won 10000 dollars!</p>
    <p>Well, 6000 dollars, after taxes.</p> 
</div>

(5) There is no indenting in the final prize-message function. 

(6) The final prize-message function is missing an interpolation: $a.value should be `{$a?value}`  

Thanks,
Josh



> On Oct 6, 2015, at 3:20 PM, Michael Kay <mike@saxonica.com> wrote:
> 
> 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 Thursday, 8 October 2015 02:53:56 UTC