W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2014

Re: Suggestions for onentry/onexit tags

From: Jim Barnett <1jhbarnett@gmail.com>
Date: Tue, 07 Jan 2014 10:22:18 -0500
Message-ID: <52CC1BAA.7000203@opayq.com>
To: www-voice@w3.org

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.

  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 
> <https://emails.abine.com/disableDisposable?fwd=FWD_1fRKqgy3@opayq.com>
> Le 3 jan 2014 à 09:58, Andreas Gansen <c64zottel@gmail.com 
> <mailto:c64zottel@gmail.com>> 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
Received on Wednesday, 8 January 2014 07:37:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:01 UTC