commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Re: [SCXML] Declaration of a data model
Date Tue, 21 Mar 2006 07:12:59 GMT

Hi Rahul,

On 17.03.2006 23:57:06 Rahul Akolkar wrote:
>Please prefix email subjects since this mailing list is shared by all
>of Commons. I've added the [scxml] prefix to the subject for this
>thread. Onto your question ...

sorry, but I'm new to this list. I'll do it next time.

>On 3/17/06,
><> wrote:
>> Hi,
>> is it possible to declare a data model like defined in W3C Working
Draft? I
>> tried it but I got a warning for undefined variable (UNDEFINED_VARIABLE
>> = null):).
>Not yet. Though incidentally, I just started working on the
><datamodel> section [1] which was added as part of the latest SCXML WD
>(24 Jan '06). Given your nudge, I'll try to push some of it out into
>the nightlies early next week.

That would be nice. Thanks in advance.



>> <?xml version="1.0" encoding="us-ascii"?>
>> <scxml version="1.0" xmlns="">
>>  <datamodel>
>>    <data name="X" expr="2"/>
>>  </datamodel>
>The usage above, though quite correct, is really the degenerate case
>where your XML data tree has collapsed into a single leaf node. For
>such usages, you can simply use the <var> element (which is used to
>create similar "scratch space" variables) inside the pertinent
><onentry> to define the variable with an appropriate initial value and
>do away with the UNDEFINED_VARIABLE callback on the ErrorReporter (as
>well as the <datamodel> -- again, for such degenerate usages).
>The data element is really meant to hold XML data trees such as:
> <data name="ticket">
>   <origin/>
>   <destination/>
>   <!-- default values for trip and class -->
>   <trip>round</trip>
>   <class>economy</class>
>   <meal/>
>   <!-- and so on -->
> </data>
>A <datamodel> can contain more than one of these. Moreover, the
>datamodel can be distributed across the SCXML document, and scoping
>rules apply to these <data> once they start appearing as children of
><datamodel>s within <state>s.
>Furthermore, these XML data trees can now be transported via the
>EventDispatcher (<send>) or the Invoker (<invoke> from the latest
>SCXML WD, soon to come to Commons SCXML) to any related, even external
>Finally, one may think of distributed datamodels as task completion
>goals, possibly bubbling up and co-operating to fulfill some supertask
>defined at document root.
>These are powerful constructs, IMO. We only have the beginnings of
>SCXML usecases available [2].
>> </scxml>
>> Regards,
>> Heiko
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message