ISSUE-831: Should default <send> target be specific to the I/O Processor? [SCXML-LC-Comments]

ISSUE-831: Should default <send> target be specific to the I/O Processor? [SCXML-LC-Comments]

https://www.w3.org/Voice/Group/track/issues/831

Raised by: James Barnett
On product: SCXML-LC-Comments

>From David Junger [tffy@free.fr]

"If neither the 'target' nor the 'targetexpr' attribute is specified,  the SCXML Processor must add the event will be added to the external event queue of the sending session."

Beside the bad syntax, I think this should only be required for type="SCXML". Other types should be able to define their own default target.
For example, it makes sense for type="DOM" to default to some element in the parent DOM (like the <scxml> element if present) rather than the SCXML session itself.

   David

Response from Jim Barnett

Interesting point.  I'll clean up the prose.  What should the default target be for other types?  If we push the default down into the individual I/O processors, we will need to give a clear specification of the default for each (though one default could be that a certain I/O processor raises an error if 'target' isn't specified.)

- Jim

Further response from David:

Defining the default target for "DOM" properly would require that we first define some of the API so we have a clear and possibly mandatory (if it implements the DOM IOproc) "DOM anchor" property for the SCXML interpreter (even if that anchor's default position in the DOM is implementation-specific).
It's not complicated per se, except that we don't have a section about API in the spec.
Having used DOM events a lot, I can say it's very pratical to have a default target. Specifying a target has its uses, but sometimes you just want to pass a message to some JavaScript. I got similar feedback from other SCXML users.
To be honest, if the default DOM target doesn't make it in SCXML 1.0, I would remove it from my implementation just for the moment it takes to pass the conformance test.

I can't think of a useful default and consistent URL for basichttp. I'd say raise an error.
A useful default could be the origin of the last received basichttp event, but that's too brittle.

   David

Received on Tuesday, 12 February 2013 12:49:26 UTC