[scxml] sixth WD of SCXML is published

[Kazuyuki Ashimura]

Hi www-voice,

The sixth Working Draft of "State Chart XML (SCXML): State Machine
Notation for Control Abstraction" has been published as follows.

This version:
  http://www.w3.org/TR/2009/WD-scxml-20091029/

Latest version:
  http://www.w3.org/TR/scxml/

Previous version:
  http://www.w3.org/TR/2009/WD-scxml-20090507/

A diff-marked version is also available for comparison purposes at:
http://www.w3.org/TR/2009/WD-scxml-20091029/diff.html

The main difference from the previous draft is the correction of
various inconsistencies.

Comments are welcomed to this Voice public list, <www-voice@...>.

Best regards,

Kazuyuki Ashimura
for the W3C Voice Browser WG

--
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@...
voice: +81.466.49.1170 / fax: [phone]

[Greg Beauchesne-2]

Kazuyuki Ashimura wrote:
> Hi www-voice,
>
> The sixth Working Draft of "State Chart XML (SCXML): State Machine
> Notation for Control Abstraction" has been published as follows.

Hello. My name is Greg Beauchesne. I guess I'm new here, but I've been
working on an SCXML implementation of my own and I figured that means I
should probably get in on this list.

So, without further ado...

1. I'm glad that the whole event name prefix issue has been updated to
use tokens. This had been causing me issues with event names like "up"
vs. "update".

2. Would it be possible for transition/@event to be of type NMTOKENS
instead of NMTOKEN? As it stands, if I want to have the same transition
be taken for two completely different events, with all of the associated
executable content, I have to copy and paste the entire transition
definition or otherwise use scripted functions to achieve common
functionality. I think this would not break anything, since NMTOKEN
already forbids whitespace. (Although technically I guess it's not
NMTOKEN anyway, according to the schema in D.1)

3. I also like the new expr vs. non-expr attributes; this really
clarifies when a string or expression should be used. On <send> and
<invoke>, I would say that @id and @idlocation is inconsistent with the
rest (@idexpr instead of @idlocation would probably match better), but
I realize this is probably for compatibility with previous WDs, not to
mention that it is the one attribute that acts as an lvalue.

4. Along the lines of the expr/non-expr attributes, I would see
value in something similar for <log>. It seems to me that @label is not
intended to be replacement for @expr (i.e. <log label="test"/> is not
necessarily the same as <log expr="'test'"/>, especially since @expr is
required and @label is not). So maybe something like <log message="My
message"/>?

If that were the case, though, it would probably get confusing as to
whether to use @label or @message. What was the intent behind the @label
attribute?

Alternatively or in addition, I think <log> could support child content
(at least text nodes) as an alternative to either the @label or @expr
attributes. <assign> and <data> already do this. For example, this:

<log>A thing happened</log>

....would be the same as this (assuming a compatible scripting language):

<log expr="'A thing happened'"/>

5. Section 9 on IDs does not specify the scope of uniqueness. I know
that the XML ID type specifies that it is unique throughout the
document, but it seems like states/sends/invokes/data model fields would
all be in different namespaces (not to be confused with XML namespaces).
I would think it to be pretty useful for an <invoke> or a <send> to
share the ID of the <state> that contained it. If the intent was to
forbid this sort of thing, I think that should be explicitly stated.

6. Is the default transition on history states permitted to have
executable content? The algorithm seems to say no (the transition is
just used as though it were the history value), while section 3.11.2
does not say. If the answer really is "no", is there any reason to have
a <transition> child as opposed to just an attribute with the default
targets, other than consistency? (i.e. <history default="blah"/> seems
just as good as <history><transition target="blah"/></history>)

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit (i.e. it targets either itself or
another history state that then targets the original history state). A
potential solution (assuming no executable content from #6 above) would
be to simply forbid the default history state transition from having a
sibling history state as a target. There is no reason this would be
necessary, since A) before the history values are assigned, setting the
target of H1 to H2 would have the same result as setting the target of
H1 to the target of H2, and B) all sibling history state values are
assigned at the same time, which eliminates the default transitions --
there is never a time when one sibling history will be using its default
transition and the other will not.

-------------------
Lastly, here are some proofreading errors:

Section 3.2.2: Last paragraph -- in the text '...an "initial" attribute
or am <initial> element...', I'm assuming "or am <initial>" should be
"or an <initial>".

Sections 4.1.6, 4.3.3, E.1, E.7, G.1: The examples don't appear to have
been updated for the new expr and non-expr attributes.

Section 10.3.3.1: The XPath in the <assign> is incorrect.
"city[id='nyc']" should be "city[@id='nyc']".

Section B: addStatesToEnter() uses the "LCA" variable in its history
state handling, but it's never actually assigned a value. (I expect this
is from being moved from enterStates() in the previous WD, which means
that a likely correction is "root".)

Section C: scxml/@initialstate in the example should be scxml/@initial.
-------------------

Those are my comments for now. Thank you for your work on SCXML.

-- Greg

[Greg Beauchesne-2]

Hello. I have some more comments on the SCXML WD:

1. In section 3.5.2, where it says "the 'target' of the transition must
be a descendant of the <initial> element's parent <state>", was it
actually intended to say "descendant" and not "child" here? I ask
because if it is actually supposed to be "descendant", then there are
some issues that may need to be addressed regarding <initial> and
<parallel>. I can elaborate, but I want to make sure this is the case first.

-

2. Section 4.1.2 says that send/@namelist separates its datamodel
locations by space, but this is potentially incompatible with more
complex expressions. For example, the XPath expression:

a/b[@attr='some value']

...would be improperly broken at a whitespace boundary. The actual
method of specifying multiple names should probably be scripting
language-dependent. XPath has sequences (well, 2.0 does, anyway),
ECMAScript has arrays, etc.

-

3. The definition for <datamodel>/<data> is somewhat unclear. Section
5.1 says "...all instances of the <data> element are created and
initialized when the state machine is instantiated and may be accessed
from any state at any time." whereas 5.2 says "All <data> tags are
evaluated exactly once, at load time. Implementations thus MUST evaluate
<data> elements at load time but MAY do so in any order they choose."

Does this mean, then, that if I have something like <data id="someValue"
expr="random()" /> that all instances of a state machine in a particular
session will end up with the same value for "someValue" but that it may
differ if the SCXML document is reloaded?

If so, I assume the recommended alternative is to initialize the data in
scxml/initial/transition ?

-

4. What are the semantics of the in() predicate in any of the
intermediate places where executable content is used? What I mean by
this is that just about everywhere that executable content is used
except for transition/@cond, the current state configuration is in the
middle of being modified (onentry, onexit, (state |
parallel)/transition, initial/transition).

If the answer here is "add/remove states in the configuration when the
algorithm says so," then OK. I just wanted to make sure, since 8.1,
10.2.5.1, and 10.3.4.1 don't say anything about this.

-

5. parallel/history[@type = 'shallow'] -- Does it do anything useful? If
not, could it be made useful by digging down a little deeper to the
nearest children of a compound <state>? (Or does this stray too far from
Harel semantics?)

-

6. What happens if a <history> with no default transition is the target
of a transition? In the algorithm, it looks to me like this will create
an invalid state configuration. Maybe this should have the same defaults
that @initial does when unspecified?

-

7. When errors are raised at document load time, what is to be done with
them? Implementation-defined? I ask because they are formatted in the WD
as though they should be treated like dynamic errors (i.e. fed back to
the state machine as an event) but this is not possible without a state
machine instance. If I'm understanding correctly, the handling of these
two error types is *very* different -- static (document load) errors are
likely thrown as normal exceptions in whatever the implementation
language happens to be (e.g. Java exceptions), and dynamic (runtime)
errors are handled internally within the state machine without being
directly reported to the external environment (and potentially ignored
if there are no transitions to handle them).

-

8. I'm a little confused about scxml/@exmode='strict'. Section 3.1.1
says that the interpreter should raise "error.unsupportedelement" when
it encounters unrecognized executable content, whereas section F says
unrecognized custom executable content must raise an "error.badfetch"
event with scxml/@exmode='strict'. However, this is the only place
"error.badfetch" is mentioned. It also says
"error.unsupported.<element>" for unsupported SCXML elements. Which of
these three is it? (I understand there are going to be inconsistencies
of this nature in a work-in-progress, but I'm wondering which is the
most likely/recent candidate.)

Also, regardless of whichever error code it happens to be, I'm not sure
whether it's OK for me to make it a static error or if I have to wait
until runtime execution hits that point to raise the error. None of
sections 3.1.1, 3.12.6, or F give any clue if it's supposed to be static
or dynamic (or implementation-defined).  At the moment, I just abort
compilation with a static error, since all possible custom executable
elements are known at compile time. I would guess implementation-defined
is the way to go, since nowhere does it say in the WD when custom action
elements must be bound to implementations (they could be bound pre- or
post-document load, or even dynamically in regards to the needs of the
document).

-

9. Are there any plans for state machine instance serialization? i.e. I
want to take a running instance, save its configuration, history states,
event queue, etc. to a byte array, and then restore it at a later time
(thus bootstrapping directly into a particular state configuration
rather than finding a way there from the initial state via the defined
transitions).

Obviously, things like serialization format and such would be
implementation-defined, but I ask because there are semantic
implications in how <onentry> and such might work. My current plan for
my own implementation is just that executable code in <onentry> can
access some extension variables and functions to determine if it's being
entered normally or entered as part of a serialized load.

My guess would be "No, there are no plans for this, and it's outside the
scope of the basic SCXML definition anyway." That's also fine, in which
case I guess I'm looking for any best practices suggestions.

-

That's it for now. Thanks for reading.

-- Greg

[Jim Barnett-5]

Greg,
  We will reply to the rest of your comments as we have time to review
them.  Here are responses to a few of them:

5. Section 9 on IDs does not specify the scope of uniqueness
>> The section states:  "The values of all attributes of type "id" MUST
be unique within the session."  

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit
>>  We will look at this more closely, but in general SCXML and all
other state machine languages are so rich in possibilities for infinite
loops that we can never hope to eliminate all of them.

And from your email of Nov 11

1. In section 3.5.2, where it says "the 'target' of the transition must
be a descendant of the <initial> element's parent <state>", was it
actually intended to say "descendant" and not "child" here? I ask
because if it is actually supposed to be "descendant", then there are
some issues that may need to be addressed regarding <initial> and
<parallel>. I can elaborate, but I want to make sure this is the case
first.

>> yes, the intent was 'descendant', so we would like to hear about the
issues with <initial> and <parallel>

4. What are the semantics of the in() predicate in any of the
intermediate places where executable content is used? What I mean by
this is that just about everywhere that executable content is used
except for transition/@cond, the current state configuration is in the
middle of being modified (onentry, onexit, (state |
parallel)/transition, initial/transition).
If the answer here is "add/remove states in the configuration when the
algorithm says so," then OK. I just wanted to make sure, since 8.1,
10.2.5.1, and 10.3.4.1 don't say anything about this.

>> Yes, the intent is to add/remove states following the algorithm.

9. Are there any plans for state machine instance serialization? i.e. I
want to take a running instance, save its configuration, history states,

event queue, etc. to a byte array, and then restore it at a later time

>> We have discussed this and think it's out of scope, at least for the
first version of the spec. We expect that most implementations will
support something like this, and are interested in suggestions for
things that we could add to the spec to make serialization easier, but
we don't see the need for a standard serialization format at the moment.

= Jim Barnett

-----Original Message-----
From: www-voice-request@... [mailto:www-voice-request@...] On
Behalf Of Greg Beauchesne
Sent: Sunday, November 01, 2009 10:02 PM
To: VoiceBrowser
Subject: Re: [scxml] sixth WD of SCXML is published

Kazuyuki Ashimura wrote:
> Hi www-voice,
>
> The sixth Working Draft of "State Chart XML (SCXML): State Machine
> Notation for Control Abstraction" has been published as follows.

Hello. My name is Greg Beauchesne. I guess I'm new here, but I've been
working on an SCXML implementation of my own and I figured that means I
should probably get in on this list.

So, without further ado...

1. I'm glad that the whole event name prefix issue has been updated to
use tokens. This had been causing me issues with event names like "up"
vs. "update".

2. Would it be possible for transition/@event to be of type NMTOKENS
instead of NMTOKEN? As it stands, if I want to have the same transition
be taken for two completely different events, with all of the associated

executable content, I have to copy and paste the entire transition
definition or otherwise use scripted functions to achieve common
functionality. I think this would not break anything, since NMTOKEN
already forbids whitespace. (Although technically I guess it's not
NMTOKEN anyway, according to the schema in D.1)

3. I also like the new expr vs. non-expr attributes; this really
clarifies when a string or expression should be used. On <send> and
<invoke>, I would say that @id and @idlocation is inconsistent with the
rest (@idexpr instead of @idlocation would probably match better), but
I realize this is probably for compatibility with previous WDs, not to
mention that it is the one attribute that acts as an lvalue.

4. Along the lines of the expr/non-expr attributes, I would see
value in something similar for <log>. It seems to me that @label is not
intended to be replacement for @expr (i.e. <log label="test"/> is not
necessarily the same as <log expr="'test'"/>, especially since @expr is
required and @label is not). So maybe something like <log message="My
message"/>?

If that were the case, though, it would probably get confusing as to
whether to use @label or @message. What was the intent behind the @label

attribute?

Alternatively or in addition, I think <log> could support child content
(at least text nodes) as an alternative to either the @label or @expr
attributes. <assign> and <data> already do this. For example, this:

<log>A thing happened</log>

....would be the same as this (assuming a compatible scripting
language):

<log expr="'A thing happened'"/>

5. Section 9 on IDs does not specify the scope of uniqueness. I know
that the XML ID type specifies that it is unique throughout the
document, but it seems like states/sends/invokes/data model fields would

all be in different namespaces (not to be confused with XML namespaces).

I would think it to be pretty useful for an <invoke> or a <send> to
share the ID of the <state> that contained it. If the intent was to
forbid this sort of thing, I think that should be explicitly stated.

6. Is the default transition on history states permitted to have
executable content? The algorithm seems to say no (the transition is
just used as though it were the history value), while section 3.11.2
does not say. If the answer really is "no", is there any reason to have
a <transition> child as opposed to just an attribute with the default
targets, other than consistency? (i.e. <history default="blah"/> seems
just as good as <history><transition target="blah"/></history>)

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit (i.e. it targets either itself or
another history state that then targets the original history state). A
potential solution (assuming no executable content from #6 above) would
be to simply forbid the default history state transition from having a
sibling history state as a target. There is no reason this would be
necessary, since A) before the history values are assigned, setting the
target of H1 to H2 would have the same result as setting the target of
H1 to the target of H2, and B) all sibling history state values are
assigned at the same time, which eliminates the default transitions --
there is never a time when one sibling history will be using its default

transition and the other will not.

-------------------
Lastly, here are some proofreading errors:

Section 3.2.2: Last paragraph -- in the text '...an "initial" attribute
or am <initial> element...', I'm assuming "or am <initial>" should be
"or an <initial>".

Sections 4.1.6, 4.3.3, E.1, E.7, G.1: The examples don't appear to have
been updated for the new expr and non-expr attributes.

Section 10.3.3.1: The XPath in the <assign> is incorrect.
"city[id='nyc']" should be "city[@id='nyc']".

Section B: addStatesToEnter() uses the "LCA" variable in its history
state handling, but it's never actually assigned a value. (I expect this

is from being moved from enterStates() in the previous WD, which means
that a likely correction is "root".)

Section C: scxml/@initialstate in the example should be scxml/@initial.
-------------------

Those are my comments for now. Thank you for your work on SCXML.

-- Greg



                                       
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
                                       

[Greg Beauchesne-2]

Jim Barnett wrote:
> Greg,
>   We will reply to the rest of your comments as we have time to review
> them.  Here are responses to a few of them:

Yes, sorry about that. I admit it was a bit of a brain dump. No rush.

> 5. Section 9 on IDs does not specify the scope of uniqueness
>>> The section states:  "The values of all attributes of type "id" MUST
> be unique within the session."  

Sorry, yes; my mistake. I guess what I really meant was "Is there any
context in which uniqueness of IDs over types of objects that are
effectively disjoint (such as states vs. data model fields) is
important, or is this mainly just for general readability and ambiguity
prevention?" (If you had something like "typeof('abc')=='state'" and
"typeof('def')=='datafield'", for example, then this would be a clear
situation where two different types of object should not be able to have
the same ID).

Or is it just that it's simpler for a parser to validate a document
using ID/IDREF than one with a bunch of different schema keys?

> 7. The algorithm seems to potentially run into infinite recursion on
> default history state transitions if multiple default history state
> transition targets create a circuit
>>>  We will look at this more closely, but in general SCXML and all
> other state machine languages are so rich in possibilities for infinite
> loops that we can never hope to eliminate all of them.

Of course. This one in particular just seemed to be something that was
easily detectable or preventable with a rule change.

>>> yes, the intent was 'descendant', so we would like to hear about the
> issues with <initial> and <parallel>

OK. First off is just a little inconsistency between section 3.5.2 and
the sections which describe @initial (3.1.1 and 3.2.1). Section 3.5.2
says "must be a descendant", but with @initial being of type IDREFS, I'm
guessing this should be "must be one or more descendants" (or however
you want to word it to work in a mention of <parallel> -- maybe even
just copying the text from the descriptions of @initial).

Now, more importantly: <parallel> does not currently allow <initial>,
but given the definition of <initial>, it seems like it could
potentially serve a valid purpose.

The first such reason would be executable content. You might say that
parallel/onentry could already handle this, but remember that <onentry>
cannot be skipped by transitions, whereas transitions that directly
target child states will skip the initial/transition executable content
of those states' ancestors.

The second reason is a little more involved, but it's along those same
lines. As you've confirmed for me, initial transition targets must be
descendants of the <initial> parent's element -- not necessarily direct
children:

<state name="S1" initial="S3">
   <state name="S2">
     <initial>
       <transition target="S3">
         <log expr="'Passed through S2'" />
       </transition>
     </initial>

     <state name="S3" />
   </state>
</state>

In other words, in the case above, entering S1 directly would mean
entering S3 directly, skipping over S2's initial transition (i.e. S2 is
not added to statesForDefaultEntry in the algorithm), and the <log>
would not be executed.

Now, presumably (and please correct me if I'm wrong on this) <parallel>
does not allow <initial> because when a parallel state is entered, all
of its children are entered as well. But this means all children trigger
their initial transition (because they're all added to
statesForDefaultEntry). True, there is no difference in functionality if
you were to have an @initial that specified only direct child states,
but as above, specifying one or more states at the grandchild level or
deeper WOULD have an effect:

<parallel state="P1" initial="S3">
   <state name="S1" />
   <state name="S2">
     <initial>
       <transition target="S3">
         <log expr="'Passed through S2'" />
       </transition>
     </initial>

     <state name="S3" />
   </state>
</parallel>

In this case above, upon entering P1, S1 and S3 would be entered, and
again S2's initial transition would be skipped over. (This also means
initial="S3" is the same as initial="S1 S3", and not specifying an
initial transition is the same as "S1 S2").

Of course, the same effect could be achieved by wrapping the <parallel>
in a <state initial="S3">, but this seems like an unnecessary extra
step. It also means that if you're making use of parallel/state/final,
the "done.state.*" event does not have the same ID as the wrapper <state>.

> 4. What are the semantics of the in() predicate in any of the
> intermediate places where executable content is used? What I mean by
> this is that just about everywhere that executable content is used
> except for transition/@cond, the current state configuration is in the
> middle of being modified (onentry, onexit, (state |
> parallel)/transition, initial/transition).
> If the answer here is "add/remove states in the configuration when the
> algorithm says so," then OK. I just wanted to make sure, since 8.1,
> 10.2.5.1, and 10.3.4.1 don't say anything about this.
>
>>> Yes, the intent is to add/remove states following the algorithm.

OK. With that in mind, would you see any benefit to pre- and
post-microstep versions of in()? That is, during <transition>,
<onentry>, or <onexit>, the former would enable access to the state
configuration from before the microstep began, and the latter would
enable access to what the state configuration will be when the microstep
completes. I say that for reasons of parallel states such as the following:

<parallel>
   <state id="SA">
     <state id="SA1">
       <transition event="move" target="SA2" />
     </state>
     <state id="SA2" />
   </state>
   <state id="SB">
     <state id="SB1">
       <onexit>
         <if cond="in('SA1')"><log expr="'In SA1'"/></if>
         <if cond="in('SA2')"><log expr="'In SB1'"/></if>
         <if cond="in('SB1')"><log expr="'In SB1'"/></if>
         <if cond="in('SB2')"><log expr="'In SB2'"/></if>
         <if cond="in('SC1')"><log expr="'In SC1'"/></if>
         <if cond="in('SC2')"><log expr="'In SC2'"/></if>
       </onexit>
       <transition event="move" target="SB2" />
     </state>
     <state id="SB2" />
   </state>
   <state id="SC">
     <state id="SC1">
       <transition event="move" target="SC2" />
     </state>
     <state id="SC2" />
   </state>
</parallel>

Assuming a configuration containing "SA1 SB1 SC1", the "move" event will
trigger all three transitions. However, in SB1's <onexit>, we get the
log entries "In SB1" and "In SC1" -- SA1 has already been exited,
leaving no trace that we used to be there, whereas SC1 gives no
indication that it is also about to be exited. This means In() has a
dependency on document order that I believe could be eliminated.

> 9. Are there any plans for state machine instance serialization? i.e. I
> want to take a running instance, save its configuration, history states,
>
> event queue, etc. to a byte array, and then restore it at a later time
>
>>> We have discussed this and think it's out of scope, at least for the
> first version of the spec. We expect that most implementations will
> support something like this, and are interested in suggestions for
> things that we could add to the spec to make serialization easier, but
> we don't see the need for a standard serialization format at the moment.

I figured as much. No complaints here; an extension is just fine. I am
interested myself in what other implementations have done with this (if
anything).

> = Jim Barnett

Thanks for your reply.

-- Greg

[Jim Barnett-5]

Greg,
 On your specific point below, the global uniqueness of IDs regardless
of type is part of XMLSchema.  I don't know what that group's motivation
was, though I imagine it makes document validation simpler.  In any
case, given that that's the way XMLSchema works, it's easiest for us to
adopt their definition.

- Jim

"Is there any
context in which uniqueness of IDs over types of objects that are
effectively disjoint (such as states vs. data model fields) is
important, or is this mainly just for general readability and ambiguity
prevention?" (If you had something like "typeof('abc')=='state'" and
"typeof('def')=='datafield'", for example, then this would be a clear
situation where two different types of object should not be able to have

the same ID).

Or is it just that it's simpler for a parser to validate a document
using ID/IDREF than one with a bunch of different schema keys?



                                       
-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
                                       

[Greg Beauchesne-2]

Jim Barnett wrote:
> Greg,
>  On your specific point below, the global uniqueness of IDs regardless
> of type is part of XMLSchema.  

Right, I get that; that's why I was wondering about its use in SCXML (as
opposed to multiple xsd:keys).

 > I don't know what that group's motivation
> was, though I imagine it makes document validation simpler.  In any

I would guess it's mainly for compatibility with DTDs.

> case, given that that's the way XMLSchema works, it's easiest for us to
> adopt their definition.

OK. My main reason for asking was that for implementations with a
non-validating XML parser, it's an extra enforcement step for keyspaces
that I would assume are otherwise naturally separate. (Or at least it is
if you're going for strict SCXML conformance.)

-- Greg

[Jim Barnett-5]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Greg,

Here are responses to two more of your requests.  We will respond to the rest as we review them.

 

2. Would it be possible for transition/@event to be of type NMTOKENS instead of NMTOKEN?

>> We have accepted this request.  In the next public working draft, it will be possible to specify multiple event names in transition/@event (though we haven’t decided exactly what type to use in the schema.)

 

What happens if a <history> with no default transition is the target

of a transition?

>>  This cannot happen because the transition is mandatory.  Section 3.11.2 says that the transition child “Occurs once.”  However, the schema  needs to be fixed since it makes the transition child optional.  This will be fixed in the next draft. 

 

-          Jim

 

 

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

[Greg Beauchesne-2]

Jim Barnett wrote:

>
>
> Greg,
>
> Here are responses to two more of your requests.  We will respond to the
> rest as we review them.
>
>  
>
> 2. Would it be possible for transition/@event to be of type NMTOKENS
> instead of NMTOKEN?
>
>  >> We have accepted this request.  In the next public working draft, it
> will be possible to specify multiple event names in transition/@event
> (though we haven’t decided exactly what type to use in the schema.)

Excellent; thank you.

> What happens if a <history> with no default transition is the target
>
> of a transition?
>
>  >>  This cannot happen because the transition is mandatory.  Section
> 3.11.2 says that the transition child “Occurs once.”  However, the
> schema  needs to be fixed since it makes the transition child optional.  
> This will be fixed in the next draft.

OK, that clears some things up. Are you making it explicitly mandatory,
or "mandatory with an implicit default" such as was done with
initial|@initial in this recent WD?

Thanks for your reply.

-- Greg