commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] format of state content in external file?
Date Tue, 13 Feb 2007 16:11:07 GMT
On 2/13/07, Wolfgang Frech <Wolfgang.Frech@iteratec.de> wrote:
> Hello SCXML users,
>
> I would like to split a SCXML document into several modules.
> Though there is an example in the Working Draft, this might not be
> exactly consistent with the specification, and it might be not what
> Commons SCXML implements.
>
> What exactly is the format of the external file referenced by a src
> attribute?
<snip/>

Same as the host SCXML document (no signifcant additional constraints).


> In the context of the implementation, it is less important, if the
> solution follows the WD to the letter. I am looking for a solution that
> works with V0.6.
>
<snap/>

OK, lets consider an example.

Given that statemachine1.scxml is the following:

<scxml ... initialstate="foo">

    <datamodel>
        <data name="alpha">
            ...
        </data>
        <data name="beta">
            ...
        </data>
    </datamodel>

    <state id="foo">
        ...
    </state>

    <state id="bar">
        ...
    </state>

    <!-- other states -->

</scxml>

and a <state> in another SCXML document, statemachine2.scxml, points
to the above statemachine1.scxml (lets use a trivial relative path)
like so:

<state id="enclosing" src="statemachine1.scxml" />

then the runtime engine sees the enclosing state as (in other words,
the above is equivalent to):

<state id="enclosing">

    <initial>
        <transition target="foo"/>
    </initial>

    <datamodel>
        <data name="alpha">
            ...
        </data>
        <data name="beta">
            ...
        </data>
    </datamodel>

    <state id="foo">
        ...
    </state>

    <state id="bar">
        ...
    </state>

    <!-- other states -->

</scxml>

Thereby, if we originally have a state machine that looks like the
runtime representation, then by corollary, the enclosing state may be
extracted into a state machine that looks like statemachine1.scxml.

To make this happen, the v0.6 impl does the following:

 * Takes the initialstate attribute of the src'ed in SCXML and makes
it the target of the initial of the enclosing state
 * Populates the enclosing state's <datamodel> with that of the src'ed in SCXML
 * Child states of the src'ed in SCXML become child states of the
enclosing states

If you have other questions, please feel free to ask.

-Rahul


> It could be one of the following
>
> a) a complete SCXML document, with scxml element as root, and exactly
> one state element, that is identical to the state element in the main
> SCXML document, and without initialstate attribute.
> This would follow the example in the WD.
>
> b) as a), but with an initialstate attribute pointing to its one and
> only state.
> This would meet the definition of the scxml element.
>
> c) a fragment of a SCXML document, without scxml  root element, but with
> exactly one state element as root.
> This would avoid the question if initialstate is required, because it
> leaves out the scxml element.
> This would _not_ follow the example.
>
> d) a fragment with the content of the state element, that is an XML
> fragment with a list of elements, not with a single root.
> This would _not_ follow the example, and it would be hard to edit with
> an XML editor that does not handle  multiple top level elements.
>
> e) a SCXML document with scxml root element, and the content of the
> externalized state, that is onentry, transition, onexit elements, but
> _not_ with an enclosing state element between the scxml and the state's
> content.
> A first experiment shows that this is accepted, but not correctly
> executed: The transitions do not "fire".
>
> f) ... anything else?
>
> Thanks for your help.
>
> Wolfgang Frech
>
> --
> Wolfgang Frech
> iteratec GmbH
> Inselkammerstra├če 4   D-82008 Unterhaching
> +49-89-61 45 51-64    Fax: -10
> mailto:wolfgang.frech@iteratec.de   www.iteratec.de
>
>

---------------------------------------------------------------------
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