RE: SCXML Issues - Intervoice

Answers to at least some of your questions in-line below marked by >>.

- Jim


-----Original Message-----
From: www-voice-request@w3.org on behalf of Skip Cave
Sent: Fri 2/10/2006 5:46 PM
To: www-voice@w3.org
Subject: 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:

>> Yes, definitions will be tightened in a future draft

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.

>> state machine is the the <scxml> tag



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?

>> schema will be tightened up in future drafts

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

>> schema is incorrect here. 

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? 
 
>> ID will probably be made mandatory in the next draft

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?

>> no. parallel will be changed to have only a single onentry and onexit tag.

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

>> yes this is intended since anonymous states are no longer permitted

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?

>>  The issue is whether to permit <parallel> as
a direct child of <scxml>.  <state> and <parallel> can never be
siblings. 

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

>> intent is to use location as a generalization of name, but exact relation of 
<var> and <data> has yet to be clarified.  <var> is included for backwards compatibility
with CCXML.  The idea is that <data> is more general and allows to a location inside
an XML tree, which can be designated by a path expression, not just an atomic name.

Semantic Questions/Issues:

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

>> Good question.  That's either an error or an odd borderline case.  It will
be clarified when we give a full definition of the semantics

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?

>> Yes, but the data access language has not been defined and we would like to 
warn that the datamodel is the most unstable part of the spec. 

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?

>> For the time being yes, but ID will probably be made mandatory in the next draft.

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"?

>> anonymous states are no longer permitted

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>?

>> see answer to schema question 7

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.

>> Good point.  we'll take this as an open issue

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. 

>> this will be clarified in a future draft 

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 Sunday, 12 February 2006 17:49:37 UTC