Re: SCXML: DOM Events I/O

David,

You and Jacob bring up a number of good points, and it's clear that the
current specification does not define enough of what would be needed for
a useful integration of SCXML into a browser.  There are two sorts of
issues that I would like to distinguish:

1.        Ideas like a non-xml representation of the language,  a
notation for binding a state machine to a specific DOM node, JS
functions for injecting events into SCXML, etc.  are all quite
interesting.  Things like this would undoubtedly be necessary for a
fully-functional integration.  However they all lie outside of the scope
of the spec.  (For example, the SCXML spec cannot define extensions to
HTML.)  We could prepare a separate document describing this full
integration.   I would be particularly interested if browser vendors
wanted to participate.  

2.       There are issues of what the definition of the DOM Event I/O
processor should be in the current spec.  By itself it will not be
enough to define the full integration, but it shouldn't hinder the full
integration either.  Here are a few items that I have gleaned from your
emails:

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

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. 

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.

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.

 

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.  

 

Let me know what you think.