SCXML Issues - Intervoice

Questions/Issues from Intervoice on W3C SCXML Spec dated Jan 2006.

Definitions Proposals:

1.	It would be helpful to have explicit definitions for the
following terms to further disambiguate interpretation:

Engine - Platform provided for execution of one or more SCXML Sessions.

SCXML Session - Entity where one or more SCXML documents may be
executed.

SCXML Document - XML document adhering to SCXML schema.

State Machine - Is this a <state>, "SCXML Document", "SCXML Session"?
See Semantic Question/Issue #8 below.



Schema Questions/Issues: 

1.	W3C has chosen to represent children of, for example, <state> in
the schema as a <choice> group with minimum occurrence of "0" and a
maximum occurrence of "unbounded".  However, inside <choice> the number
of occurrences of elements such as <onentry> or <onexit> are further
constrained. A simple change from a <choice> group to a <sequence> in
the schema would promote validation at parse time, overcoming the limits
of XML Schema validation surrounding <choice> groups.  Is there any
intent or desire to make this change?

2.	<target> now longer present in documentation yet unreferenced
<target> element still defined in schema.  Is it to be assumed that
schema is incorrect?

3.	Previously <target> was provided as a container for an anonymous
<state>.  As <target> is no longer referenced in schema, does it make
sense to still allow the "id" attribute of <state> (Section 3.2) and
<parallel> to be optional?  

4.	Per Section 3.4, <parallel> allows multiple <onentry> or
<onexit> child tags.  Tags of each type are to be executed in document
order.  Per Section 3.2, <state> does not allow multiple <onentry> or
<onexit> child tags.  Is this intended or should <state> also be allowed
to contain multiple <onentry> or <onexit> child tags?

5.	<exit/> tag no longer appears in the specification or XML
Schema.  Is this intended?  Also, see Design Questions/Issues #1 below.

6.	With regard to Schema Issue/Question #5, Appendix B.4 discusses
the possibility of allowing <parallel> as a sibling of <state> in the
Schema.  Will this imply that<parallel> will now have a Boolean "final"
attribute?  If <parallel> is allowed to be a sibling of <state>, does
the idea of an anonymous <parallel> have value or should the "id" of
parallel be changed from "optional" to "required" as discussed in Schema
Question/Issue #3 above?

7.	Various examples of <assign> throughout the specification
contain a "name" attribute.  However the XML Schema only defines a
"location" attribute.  What is the purpose for "name" or should "name"
be replace by location?  Also, please see Semantic Question/Issue #5


Semantic Questions/Issues:

1.	With regard to Schema Issue/Question #6, what are the semantic
implications of
<parallel final="true>?

2.	Section 5.3 discusses the possibility of <data> with a child XML
Tree.  Is the intent here that an ECMA DOM must be provided by the
runtime engine for the purposes of allowing traversal of this tree such
as the behavior for the VXML 2.1 <data> tag mandates?

3.	Section 4.4, specifically the last paragraph of <invoke>
outlines a need to pass "state id" to the external entity for purpose of
routing return events.  Since the "id" attribute of <state> is optional,
it is presumed that the runtime must generate "id"s for anonymous states
for the purposes of routing event notification to <finalize>.  Is this
expected behavior intended for the runtime?

4.	Regarding anonymous states, Section 5.1 discusses referencing of
<data> elements defined inside a <state> using a dotted hierarchy
containing the "state id".  If <datamodel> and <data> are declared in
anonymous states, reference to such data from outside the state will be
impossible as the "state id" cannot be ascertained.  Is the intent to
leave the "id" attribute of <state> optional as discussed in Schema
Question/Issue #3 purposeful in providing "data hiding"?

5.	If <assign> has a "name" attribute as the examples suggest, is
the intent that the use of "name" versus "location" implies that <assign
name="xxx"> will only target variables declared using <var> where
<assign name="location"> will only target variables assigned using
<data>?

6.	As <var> and <script> are only allowed as "executable content",
a situation arises where a developer might like to include ECMA
functions using <script> that are "shared" (visible outside executable
content container) throughout the document.  Is there any consideration
of allowing <script> and possibly <var> as children of <scxml>?  The
example that immediately comes to mind is the VXML Specification where
both <var> and <script> are allowed as children of the <vxml> tag.

7.	Data Model Initialization - Section 5.1 Paragraph 4 indicates
that <datamodel> is allowed as a child of <state> and futher states:
"However, all instances of the <data> tag are created and initialized
when the state machine is instantiated and may be accessed from any
state at any time."  Please see Definitions Proposals #1.

8.	With regard to Semantic Question/Issue #7 above, if state
machine is interpreted to mean the SCXML document, there are semantic
implications regarding an "initialization phase" (see VXML FIA) where
<data expr"xxx"/> could contain an expression that references <data>
declared in another <state> that has not yet been initialized.  

However, if the specification were to state that <data> initialization
occurs in document order, the user would be forced to order <states>
containing <data> elements with "dependent" <data> references could be
resolved without issue.  Is there any future intent to add such a clause
to the specification?



This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information.  If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments.

Received on Friday, 10 February 2006 22:47:01 UTC