commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Frech <Wolfgang.Fr...@iteratec.de>
Subject [SCXML] Re: format of state content in external file?
Date Wed, 14 Feb 2007 10:02:05 GMT
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 <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
>
>
-- 
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