- From: Barnett, James <James.Barnett@aspect.com>
- Date: Sun, 12 Feb 2006 12:51:56 -0500
- To: "Skip Cave" <Skip.Cave@intervoice.com>, <www-voice@w3.org>
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