RE: IPR tests, part 1

David,
  On tests 150, 151, I will change the language to allow for JSON in-line inside of <data> (for processors that support JSON).  If I do that, will the test then work?

On 351, the point of including the sendid in the SCXML Event I/O processor is that if the receiving side knows the sendid, it can include information in its response letting the original sending side know which <send> it is receiving a response to.  That information could be put in <param> in the original <send>, but only if it's not using <content>.  So including it automatically in the event is a little more flexible.  

For ECMA <foreach>, the current spec language seems to me to allow the generality you want.  I guess that we can add that shallow copy is not required for immutable objects such as strings.  Is there anything else you would change? 

C.2.11 <foreach>

In the ECMAScript data model, the SCXML Processor MUST support iteration over objects that satisfy instanceof(Array) in ECMAScript. It MAY support iteration over other types of objects. The legal values for the 'item' attribute are legal ECMAScript variable names. The iteration order is the order of the underlying ECMAScript array, and goes from an index of 0 by increments of one to an index of array_name.length - 1. Note that since shallow copy is required <foreach> assignment is equivalent to item = array_name[index] in ECMAScript. Note also that the assigned value could be undefined for a sparse array.

- Jim


-----Original Message-----
From: David Junger [mailto:tffy@free.fr] 
Sent: Tuesday, April 09, 2013 1:45 PM
To: www-voice@w3.org (www-voice@w3.org)
Subject: Re: IPR tests, part 1

Le 9 apr 2013 à 17:54, Jim Barnett a écrit :

> 150 and 151 are duplicates; moreover they produce a <data name="Var3">[1, 2, 3]</data>.
> According to C.2.1, that should be interpreted as the string "[1, 2, 3]" rather than an actual array. Which is obviously not what the test intends. It should transform into <data name="Var3" expr="[1, 2, 3]" /> instead.
>>> Yes, the tests are the same, but they are testing two different assertions.  My document structure doesn't give me an easy way of indicating that if you pass one test, you satisfy two assertions, so I repeat the test.
>>> It's certainly would be easier to use an expr to create the array, but the opposite is true in XPath.  Is there any notation we can use that would create an array in-line?  Could we use JSON?  

The value you provide is valid JSON, it's just that the current spec doesn't say it should be parsed as JSON.

> test 351 expects the first sent event to have a sendid, just because the <send> element had an 'id' attribute. My understanding of 3.14 is that an id must be generated for each <send> that doesn't have one, but according to 5.10.1 that id must be included in the event when and only when it is an error event resulting from a failed <send>.
>>> Hmm, you're right and this is a bug.  The SCXML Event I/O processor 
>>> specifies that this should be filled in, but section 5.10.1 says 
>>> that it's only filled in error cases. I think that 5.10.1 should be 
>>> changed to say it's filled in if there's an error or if the sender 
>>> specifies it  (with a reference to the Event I/O Processors section 
>>> for details.)

What would be the purpose of the target having the id of the originating <send>? it's a <send>, you can't do anything with its id. If you want the target to know something you should put it in a <param>.

> test 457 works, but the comments say more than the test. First, an array can be instanceof some other global's Array object, in which case, annoyingly, it will tell you that it is not instanceof (your own global's) Array.
> Second, there is no good reason why any iterable object couldn't be iterable with <foreach>. ECMAScript's for...in construct can iterate over Arrays items, other objects's properties (we should say to iterate only over the object's own properties, since that is what you want to do 99% of the time), and the characters in strings.
> In the case of strings, it is unnecessary to make a shallow copy because strings are immutable.
>>> What should the assertion/comment be, then?  The current text was suggested by someone a long time ago.  It's fine with me if we want to generalize it or modify it.

well, the general <foreach> definition should be that it can be used to iterate over any structure that is iterable in the datamodel and has key-value or index-value pairs. The order of iteration should be the same as usual in the datamodel, i.e. in ECMAScript it is unspecified for most objects.

In the case of ECMAScript, <foreach> should be(have as if) implemented with:
for(key in array) if (array.hasOwnProperty(key)) {
	item=array[key]
	execute <foreach> content.
}

which means that it should refuse an 'array' value if and only if ECMAScript would complain about it too. That's easy to implement and to understand.

			David

Received on Tuesday, 9 April 2013 19:36:01 UTC