some comments on an SCXML draft

[These are some old-ish notes from the Plenary week.  Sorry if these
are things you have dealt with already.  - Al]

Reference: http://www.w3.org/TR/2006/WD-scxml-20060124/

** event identification [this idea was discussed/accepted at the MMI
meeting on Tuesday IIRC]

ref: section 4.4 <invoke> second paragraph

In the current draft it is stated that detached-process response
events can be identified by the ID of the state that spawned the
event being responded to.

I don't believe that this is true, and that the computational model needs to be
shifted from an event identification based on the XML ID of the note
that spanwned the event to the idea that there is a unique ID per
event message, and that response messages have an "in reply to"
attribute which bears the ID of *the event* being responded to, not
just the locus in XML of the activity template that was being
executed by the process that threw the event.  Compare with Message-ID
in RFC 821/822.

A counter-example can be constructed as follows.

A remote detached process is spawned by one thread forked by a <parallel>.

The <parallel> is aborted by one of the other threads executing a
transition out of the <parallel>. This causes some cleanup activity
including the sending of a cancel-message to the spawned process.

But the thread the went off outside the <parallel> returns and
re-enters the same <parallel>.

So the first branch once again spawns a "distinct logical instance"
of the same activity template. If we only know the ID of the
requesting state, we don't know the response to the first request
from the response to the second. But we need to know. There is no
guarantee that the cancel message will be handled before the first
execution of the detached process has dispatched a response event.
The second instance of the detached process can return a response
event before you get the response to the first request or the
response to the cancel message. So the events need their own IDs.

** Required syntax for response to external process invocation?

In the following (3rd) paragraph of section 4.4 there is talk of
spawned processes returning a 'done' message in a specified (but not
yet specified) syntax. This is a mis-design, as you have already
created the mechanism for converting the information returned by
external processes to in-this-state-chart-standard form in the
<finalize> clause. The recognition of 'done' state in the spawned
process should be evaulated after the <finalize> has run and hence
there is no fixed syntax for the message. Only the semantics of
'done' is fixed and the syntax in which this is communicated can be
established as part of a negotiated binding to a Web Service, for
example.

** specification of information items (attributes and the like)

It is not just within the Data Model discussion that ECMASCRIPT culture
pervades the discussion as opposed to XML culture.  This is also
true in the discussion of the attributes of states and events.

For example, enumeration types such as scxml:history.type are
explained as being of type "string."  This may well be the tightest
ECMASCRIPT type appropriate but in XML this should be typed as some
sort of a token type.

Other shortfalls in the specification of the model are things like

Re: scxml:join.ID "valid values" = "Valid state ID"

[This recurs in multiple ID-bearing elements]

The 'state' in "Valid state ID" doesn't belong there. What is
intended is an XML-acceptable ID value. The "valid values" entry
should be a citation, in other words it should say "per [REF]" where
[REF] is a reference to a specification, either some flavor of
XML specification or the XML-ID specification.

** can't mix 'incompatible' statments

Ref: 3.2.2 children (of 3.2 <state>)

last bullet, it says <invoke> is incompatible [sic] with the <state> and
<parallel> elements.

First, I don't understand what is being said by the term 'incompatible.'
What is the content model?

Second, I don't know why this is thought to be true.  If you can put
an <invoke> inside a <state> but you can't put it after another
child <state> then you can simply follow the first sub <state>
with a second sub <state> which is a wrapper for the <invoke>
that is a content-free workaround for the immiscibility condition.

HTH

Al

Received on Thursday, 23 March 2006 20:53:56 UTC