RE: some comments on an SCXML draft

There are two issues here.  The first involves event identification:

When this was discussed internally we felt that there is a mix up in
Al's comments between what the author of SCXML sees versus what the
SCXML interpreter sees. In other words the id that is included (that
matches the state that called the invoke) is sufficient for the SCXML
author, but it implies that the browser is somehow able (quite possibly
through id mechanisms like Al describes) to ensure that events from
previous state's invokes (or more importantly from previous
instantiations/interactions of this same state's invoke) don't get
raised to the author.  In short, the platform is responsible for sorting
out the use case that Al describes.

The second point involves the 'Done' event and finalize.  Finalize is
intended to update the data model only.  Events in SCXML (and other
state machine languages) are immutable, read-only objects.  After all,
what would it mean to have a transition triggered by an event 'Foo' if
the transition's executable content could convert 'Foo' into 'Bar' while
the transition was executing?  Thus events may not be modified once they
appear within the scope of the SCXML markup.  However, this does not
mean that the platform may not massage the result returned by the
external process before it injects it into the SCXML event queue.  In
short, the platform may do whatever it needs to get the 'Done' event
into proper shape before the finalize tag sees it.  

- Jim

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Al Gilman
Sent: Thursday, March 23, 2006 3:54 PM
To: www-voice@w3.org
Subject: 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 Wednesday, 3 May 2006 21:14:59 UTC