commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heiko.Eichber...@rsbick.rohde-schwarz.com
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:
>Heiko,
>
>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, Heiko.Eichberger@rsbick.rohde-schwarz.com
><Heiko.Eichberger@rsbick.rohde-schwarz.com> 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
(X
>> = null):).
>>
><snip/>
>
>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.

Regards,

Heiko

>
>
>> <?xml version="1.0" encoding="us-ascii"?>
>> <scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
>>  <datamodel>
>>    <data name="X" expr="2"/>
>>  </datamodel>
>>
><snap/>
>
>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
>process.
>
>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].
>
>-Rahul
>
>[1] http://www.w3.org/TR/scxml/#data
>[2] http://jakarta.apache.org/commons/sandbox/scxml/usecases.html
>
>
>>
>> </scxml>
>>
>> Regards,
>>
>> Heiko
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message