RE: updated SCXML draft

David,
  I'll look at your other comments later, but on C.2.11 I think that you may be looking at an outdated version.  The current prose reads  " The iteration order is the order of the underlying ECMAScript structure, which goes from 0 to length-1 in the case of arrays and strings".  

A question related to this:  you say that there are objects for which the iteration order is not defined.  Is it possible to iterate over them?  Is the idea that the platform would determine its own platform-specific order in this case?  If so, should we say "The iteration order is the order of the underlying ECMAScript structure, where this is defined.  In the case of arrays and strings, this goes from 0 to length-1".

-----Original Message-----
From: David Junger [mailto:tffy@free.fr] 
Sent: Thursday, April 11, 2013 2:59 AM
To: Voice Public List
Subject: Re: updated SCXML draft

Le 10 apr 2013 à 23:45, Jim Barnett a écrit :

> C.2.5
>> The Processor may convert the expression result to a string in contexts where a string is expected
> Please, no. [.]
>>> This comment is inconsistent with your comment on C.2.8.1.

This comment was about C.2.5 Value Expressions. That is, expressions that are always supposed to be an ECMASCript value (expr and cond), unlike <content>'s content and incoming event data.
We must not, ever, treat the attribute value of 'expr' as a string instead of evaluating it as an ECMAScript expression, the way you did in the example in C.2.1.

I may have misread your intention. If you mean that the interpreter should simply call toString() on the result of evaluating the expression, I still disagree. ECMAScript variables don't have a type, only values do. The only variables that have constant-type values are either read-only or DOM properties that internally convert whatever you assign to them. We have some read-only variables in SCXML but none of the second sort, as far as I can remember. If we did, it would not be the <assign>'s job to do the conversion anyway.


> C.2.8.1
> 
>>> See above on C.2.5.  I don't see how you can maintain both comments.

see above :p

>>> I think this will have to remain as an issue for a future release.

Well, fine, but don't prevent implementations of SCXML 1.0 from going ahead with it.

>>> As for seeing the XML document, do you really need to examine the document inside the script while it's running?  If it's a debugging issue, you can handle it by platform-specific means.

And what would be gained by having the text of an invalid XML document, as opposed to the error document (assuming it is indeed XML, which is a good assumption when the MIME type says so)? At least with the error doc I can see the bug immediately.

Also, it's doubtful whether the XML parser would recognize a HTML document and switch to the appropriate algorithm or produce an error and cause the algorithm you propose to fall back to text straight away. I know that the DOMParser object does the latter, and you have to tell it explicitly to parse as HTML unless it is called as part of XHR, which looks at the Content-Type header and calls the DOMParser based on that.

> C.2.9
> should say something about the platform being unable to serialize at all. Do we raise an error.execution or just give a warning?
> 
>>> I'm not sure.  We say that the platform can fall back to a platform-specific method, which may include loss of data.  So it can serialize anything as "" and be in technical compliance.  I don't think it makes sense to have a 'must' after a 'may' because it's then not clear what the 'must' really means and when it applies.  That's why I left it with just 'should provide a warning' though we could extend it to say "loss of data or unable to serialize at all" which would be clearer.

What I was thinking about was the very clear distinction between when JSON.stringify() will give you some result (no matter how lossy), and when it will throw an error. Handling that can be done before the 'may'.


> C.2.11

> The iteration order is the order of the underlying ECMAScript array


Would you mind adding "For arrays, " in front of that?

			David

Received on Thursday, 11 April 2013 13:55:36 UTC