Re: Change to SCXML Test 298

I think that's a reasonable solution.

- Jim
On 6/29/2014 8:17 PM, Gavin Kistner wrote:
> This is not a pressing issue for me, since I’ve sort of hacked my runtime to work around it. However, for completeness, let me rephrase what I was trying to say:
>
> in my Lua data model, any value is valid for the name of a data model location. I can store a value with the key “foo” or “foo bar” or “!@#$” or even an empty string, or even non-string values. The one exception to this supported by the spec is that I can’t write to system variables (starting with an underscore). So, the way that I supported conf:invalidLocation was to write location=“_no”. And that worked great for writing.
>
> When it comes to reading, however, the game is slightly different. I *can* read from _no or _x legally. These locations that are invalid for writing are valid for reading. So, I was asking for a new conf: attribute to be added to cover these different semantics.
>
> However, I’ve decided that though I can support an empty string as a location name, nobody sane would use that. As such, I’ve hardcoded an empty string as an invalid location for reading/writing in my runtime, and switched my conversion of conf:invalidLocation to create location=“”.
>
> All is well in my world at this point with respect to this test. :)
>
>
> On Jun 20, 2014, at 7:45 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:
>
>> There is no conf:invalidParamLocation in the tests right now.  How would  it differ from conf:invalidLocation?  I'm maintaining sample JS and Xpath  xslt files so I would  need to know what to put in them.
>>
>> P.S.  I remember a bit more on the discussion of invalid values for 'name' in <data>.  Since 'name' is required to be of type 'id', if you put in an invalid name, you have a syntactically invalid  document. The conformance section of  the spec says that the behavior of the interpreter is undefined when it is given an syntactically invalid document, so there's no way to write a test for this case (the document will fail schema validation, but you're not required to validate.)
>>
>> On 6/19/2014 6:29 AM, Gavin Kistner wrote:
>>> On Jun 18, 2014, at 8:50 AM, Gavin Kistner <phrogz@me.com> wrote:
>>>> I think that in test 298 perhaps this code:
>>>>     <donedata>
>>>>      <param conf:name="3" conf:location="2"/>
>>>>      </donedata>
>>>>
>>>> should be changed to this:
>>>>     <donedata>
>>>>      <param conf:name="3" conf:invalidLocation=""/>
>>>>      </donedata>
>>>>
>>>> Per previous discussions, just because a location was not predeclared does not make it invalid in all data models. (Right?)
>>>>
>>>> Perhaps there should further be an invalidName, perhaps tested independently. (Perhaps there already is and I’ve not yet reached that test :)
>>> Actually, I wish to change this suggestion. invalidLocation is for *writing* to an invalid location during <assign>. In this case (and in test 343) we want to READ from an invalid location for param. As such I would recommend instead conf:invalidParamLocation for both tests.
>>>
>>> (In my very permissive data model, I am able to create an invalid location for <assign> by using a system variable, e.g. starting with underscore. This is valid for reading, however, and so I need another, different technique to simulate this.)
>> -- 
>> Jim Barnett
>> Genesys
>>

-- 
Jim Barnett
Genesys

Received on Monday, 30 June 2014 13:20:16 UTC