ISSUE-822

David,
Here are my replies to your specific comments, set off by '>>'  (if you will keep 'ISSUE-822' in the subject line of any reply you make, it will make it easier for us to track the discussion.)

C.2.6:
The value at an undefined location is undefined, but it does not necessarily prevent the ECMAScript interpreter from assigning a new value to it (if the location points to a yet-undeclared property of an existing object). It may be desirable to let the ECMAScript datamodel behave like ECMAScript and allow such assignments to undeclared locations, raising an error when and only when the ECMAScript interpreter does. Certainly wouldn't hurt my implementation, I'd just have to remove some ugly code.

>> Yes, I think that we can make this change.  The intent is that the SCXML interpreter raise an error if it can't change the value at the location.  The '(for example...)' clause is just for illustration.  We could drop the '(for example..)' clause altogether or say something like '(for example, if 'location' refers to a non-existent object)'.


I have noticed a few critical problems with the new definition of the DOM send type. Sorry ;)

D.3.1 second paragraph:
- the name of the CustomEvent's custom property is "detail" without an "s"

>> This can be fixed.
- in the browser, it is impossible to set the value of many event properties (they are read-only to content JavaScript) so a browser implementation cannot be conformant with the current requirement that any event property named in namelist or <param> be set to the corresponding value (no error will be raised by the attempt, it will simply leave the value unchanged).

>> Can you explain some more here?  In the DOM 3 Event spec, I see functions like 'initUIEvent' that can be used to set the attributes of the event.  (In InitMouseEvent, you can set screenXARG, ScreenYArg, etc.)  When we send a DOM event, doesn't the JS code get to create it and call this function?  That's what I had in mind.

D.3.2:
- It is not practical to prevent Element instances (such as those representing SCXML states and other elements) in the browser from implementing the EventTarget interface, and neither is it practical (without native support) to have an inline <scxml> document in HTML (an <scxml> tag with a 'src' attribute is fine).
- It is irrelevant at this point that the <scxml> element and its children implement it, since it cannot be used to listen to all DOM events anyway, because unlike with SCXML events, DOM events must have a registeredd listener in their name before anything will happen. Just cut that out of the recommendation.

>> Yes we can remove this.  Do we want to leave the requirement that <scxml> implement EventTarget?  It would be nice to be able to send events to it, even if the author does have to add an appropriate listener.  We will just drop the requirement that other nodes not implement it.

- Nothing about <content>? For CustomEvents, it shouldn't be a problem to be consistent and say that the <send> element may have one <content> child excluding any namelist and <param>s, and that the event's "detail" property must be set to the child's text contents (or possibly to that content interpreted as JSON).

>> This could be added, but since a <content> child is incompatible with 'event', we would end up with a DOM event with no 'type' attribute (since 'event' is used to populate 'type), and I thought that would be problematic.  Is that true, or would developers not have a problem with this?



As I have pointed out before, the 'basichttp' I/O Processor is incompatible with a client-side implementation, but since that Processor is optional it's all right.

>> Agreed.  In general, the features are defined as optional when they are not useful in all environments.  The basicHTTP processor has turned out to be useful in various server environments, but we know it's not implementable in a client, so it's  optional.