Suggestions for onentry/onexit tags

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestions for onentry/onexit tags

Andreas Gansen
Hey there,

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

Would it not be better to have 0 or 1 occurrence?
That would avoid the question: How can I exit a state multiple times without re-enterring before?
The code from each handler would then be concatenated.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
 considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

Regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

David Junger
Le 3 jan 2014 à 09:58, Andreas Gansen <[hidden email]> a écrit :

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

As far as I know, there is one semantic feature of multiple onentry/onexit blocks: when an error occurs during execution of an executable block, the whole block's execution is aborted, but not the other executable blocks in the same state. You don't see what error has happened (for that, you need a transition with event="error.*", which will catch the error later), but it allows you to isolate "risky" executable content if the rest of the content doesn't depend on the success of previous blocks.

There is also a language design feature: authors don't automatically need to check for a previous handler in a big state when they write an onentry/onexit handler. It's good for modularity and collaborative editing. It also adds to expressivity: separate blocks are a good indication that the code inside is somewhat independent.

Would it not be better to have 0 or 1 occurrence?

As far as I can see, the only advantage of having a maximum of one onentry and one onexit block would be to shorten or remove a very cheap iteration.

How can I exit a state multiple times without re-enterring before?
When you re-enter a state, you must always run its onexit block(s) during the exit phase and its onentry block(s) during the entry phase of the microstep. That would be true even with your proposed modification.
If your implementation exits a state multiple times during one microstep, it's incorrect, and onexit blocks are the least of your worries.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
 considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

I'm pretty sure the correct meaning is zero or more.

David
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Jim Barnett
In reply to this post by Andreas Gansen
Andreas,
  David's response captures the groups reason for allowing multiple onexit and onentry handers.  In particular, the ability to isolate errors is a useful feature. 
  He is also correct that we intend to allow multiple onexit and onentry handlers in <final>.  It's an editing oversight that the current draft says 0 or 1, and I will fix it in the next draft.
  Please let me know if these responses answer your questions, or if you think that further discussion is required.

Best,
 

On 1/5/2014 6:43 PM, David Junger [Masked] wrote:
Preview: Le 3 jan 2014 à 09:58, Andreas Gansen a
Safely received through a Masked Email. IF THIS IS SPAM, CLICK HERE TO BLOCK THIS MASKED EMAIL.

Le 3 jan 2014 à 09:58, Andreas Gansen <[hidden email]> a écrit :

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

As far as I know, there is one semantic feature of multiple onentry/onexit blocks: when an error occurs during execution of an executable block, the whole block's execution is aborted, but not the other executable blocks in the same state. You don't see what error has happened (for that, you need a transition with event="error.*", which will catch the error later), but it allows you to isolate "risky" executable content if the rest of the content doesn't depend on the success of previous blocks.

There is also a language design feature: authors don't automatically need to check for a previous handler in a big state when they write an onentry/onexit handler. It's good for modularity and collaborative editing. It also adds to expressivity: separate blocks are a good indication that the code inside is somewhat independent.

Would it not be better to have 0 or 1 occurrence?

As far as I can see, the only advantage of having a maximum of one onentry and one onexit block would be to shorten or remove a very cheap iteration.

How can I exit a state multiple times without re-enterring before?
When you re-enter a state, you must always run its onexit block(s) during the exit phase and its onentry block(s) during the entry phase of the microstep. That would be true even with your proposed modification.
If your implementation exits a state multiple times during one microstep, it's incorrect, and onexit blocks are the least of your worries.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
 considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

I'm pretty sure the correct meaning is zero or more.

David

-- 
Jim Barnett
  Genesys
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Jim Barnett
In reply to this post by Andreas Gansen
Andreas,

David's answer captures our reasoning for allowing multiple occurrences on onentry and onexit.  The isolation of errors is subtle, but useful, feature.  David is also correct that the description of final should allow for 'one or more' occurrences on onentry and onexit.  It's an editorial oversight on my part that it doesn't, and I'll fix it in the next public draft. 

Please let me know if our response answers your question or if more discussion is needed.

Best,
 Jim Barnett

On 1/5/2014 6:43 PM, David Junger [Masked] wrote:
Preview: Le 3 jan 2014 à 09:58, Andreas Gansen a
Safely received through a Masked Email. IF THIS IS SPAM, CLICK HERE TO BLOCK THIS MASKED EMAIL.

Le 3 jan 2014 à 09:58, Andreas Gansen <[hidden email]> a écrit :

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

As far as I know, there is one semantic feature of multiple onentry/onexit blocks: when an error occurs during execution of an executable block, the whole block's execution is aborted, but not the other executable blocks in the same state. You don't see what error has happened (for that, you need a transition with event="error.*", which will catch the error later), but it allows you to isolate "risky" executable content if the rest of the content doesn't depend on the success of previous blocks.

There is also a language design feature: authors don't automatically need to check for a previous handler in a big state when they write an onentry/onexit handler. It's good for modularity and collaborative editing. It also adds to expressivity: separate blocks are a good indication that the code inside is somewhat independent.

Would it not be better to have 0 or 1 occurrence?

As far as I can see, the only advantage of having a maximum of one onentry and one onexit block would be to shorten or remove a very cheap iteration.

How can I exit a state multiple times without re-enterring before?
When you re-enter a state, you must always run its onexit block(s) during the exit phase and its onentry block(s) during the entry phase of the microstep. That would be true even with your proposed modification.
If your implementation exits a state multiple times during one microstep, it's incorrect, and onexit blocks are the least of your worries.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
 considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

I'm pretty sure the correct meaning is zero or more.

David

--
Jim Barnett Genesys
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Jim Barnett
In reply to this post by Andreas Gansen
Andreas,
  Please let us know if you are satisfied with our response to you email.  If we don't hear from you by January 21, we will assume that you are and proceed with publishing the next version of the specification.

  Best,
 Jim Barnett

On 1/3/2014 3:58 AM, Andreas Gansen [Masked] wrote:
Preview: Hey there, We are working on an SCXML-Editor. Between reading
Safely received through a Masked Email. IF THIS IS SPAM, CLICK HERE TO BLOCK THIS MASKED EMAIL.

Hey there,

We are working on an SCXML-Editor. Between reading the draft and parsing the scxml we noticed that onentry/onexit tags can occur 0 till inf times for a state.

Would it not be better to have 0 or 1 occurrence?
That would avoid the question: How can I exit a state multiple times without re-enterring before?
The code from each handler would then be concatenated.

Please note either way:
The final state 3.7.2 ( http://www.w3.org/TR/scxml/#final )
 considers one entry of onentry/onexit tags only.
While the schema does not:
http://www.w3.org/2011/04/SCXML/scxml-core-strict.xsd

Regards,

Andreas

--
Jim Barnett
Genesys
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Andreas Gansen
Hello David, Jim and List,

I am so sorry for not responding. I promise to do much better in the future.

Your reasoning is completely valid and understood. My only concern is
the semantic about onexit/onentry.
Even if it is well defined in the current version, I can't deny that it
is a bit unnatural to call a second onexit block
My suggestions to combine functionality and modularity would be as follows:
<onentry>
     <action> Code of the first onentry block </action>
     <action> ... 2nd entry block </action>
</onentry>

Variation:
Define actions in LLCA (or separate file for re-usage):
<actions>
     <action id="a1"> Codeblock </action>
     <action id="a2"> Codeblock </action>
</actions>

We just reference to the actions:
<onentry>
     <action id="a1" />
     <action id="a2" />
</onentry>

 From here we have a couple of advantages:
- Code block may be reused in the same file
- We may define all code blocks for onentry/onexit in separate file and
share this between different statecharts.
- The semantic is a bit cleaner (Maybe that is a personal view)

I am very aware of my inexperience when it comes to xml/statecharts and
I am fine with what ever solution you come up with.


Again, I am sorry for not responding. That is not my general being.

All the best,

Andreas Gansen

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

David Junger
Le 28 jan 2014 à 10:27, Andreas Gansen <[hidden email]> a écrit :

> Your reasoning is completely valid and understood. My only concern is the semantic about onexit/onentry.
> Even if it is well defined in the current version, I can't deny that it is a bit unnatural to call a second onexit block
> My suggestions to combine functionality and modularity would be as follows:
> <onentry>
>    <action> Code of the first onentry block </action>
>    <action> ... 2nd entry block </action>
> </onentry>

So… it's like multiple <onentry> but with extra tags inside?
It might be useful for <transition>s where only one executable block is allowed…

> Variation:
> Define actions in LLCA (or separate file for re-usage):
> <actions>
>    <action id="a1"> Codeblock </action>
>    <action id="a2"> Codeblock </action>
> </actions>
>
> We just reference to the actions:
> <onentry>
>    <action id="a1" />
>    <action id="a2" />
> </onentry>

There are standard ways to do templating in XML. I think it would be better to reuse those for interpreters that wish to support such things.

As for storing actions in external files, I am not a big fan (at all) of any use of 'src' attributes in executable content, since fetching the source may take a noticeable amount of time and create lag in the UI, even with good caching. I think it is preferable to insert external stuff into the SCXML before runtime, one way or another. Or load them asynchronously and use them once you get an event saying they are ready to use.

                        David
Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Andreas Gansen
Hello,


 >Le 28 jan 2014 à 10:27, Andreas Gansen <[hidden email]> a écrit :
 >
 >> Your reasoning is completely valid and understood. My only concern
is the semantic about onexit/onentry.
 >> Even if it is well defined in the current version, I can't deny that
it is a bit unnatural to call a second onexit block
 >> My suggestions to combine functionality and modularity would be as
follows:
 >> <onentry>
 >>    <action> Code of the first onentry block </action>
 >>    <action> ... 2nd entry block </action>
 >> </onentry>
 >
 >So… it's like multiple <onentry> but with extra tags inside?
 >It might be useful for <transition>s where only one executable block
is allowed…

It would be a single <onentry> with multiple tags with code blocks inside.
 From here it would also easily possible to extend functionality. For
example attributes:
<action paralell="1" >
<action paralell="3" >
All actions with parallel 1 can be run simultaneously, while 1 runs
before 3.
In times of multicores a valuable feature.

 >
 >> Variation:
 >> Define actions in LLCA (or separate file for re-usage):
 >> <actions>
 >>    <action id="a1"> Codeblock </action>
 >>    <action id="a2"> Codeblock </action>
 >> </actions>
 >>
 >> We just reference to the actions:
 >> <onentry>
 >>    <action id="a1" />
 >>    <action id="a2" />
 >> </onentry>
 >
 >There are standard ways to do templating in XML. I think it would be
better to reuse those for interpreters that wish to support such things.

I can't see the template pattern here. It is more a catalogue of
functions which can be referenced.
But I am sure it can be reconstructed with xml.

 >
 >As for storing actions in external files, I am not a big fan (at all)
of any use of 'src' attributes in executable content, since fetching the
source may take a noticeable amount of time and create lag in the UI,
even with good caching. I think it is preferable to insert external
stuff into the SCXML before runtime, one way or another. Or load them
asynchronously and use them once you get an event saying they are ready
to use.

I am not a big fan neither, unless it helps.
Having the code blocks outsourced would be an optional feature to share
between applications/statecharts. Hence it could also be used to reduce
bandwith usage of you see it as a library.

 >
 >                       David


Thanks,

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

David Junger
Le 28 jan 2014 à 14:16, Andreas Gansen <[hidden email]> a écrit :

<action paralell="1" >
<action paralell="3" >
All actions with parallel 1 can be run simultaneously, while 1 runs before 3.
In times of multicores a valuable feature.

Actions should always be very quick. It's the way SCs are designed. If a long process (or a dozen, or a hundred) should be run, use <invoke> instead, or actions that start a process but return immediately. In fact, <invoke> is quite good for managing multiple child processes, and you can easily add custom parameters to specify process priority. Look into it.

>There are standard ways to do templating in XML. I think it would be better to reuse those for interpreters that wish to support such things.

I can't see the template pattern here. It is more a catalogue of functions which can be referenced.
But I am sure it can be reconstructed with xml.

Well, executable content in SCXML is made of XML, not functions, so if you want to make it reuseable you need to reference an XML structure somehow…

Having the code blocks outsourced would be an optional feature to share between applications/statecharts. Hence it could also be used to reduce bandwith usage of you see it as a library.

… On the other hand, if you are only using scripts for executable content, you can of course use <script src> which is already defined in the spec, or, even better when available, load libraries into the parent context before runing the SCs, and make them available to the SCs using interpreter-specific functionnality (e.g. passing a dictionnary of JavaScript objects to the SCxml constructor in JSSCxml: http://www.jsscxml.org/api.html#constructor).

David
Reply | Threaded
Open this post in threaded view
|

RE: Suggestions for onentry/onexit tags

Michael Bodell-2

I agree with David quite strongly that for “non-instant” actions invoke is the way to go, and that mid statemachine derefercing to src (at least outside send/invoke) is best avoided where possible.

 

The multiple handlers currently in the specification is more forgiving if you allow xinclude or other preprocessing tricks to combine of states and handlers (or even the useful but old school copy/paste method of combination).  The semantics to an interpreter are clearly specified and a human reader/writer should be able to understand what multiple onentry/onexit handlers mean and do.  Multiple handlers (or “listeners”) is also something other systems support (like DOM 3 eventing), even if the bubble, target, capture algorithm is different than the statechart/state machine algorithm present in SCXML.

 

From: David Junger [mailto:[hidden email]]
Sent: Tuesday, January 28, 2014 9:11 AM
To: Voice Public List
Subject: Re: Suggestions for onentry/onexit tags

 

Le 28 jan 2014 à 14:16, Andreas Gansen <[hidden email]> a écrit :



<action paralell="1" >
<action paralell="3" >
All actions with parallel 1 can be run simultaneously, while 1 runs before 3.
In times of multicores a valuable feature.

 

Actions should always be very quick. It's the way SCs are designed. If a long process (or a dozen, or a hundred) should be run, use <invoke> instead, or actions that start a process but return immediately. In fact, <invoke> is quite good for managing multiple child processes, and you can easily add custom parameters to specify process priority. Look into it.

 

>There are standard ways to do templating in XML. I think it would be better to reuse those for interpreters that wish to support such things.

I can't see the template pattern here. It is more a catalogue of functions which can be referenced.
But I am sure it can be reconstructed with xml.

 

Well, executable content in SCXML is made of XML, not functions, so if you want to make it reuseable you need to reference an XML structure somehow…

 

Having the code blocks outsourced would be an optional feature to share between applications/statecharts. Hence it could also be used to reduce bandwith usage of you see it as a library.

 

… On the other hand, if you are only using scripts for executable content, you can of course use <script src> which is already defined in the spec, or, even better when available, load libraries into the parent context before runing the SCs, and make them available to the SCs using interpreter-specific functionnality (e.g. passing a dictionnary of JavaScript objects to the SCxml constructor in JSSCxml: http://www.jsscxml.org/api.html#constructor).

 

                                    David

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Andreas Gansen
Hi,

Hm, I viewed it more in sense of a function call, but it is actually
an ordered list of handlers. Now I see also the flexibility through
Chapters 4 and 5, which makes it possible to construct easily my
function-like interpretation by using <script src..>

@David: Thanks for your Master-Thesis. Is your performance test setup
somewhere online?

I really appreciate your help.

Tusen takk,

Andreas




On 28 January 2014 21:08, Michael Bodell <[hidden email]> wrote:

> I agree with David quite strongly that for "non-instant" actions invoke is
> the way to go, and that mid statemachine derefercing to src (at least
> outside send/invoke) is best avoided where possible.
>
>
>
> The multiple handlers currently in the specification is more forgiving if
> you allow xinclude or other preprocessing tricks to combine of states and
> handlers (or even the useful but old school copy/paste method of
> combination).  The semantics to an interpreter are clearly specified and a
> human reader/writer should be able to understand what multiple
> onentry/onexit handlers mean and do.  Multiple handlers (or "listeners") is
> also something other systems support (like DOM 3 eventing), even if the
> bubble, target, capture algorithm is different than the statechart/state
> machine algorithm present in SCXML.
>
>
>
> From: David Junger [mailto:[hidden email]]
> Sent: Tuesday, January 28, 2014 9:11 AM
> To: Voice Public List
> Subject: Re: Suggestions for onentry/onexit tags
>
>
>
> Le 28 jan 2014 à 14:16, Andreas Gansen <[hidden email]> a écrit :
>
>
>
> <action paralell="1" >
> <action paralell="3" >
> All actions with parallel 1 can be run simultaneously, while 1 runs before
> 3.
> In times of multicores a valuable feature.
>
>
>
> Actions should always be very quick. It's the way SCs are designed. If a
> long process (or a dozen, or a hundred) should be run, use <invoke> instead,
> or actions that start a process but return immediately. In fact, <invoke> is
> quite good for managing multiple child processes, and you can easily add
> custom parameters to specify process priority. Look into it.
>
>
>
>>There are standard ways to do templating in XML. I think it would be better
>> to reuse those for interpreters that wish to support such things.
>
> I can't see the template pattern here. It is more a catalogue of functions
> which can be referenced.
> But I am sure it can be reconstructed with xml.
>
>
>
> Well, executable content in SCXML is made of XML, not functions, so if you
> want to make it reuseable you need to reference an XML structure somehow...
>
>
>
> Having the code blocks outsourced would be an optional feature to share
> between applications/statecharts. Hence it could also be used to reduce
> bandwith usage of you see it as a library.
>
>
>
> ... On the other hand, if you are only using scripts for executable content,
> you can of course use <script src> which is already defined in the spec, or,
> even better when available, load libraries into the parent context before
> runing the SCs, and make them available to the SCs using
> interpreter-specific functionnality (e.g. passing a dictionnary of
> JavaScript objects to the SCxml constructor in JSSCxml:
> http://www.jsscxml.org/api.html#constructor).
>
>
>
>                                     David

Reply | Threaded
Open this post in threaded view
|

Re: Suggestions for onentry/onexit tags

Andreas Gansen
Hello Jim,

I am very fine with the responses.

Thank you.

Andreas


On 29 January 2014 00:31, Jim Barnett <[hidden email]> wrote:

> Andreas,
>     Are you satisfied with David and Michael's responses?  At this point in the process, we do not want to entertain substantive revisions to the specification, because we are trying to get version 1.0 finished, and the only way to do that is to freeze the spec.  We will be happy to consider significant revisions in a future versions of the specification.
>
> Please let us know if you are satisfied with this response.  If we do not hear from you by February 5th, we will assume that you are.
>
> Best,
>  Jim Barnett
>
> -----Original Message-----
> From: Andreas Gansen [mailto:[hidden email]]
> Sent: Tuesday, January 28, 2014 5:01 PM
> To: Michael Bodell
> Cc: David Junger; Voice Public List
> Subject: Re: Suggestions for onentry/onexit tags
>
> Hi,
>
> Hm, I viewed it more in sense of a function call, but it is actually an ordered list of handlers. Now I see also the flexibility through Chapters 4 and 5, which makes it possible to construct easily my function-like interpretation by using <script src..>
>
> @David: Thanks for your Master-Thesis. Is your performance test setup somewhere online?
>
> I really appreciate your help.
>
> Tusen takk,
>
> Andreas
>
>
>
>
> On 28 January 2014 21:08, Michael Bodell <[hidden email]> wrote:
>> I agree with David quite strongly that for "non-instant" actions
>> invoke is the way to go, and that mid statemachine derefercing to src
>> (at least outside send/invoke) is best avoided where possible.
>>
>>
>>
>> The multiple handlers currently in the specification is more forgiving
>> if you allow xinclude or other preprocessing tricks to combine of
>> states and handlers (or even the useful but old school copy/paste
>> method of combination).  The semantics to an interpreter are clearly
>> specified and a human reader/writer should be able to understand what
>> multiple onentry/onexit handlers mean and do.  Multiple handlers (or
>> "listeners") is also something other systems support (like DOM 3
>> eventing), even if the bubble, target, capture algorithm is different
>> than the statechart/state machine algorithm present in SCXML.
>>
>>
>>
>> From: David Junger [mailto:[hidden email]]
>> Sent: Tuesday, January 28, 2014 9:11 AM
>> To: Voice Public List
>> Subject: Re: Suggestions for onentry/onexit tags
>>
>>
>>
>> Le 28 jan 2014 à 14:16, Andreas Gansen <[hidden email]> a écrit :
>>
>>
>>
>> <action paralell="1" >
>> <action paralell="3" >
>> All actions with parallel 1 can be run simultaneously, while 1 runs
>> before 3.
>> In times of multicores a valuable feature.
>>
>>
>>
>> Actions should always be very quick. It's the way SCs are designed. If
>> a long process (or a dozen, or a hundred) should be run, use <invoke>
>> instead, or actions that start a process but return immediately. In
>> fact, <invoke> is quite good for managing multiple child processes,
>> and you can easily add custom parameters to specify process priority. Look into it.
>>
>>
>>
>>>There are standard ways to do templating in XML. I think it would be
>>>better  to reuse those for interpreters that wish to support such things.
>>
>> I can't see the template pattern here. It is more a catalogue of
>> functions which can be referenced.
>> But I am sure it can be reconstructed with xml.
>>
>>
>>
>> Well, executable content in SCXML is made of XML, not functions, so if
>> you want to make it reuseable you need to reference an XML structure somehow...
>>
>>
>>
>> Having the code blocks outsourced would be an optional feature to
>> share between applications/statecharts. Hence it could also be used to
>> reduce bandwith usage of you see it as a library.
>>
>>
>>
>> ... On the other hand, if you are only using scripts for executable
>> content, you can of course use <script src> which is already defined
>> in the spec, or, even better when available, load libraries into the
>> parent context before runing the SCs, and make them available to the
>> SCs using interpreter-specific functionnality (e.g. passing a
>> dictionnary of JavaScript objects to the SCxml constructor in JSSCxml:
>> http://www.jsscxml.org/api.html#constructor).
>>
>>
>>
>>                                     David
>
>