Re: SCXML: DOM Events I/O

Just realized I'd sent the reply only to Jim… stupid Reply-to headers…

> 2.
> a.       Should all events sent from the state machine have type CustomEvent, with any data converted to a  string and stored in the ‘detail’ property?  If we say this we must say that the value of the ‘event’ attribute on <send> will be ignored.  Alternatively, we can say that  CustomEvent is the default if ‘event’ is not supplied, while if ‘event’ is provided, it defines the type of the event.  (But it that case where does the data go?) 

DOM Events all have a "type" property which is equivalent to the "name" property of SCXML events. But the baseline Event interface cannot carry any data. Thus, there are Event subclasses, one (CustomEvent) defined in the DOM spec itself, and others (MouseEvent, NetworkEvent, etc) defined for HTML ; these subclasses have extra properties, such as "detail" for CustomEvent,  "button", "clientx", "clienty", etc for MouseEvents, and so on. Those properties are set when the event is initialized.
see http://www.w3.org/TR/dom/#interface-event

So, we still use the "event" attribute for the DOM Event's type.
The CustomEvent.detail property can be any JS value, no need to convert to a String (but we might want to stringify some stuff to follow the encapsulation principle, despite it being a lost cause in the browser).

There remain the issue of "cancellable" and "bubbles".
"cancellable" doesn't make sense since <send> is fire-and-forget.
"bubbles" can be useful in a complex HTML interface with multiple listeners for the same event, so I'd activate it just in case. It can always be ignored by the listeners. Ideally, there would be a (DOM-specific) "bubbles" attribute on the <send> SCXML element.

> b.      For the value of ‘target’, we could say “Processors _must_ support CSS syntax and _may_ support XPath syntax”.  Or we could make both ‘must’s, but  then we have to make sure that there never could be any confusion between the two.

It's not possible to guarantee there *will never* be an intersection between the two languages, of course. I think most authors will be happier with guaranteed CSS support. You could state that a "target" value _must_ be interpreted as a CSS selector first, but that if it doesn't work out, the implementation _may_ try XPath, and queue an error only if that doesn't work either (By the way, what sort of error would that be? Personally, I like "error.DOM").
Both syntaxes are built-in so suporting them on modern browsers is a piece of cake.

> c.       For events the state machine receives, it makes sense to say that the name is the event type and that the actual event goes in _event.data.

Indeed. Or rather a shallow copy of it, since its properties may change later. Also, DOM Events in the browser have a srcElement property which might be converted to a valid target and used as the event's origin in SCXML.

> d.      I understand the arguments that we shouldn’t require that the SCXML root be a node in the DOM.  Maybe we can say:  if the root is a node in the DOM, then any events targeted at it are converted into SCXML events.  Furthermore, implementations may support other ways of injecting events into the state machine.

No, we can't. The only way to handle an event in the DOM is to set an eventListener for its type (or use the old DOM0 methods). Unlike in SCXML, there is no way to set a "wildcard" eventListener. That (and other reasons I've mentionned in earlier messages) is why we must have other ways of queueing external events. These other ways are
- a registration method similar to EventTarget.addEventListener, but with no callback
- a direct method similar to EventTarget.dispatchEvent, but without a return value and more flexible
- attributes on HTML elements, as Jacob suggested, that fall outside the scope of the recommendation

see http://www.w3.org/TR/dom/#interface-eventtarget

> As a practical matter, we’re  trying  to finish up the spec quickly and I don’t think that there is any way of  guaranteeing real interoperability without producing the second spec that I mentioned above.  Within our current scope, though, I’d like to clean up the DOM Event I/O definition so that it doesn’t force anybody to do things the wrong way.  Do you think that it is sufficient to address points a-d above?   You and Jacob have the two currently active JS implementations that I’m aware of, so I think that whatever the two of you agree to is a good basis for the spec.

I think the API is also necessary. It's not all specific to a browser implementation either.
At the very least we need a method for adding an event to the external queue.

I'm OK with leaving the DOM anchor out of it and keeping it for an HTML extension. There are a lot of issues that a native browser implementation would resolve, too.

			David