Thank you Rahul,
This explains it.
My misunderstanding was about the identity of (top level) state of the
included state machine..
I thought it was treated as the _same_ state as the state in the
including state machine, that has the src attribute.
The example in the Working Draft can be read like this, alas, this is
not about the WD.
What the Commons SCXML implements is, phrased as a decomposition
refactoring:
A state that has sequential substates (and an initial element with an
unconditional transition to select the initial substate) can be
extracted into an external SCXML document.
The initial/transition becomes the initialstate attribute;
the substates become children of the extracted scxml element.
Datamodel elements likewise.
What I thought of originally, but is not implemented directly, is:
A state with transitions (and onentry and onexit elements) can bei
extracted (as above) to an external file/document.
Please note that the content of the state is not a set of substates.
Of course, this could be accomplished by introducing a substate, because
a state with a single substate and some content behaves almost as
without the inserted substate.
"Almost" means: if you ignore the inserted substate as a current state;
and if you find an unused name/id for the inserted state.
Example - before extraction
<scxml ... initialstate="enclosed">
<state id="enclosed">
<!-- the following content should be extracted -->
<transition event="foo" target="enclosed"/>
<transition event="bar" target="other"/>
<!-- -->
</state>
<state id="other"/>
</scxml>
Example - after extraction - enclosing machine
<scxml ... initialstate="enclosed">
<state id="enclosed" src="external"/>
</scxml>
Example - after extraction - enclosed machine
<scxml initialstate="_inserted">
<state _inserted>
<transition event="foo" target="enclosed"/>
<transition event="bar" target="other"/>
</state>
</scxml>
Lets compare the behavior:
before extraction:
initial: enclosed -- foo -- enclosed -- bar -- other
after extraction
initial: -_inserted (parent: enclosed) -- foo --_inserted (parent:
enclosed) -- bar -- other
Or one might switch the IDs of enclosed and _inserted...
Am I on the right track?
Anyone interested in this kind of refactoring and decomposition rules?
Regards
Wolfgang
Rahul Akolkar wrote:
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
--
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]
