Re: [scxml] newbie questions on Executable Content

Thanks Jim,

Just to clarify uses of "any language".  Is this valid?

   <transition event="timeout" cond="@isaMulligan@" target="S3">
     <myextension>
       DO_XYZ,
       NVP_LIST=
         "MSG_ENCODING_TYPE:foo", "bar",
         "SV:default", "SET:0::this:RecoverCount",
         "SV:default", "EXP:((@Vindex@-1)T2)+1::this:LineNumber",
         "RULE:foo", "ARequest.foo.template",
         "CMD:foo", "nil",
         NULL
     </myextension>
     <log expr="foo bar"/>
   </transition>

Or should it be <myextension:block> ... </myextension:block>
(with no xmlns:myextension= explaining the contents) ??

What about the cond= value above?  Should it be
   <transition cond="<myextension>@isaMulligan@</myextension>">  ??
   <transition cond="myextension:@isaMulligan@">  ??

What if the other-language-piece I want to use as the cond=
value has double-quotes or colons?


Even if these approaches let me leave portions of the original
language intact, it wouldn't be compliant unless I also support
ECMAScript.  But once someone extends the language and looses
portability, is it any worse to not support ECMAScript?
Should such an implementation have to bear the shame of being
"non-compliant"?


Also, when I asked about example F.2 below, I meant stuff like
       <transition cond="${door_closed}" target next="cooking"/>
Is "${}" part of the "base set that is defined in the body
of the spec"?  It's not ECMAScript, is it?


Thanks again!
-troy



Barnett, James wrote:
> Troy,
>   The definition of executable content is intended to allow any
> language, whether XML-based or not.  The important caveat is that EC
> should execute quickly since the state machine blocks during the
> execution of such content.
> 
> The SCXML spec specifies a base set of executable content that all
> implementations must support.  This includes <if>, <send>, <assign>,
> etc., but implementations are allowed to provide extensions.  Of course,
> application authors who restrict themselves to the base set are
> guaranteed portability across SCXML implementations, while those who use
> extensions are not. 
> 
> The examples in Section F should all be from the base set that is
> defined in the body of the spec.  (That base set will be restricted
> somewhat in the next draft, however.)  The EC in example C is ECMAScript
> and is just there as an example.  
> 
> The examples with <ccxml:accept> are intended to show another way of
> extending the language, since we show how they can be translated into
> core SCXML <send>. (They are thus syntactic sugar rather than an actual
> extension of functionality.)
> 
> The cond value of an <if> (and of the 'cond' attributes of events) must
> support ECMAScript, though platforms could, in principle, offer
> extensions there as well. 
> 
> We hope to have the next draft out in November, but are still working on
> some fairly substantial issues. 
> 
> - Jim
> 
> -----Original Message-----
> From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
> Behalf Of Troy Cauble
> Sent: Monday, October 16, 2006 12:10 PM
> To: www-voice@w3.org
> Subject: [scxml] newbie questions on Executable Content
> 
> 
> Hi,
> 
> I've got an existing state machine engine that runs a home-grown
> non-xml language and I'm exploring converting it to run SCXML.
> 
> I'm trying to understand the range of allowable Executable Content
> (EC).  Basically, is EC meant to be flexible enough to allow any
> language?  Any XML language?
> 
> What is the EC language shown in section F.2?  In section C?
> What is allowed as the child of an <if> ?  As the cond= value
> of an <if> ?
> 
> I see Custom Action Element examples like <ccxml:accept ....>.
> So this form is used for explicit references to XML languages.
> Otherwise EC content is anything???
> 
> (By the way, xmlns:prefix is specified for <send> but the examples
> show it in other elements.)
> 
> Is EcmaScript (compact profile) support really a MUST?
> While EC in general is anything??
> 
> Is an update still planned for November?
> 
> Thanks,
> -troy
>

Received on Monday, 16 October 2006 22:52:33 UTC