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