RE: ISSUE-822

My comments set off with >>>>

From: David Junger [mailto:tffy@free.fr]
Sent: Thursday, January 17, 2013 5:36 AM
To: VBWG Public (www-voice@w3.org)
Subject: Re: ISSUE-822


Le 16 jan 2013 à 21:13, Jim Barnett a écrit :


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)'.

Since this is in the ECMAScript-specific section, I would simply remove the example and rely on the fact that the interpreter should raise an error.execution just like for any other executable content ECMAScript error. Refer to the ECMAScript spec for when that happens.
There is still the case when you try to assign to an existing but read-only property, which doesn't raise an error in ECMAScript and simply doesn't do the assignment. Detecting that would require checking the value after the assignment, which isn't so bad as what I must do to prevent assignment to undeclared locations that would otherwise be allowed.

>>>> I think that we should change the example to '(for example, if  it attempts to assign to a read-only property)'.  Just to remind developers that they need to catch this case.   The cases where Jscript raises an error should be obvious, but this one might be easy to overlook.



D.3.1 second paragraph:


- 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.

Yes, you can initialize some values, which depend on the exact event constructor you use (CustomEvent only allows "detail" in addition to the standard "bubbles" and "cancelable"). However, you cannot set the event's timestamp, srcElement, and some other. You also can't change the initializable properties after initialization (however that's not an issue with <send> since a reference to the generated DOM event is not available to SCXML scripts).

>>>> We can change the prose to "The Processor MUST populate any other settable attributes of the event..."  For example, if you're using SCXML to emulate a user, it will be useful to allow it to set the x and y attributes of click events, etc.  Any param or namelist entries that don't correspond to settable attributes will be placed in 'detail'.

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.

The DOM specification requires all Nodes to implement EventTarget (http://www.w3.org/TR/domcore/#interface-node)
Therefore, any DOM-compliant implementation already has this requirement. And implementations that don't support the DOM are unlikely to support DOM Events.

However, I do not think <scxml> elements embedded in other markup should even try to catch DOM Events sent to them and put them in the external queue. The reason for that, in addition to the issues raised before, is that there can be two other potential uses for such DOM Events, which of course won't be part of SCXML 1.0 but I'll discuss it to explain my position:

What I'm doing with JSSC at the moment is that the <scxml> element is the default target for <send type="DOM" /> events, and authors can add listeners for those events directly on the <scxml> element or on the path to it. The interpreter also sends DOM Events to notify the external markup when it is ready to run, when it takes a transition, when it terminates, etc. So it'd be annoying if it tried to also catch these and re-inject them instantly in its external queue.

Alternatively or in addition to that, when an event is added to the external queue (from any source) in an SCXML document within DOM-compliant markup, instead of queuing the event immediately, a corresponding DOM Event could be sent to the <scxml> element. That would allow external markup to react to this SCXML event and possibly intercept it. This behavior would be consistent with events such as the "submit" event sent to itself by an HTML <form>.

So I would very much prefer that SCXML interpreters have an API with a different method (such as "fireEvent" that I suggested and use in JSSC) for sending events to their external queue than the <scxml> element's EventTarget-inherited "dispatchEvent" method. Authors are of course free to add a simple listener for particular DOM Events that would call fireEvent. It's so simple it hardly deserves its own API method:
<scxml>.addEventListener("type", function(e){ this.interpreter.fireEvent(e) })

>>>> So I think that we can just remove all reference to EventTarget from the spec.  The current draft does require that the platform implement a function like the one you describe, but doesn't specify its name or arguments.  The reason for this is that the W3C requires two implementations of each feature.  The only person besides you who is likely to have an implementation is Jakob, and as I recall he does things slightly differently.  I'd hate to lose the whole DOM Event I/O processor just because he called his function something different.


- 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?

Ah, yes, I missed that. Typeless DOM Events are pretty much useless.

>>>> OK, we'll leave the spec as is.

                                    David

Received on Thursday, 17 January 2013 15:10:54 UTC