Clarification/Feedback about event counters.


I find the current form of event counter clarification in the recent
VoiceXML specification confusing and not correct.

In [section 5.2.2 Catch] under attribute table for "count" attribute
description says:

Statement 1:
"Each <form>, <menu> and form item maintains a counter for each event that
occurs while it is being visited; these counters are reset each time the
<menu> or form item's <form> is re-entered."

And later in the same section it says that these counters are actually
associated with handlers as in following statement:

Statement 2:
"occurrence of the event "" increments the counters associated
with handlers for "" plus "" and "event"."

Are there two different set of counters one maintained at form, menu or form
item level or other which are maintained with handlers ? I guess not and in
that case I propose following text:

"occurrence of the event "" increments the counters associated
with <form>, <menu> or form item for "" plus "" and

Also, in *Statement 1* above it is mentioned that on re-entry of  form
item's <form> or <menu> these counters are reset (Although, I think
technically it would be more correct to say that these counters are reset
when execution transitions out from the current scope of the <form> or
<menu>), what happens if a form item is re-visited without leaving the
<form>? Shouldn't the event counters associated with form item be reset?

Also as in the following text under same section:

"The form-level counters are used in the selection of an event handler for
events thrown in a form-level <filled>."  And current description of <clear>
element provides a way to control these event counters only for form items.
Do we see a need for providing something similar to <clear> for <form> and
<menu> level counters.

And, I find this current description not very useful about incrementing
counters for every prefix matching event name in *statement 2*. I think a
simple logic like, incrementing counter only for the event name that has
been just handled due to current throw, should be useful.

Mukul Jain
Cisco Systems, Inc.

Received on Wednesday, 10 July 2002 17:18:13 UTC