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: Mon, 06 Jan 2014 09:36:45 -0500
Message-ID: <52CABF7D.8090409@opayq.com>
To: www-voice@w3.org
   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.


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
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