Re: SCXML Test 354 uses datamodel-specific <content>?

What would happen if conf:eventDataVal inserted single  quotes around 
the value in the ECMA transform?  So the source would be 
conf:eventDataVal="foo".  In ECMA, that would  turn into 
cond="_event.data == 'foo'", but Lua could leave out the quotes. What 
would happen in test 179, where we have conf:eventDataVal="123"?  Would 
it be a problem to quote that in ECMA?

- Jim
On 6/30/2014 9:37 AM, Stefan Radomski wrote:
> Which single quotes are you referring to? For me the XSLT generates [1]. There are only single quotes in line 43:
>
>    <transition event="event2" cond="_event.data == 'foo'" target="pass"/>
>
> Removing these would cause foo to be evaluated as an (undeclared) variable and cause the test to fail. There used to be a time when the XSLT would add quotes around <content>foo</content> in line 40, but those were sad times :)
>
> I have no real opinion on this and can adapt my implementation easily - I just want consistency. Keep in mind that not all DMs use double quoutes to delimit strings. If I remember correctly, our implementation does the following:
>
> 1. <content> has only a single child node of type TEXT or CDATA =>
> 1.1 It will parse as JSON => KVPs / JSON / elaborate event.data structure
> 1.2 It will not parse as JSON => space normalized for event.data string literal
> 2. <content> has a single child not of type text => content’s child node will become event.data DOM node in JS
> 3. <content> has multiple childs => content node itself will become event.data DOM node in JS
>
> This worked for us but we are open to suggestions.
>    Stefan
>
> [1] https://github.com/tklab-tud/uscxml/blob/master/test/w3c/ecma/test354.scxml
>
> On Jun 30, 2014, at 15:16, Jim Barnett <1jhbarnett@gmail.com> wrote:
>
>> Gavin,  Stefan, and David,
>>   My only concern is that Stefan and David's implementations pass 354 in its current form, and I don't want to break their systems. Stefan and David, is it ok with you if we remove the single quotes around 'foo' in 354?  Or can we rely on conf:eventDataVal to insert quotes as needed?  (We could rename it conf:eventDataStringVal to make it clear.)  Or do we need eventDataStringVal and eventDataIntVal?
>>
>> - Jim
>> On 6/29/2014 8:19 PM, Gavin Kistner wrote:
>>> I locally modified my TXML to use the same strategy as 179 (use unquoted 123 in both locations) and it works well enough for me. Is that a change you’d feel OK with making, so that I can remove my local override?
>>>
>>> On Jun 20, 2014, at 8:34 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:
>>>
>>>> We have had more problems with quotes than anything else in the tests - putting them in, taking them out, doubling them, undoubling them.  Does anyone else have an opinion on what to do with these tests?
>>>>
>>>> On 6/19/2014 9:27 AM, Gavin Kistner wrote:
>>>>> test179.txml has:
>>>>> 	<send event="event1"><content>123</content></send>
>>>>> 	<transition … conf:eventdataVal="123” … />
>>>>>
>>>>> My data model evaluates the text content of <content> as code, so that <content expr=“123”/> is the same as <content>123</content>, and my transformation of the tests converts the condition above to <transition cond=“_event.data.val==123” … />.
>>>>>
>>>>> However, test354.txml has this:
>>>>> 	<send  event="event2"><content>foo</content></send>
>>>>> 	<transition … conf:eventdataVal="'foo'” … />
>>>>> (notice the single quotes around the ‘foo’ inside the double-quotes).
>>>>>
>>>>> This breaks my data model, since evaluating foo as a Lua expression results in nil, not the string ‘foo’. If I switch my data model to interpret the text child of <content> as a string instead, then test 179 would fail.
>>>>>
>>>>>
>>>>> I can modify this test to change to <content>’foo’</content>, but I think this is too specific to ECMAScript and Lua data models. I would suggest that at a minimum this test should match the pattern from test179. However, ideally, I am afraid that more conf: is really needed here, to be properly generic for data models.
>>>>>
>>>>>
>>>> -- 
>>>> Jim Barnett
>>>> Genesys
>>>>
>> -- 
>> Jim Barnett
>> Genesys
>>

-- 
Jim Barnett
Genesys

Received on Monday, 30 June 2014 13:54:41 UTC