RE: [SCXML] <anchor> stuff?

Serge,

As you say in Question 2, the most sensible way to implement anchors is
to keep a stack of states and snapshots and then pop items off until you
find a match.  (Note, though that in the case where there is no match,
you may end up not popping any items off the stack.)  

 

We will try to document the required behavior more fully in the next
draft.

 

- Jim

 

________________________________

From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On
Behalf Of Serge Voloshenyuk
Sent: Monday, April 16, 2007 4:21 PM
To: www-voice@w3.org
Subject: RE: [SCXML] <anchor> stuff?

 

James. 

Thanks for your prompt answer.

	>Question 1:  <anchor> transitions can be chained.  Suppose
states S1 and
	
	>S2 both have <anchor>s of type "Foo" and the machine enters S1,
then S2,
	
	>then S3.  If the machine then takes a transition with 'anchor'
"foo", it
	
	>will return to S2 and roll back the data model.



And in this point machine enters to state S2 with anchor "Foo"

and saves state S2 as last visited for anchor type "Foo".

So in next transition to anchor "Foo" it must go
 to state S2.



I do understand your explanation but in this case you have to describe
in the next draft that

memory for saving anchor visits must be stack and this stack will be
changed only in regular visit 

but not in case of rollback by <anchor> transitions. 



"Question 2:  When the machine takes a transition with 'anchor' of "Foo"

back to state S2, the snapshots of all anchors visited since the last

time we were in S2 are erased (i.e. all snapshots "between" S2 and the

state that is the source of the transition.)"



All - is it meant other anchor types too?



"Given the logic of

anchors, none of these states can have an <anchor> of type "foo"."



So, as I understood I have to have sole stack of visited anchored states
and 

in rollback must pop states from this stack (with clearing all related
snapshots)

until find state with destination anchor.

Is it true?



"Question 3:  The current draft is not
 clear on this.  I would say it is

the state containing the <transition> with the 'anchor' attribute."



Yes, this looks as most reasonable case.

But I would like to note that placement transition to some level of
state hierarchy

can have just a reason of avoidance of repetitions in child states.

I can't imagine the rollback transition from leaf state 

and especially sense for reentering to this state.



But in the end I fell that I have more questions than I had. 

Could you publish some primer for this feature?

The primer that you have in mind when you invented anchors.



Regards, Serge.





  

________________________________

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.
<http://us.rd.yahoo.com/evt=48245/*http:/autos.yahoo.com/new_cars.html;_
ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-
>