On 2/13/07, Wolfgang Frech <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] www.iteratec.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
