RE: Shocked by new SCXML Draft

I think there is some confusion here.

1. CCXML 1.0: "A CCXML implementation MUST support the ECMAScript Compact Profile." [Section 3.3, http://www.w3.org/TR/ccxml/]

2. The latest draft of SCXML 1.0 introduces the concept of profiles with the precise intention of decoupling expression languages from the core (state machine) operations of SCXML. The core profile has no expression language support. The Xpath profile requires XPath 2.0 support. The ECMAScript profiles requires ECMA 327: "conformant implementations of the ECMAScript Profile for SCXML 1.0 must support ECMAScript Compact Profile" (Section 9.2.1). Section 9 "Profiles" describes how to define your own profile. You could, for example, define a profile which supports exactly the expression language Stefan describes. A document author then uses the profile attribute to indicate which profile they are authoring with.

An SCXML implementation is not (yet) required to support any specific profile; i.e. it does not need to support the EMAScript profile (or the Xpath profile). It could just support the profile you need. Appendix F "Conformance" was intended to make this clear, including how an implementation deals with documents written in a profile which it does not support.

Scott


-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of David Nicol
Sent: Friday, May 23, 2008 17:43
To: Stefan Maton
Cc: www-voice@w3.org
Subject: Re: Shocked by new SCXML Draft


On Thu, May 22, 2008 at 6:25 AM, Stefan Maton <maton@sidema.be> wrote:
>
> -          Decouple Ecmascript and SCXML: Looking at the different
> conditions and expressions that can be embedded within the scxml,
> there is no real need to force the SCXML standard to use Ecmascript.
> In fact any expression parser which can handle normal and boolean
> expressions and which can hold a set of data is ok. The only
> specification you need to give is the way the data is represented when
> attaching it as a namelist in <send> or as a return value when a expr
> is evaluated within an <assign>. By decoupling Ecmascript and SCXML
> (and implicitly XPath) the draft would be much more flexible since not only targeted at the java platform.

Speaking as someone who is only aware of SCXML as a potential successor to CCXML, which is a context that rightly does not include ecmascript, letting the VXML portions of a complex system handle them, I agree with what Mr. Maton has said.
Perhaps declaring
JSON as the marshalling protocol for data objects or another very restricted by well defined subset of ECMAscript -- perhaps requiring ECMA-327 http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-327.pdf
instead of full ECMA-262.

Received on Friday, 23 May 2008 16:17:43 UTC