On 2/14/07, Wolfgang Frech <[EMAIL PROTECTED]> wrote:
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.
<snip/>
Based on the clarification I've recently received, it so turns out
that the Commons SCXML implementation is actually a step ahead of the
WD in this respect ;-) It also seems that WD++ will render SCXML-37
invalid, but lets wait to see it before we make that conclusion.
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?
<snap/>
Yes, thats correct.
-Rahul
Anyone interested in this kind of refactoring and decomposition rules?
Regards
Wolfgang
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
