Propose a better structuring of the profile :
A Behavior can contain directly operations and attributes,
signals and contained behaviors.
This allows to represents directly Dialogs containing messages,
input events variables and sub-dialogs.
A Dialog is a Behavior which can contain directly operations,
Variables

(1) Insert a new section within Section 9 (The Voice UML Profile) named "Structure of a voice service model" with the following text:

A UML model may contain the definition of a single voice service or the definition of various voice services. A "Framework" package contains the lists of predefined signals and predefined operations that are available to all services. Each voice service is represented by a Package stereotyped <<Service>>. A package containing the definition of entities can be either contained within a <<Service>> package or live at same level - typically imported from other UML models. The latter is useful for services sharing the same set of entities.

The structure of a <<Service>> package should follow one of the two structural schemes:

Old style:
Entities defined specifically for the service are defined within a package stereotyped <<EntitiesModel>>.The dialogs are represented by a package stereotyped <<DialogModel>>. The main dialog is the unique <<DialogModel>> package directly contained by the <<Service>> package. A <<DialogModel>> has the following structure: a class stereotyped <<InputContainer>> to contain the locally defined input events (UML signals), a class stereotyped <<VariableContainer>> to contain the global variables (only for the main dialog), a class stereotyped <<MessageContainer>> to contain the messages (UML operations)
and a class stereotyped <<BehaviorContainer>> to contain the operation containing the behavior definition (state machine or activity graph). Sub dialogs are defined by nested packages stereotyped <<DialogModel>>.

New style:
Within the <<Service>> package, a dialog is directly defined by a behavior (either a state machine or an activity graph). The main dialog is the unique behavior directly contained by the <<Service>> package. Sub dialogs are defined as behaviors owned by the behavior representing the owning dialog. The input events are defined as signals owned by the <<Service>> package. Variables are defined as properties of the behavior and messages are defined as operations of the behavior.

These two styles are needed to cope with existing UML implementations. Old style can be used by UML 1.x conformant tools or UML2 tools that do not support the ability for a behavior to contain properties and operations.

(2) In page 28, within the line describing "Message", remove the sentence "The operation is owned by a class stereotyped <<MessageContainer>>".

(3) In Section 9.2 Stereotypes of the UML Voice Profile, after the table add the following sentence.

The following stereotypes are only applicable when the "old style" structural schema (see Section 9.1) is used: <<MessageContainer>>, <<InputContainer>>, <<BehaviorContainer>> and <<DialogModel>>.

(4) In Section 9.2 remove the stereotypes <<PackageModel>>, <<ConceptContainer>>. Note: These are duplicates of <<DialogModel>> and <<InputContainer>> respectively.

Some adjustments to the textual syntax are needed.
In particyular:
Allow decision with empty decision expression decision ()

Operator != is missing in BNF (found '<>' instead)

(1) In Section 10.2, after "This section gives formally the grammar.", adds the following paragraph:

Lexical elements:

The list of reserved words is:
'service', 'voiceservice', 'entities', 'package', 'class', 'operation', 'message', 'messagepart', 'event', 'externalevent', 'systemevent', 'static', 'global', 'shared', 'property', 'var', 'extends','maindialog', 'dialog', 'within', 'in','inout','out', 'behavior', 'play', 'playall', 'call', 'divert', 'return', 'stop', 'decision', 'case', 'junction', 'jump', 'restart', 'wait', 'when', 'do', 'accept', 'if', 'then', 'else', 'endif', 'null', 'true', 'false', 'unlimited', 'not', 'and','or','xor'','informal','new','Set','Bag','Sequence','OrderedSet'.

In the BNF these keywords are denoted by the corresponding word in capital letters. For instance DIALOG denotes the occurrence of the dialog keyword.

The following variable tokens are defined:

ID: an alphanumeric identifier
ICONST: integer value
FCONST: float value
SCONST: double quoted string
CCONST: single quoted string

The following character tokens are defined:
'PLUS' -> '+'
'MINUS' > ''
'TIMES' -> '*'
'DIVIDE' -> '/'
'MOD' -> '%'
'EQ' -> '=='
'LT' -> '<'
'LE' -> '<='
'LT' -> '<'
'GE' -> '>='
'GT' -> '>'
'NE' -> '<>'
'NEX' -> '!='
'EQUALS' -> '='
'PLUSEQUAL' -> '+='
'MINUSEQUAL' > '='
'ARROW' > '>'
'PERIOD' -> '.'
'LPAREN' -> '('
'RPAREN' -> ')'
'LBRACKET' -> '['
'RBRACKET' -> ']'
'LBRACE' -> '

'
'COMMA' -> ','
'SEMI' -> ';'
'COLON' -> ':'
'DCOLON' -> '::'

(2) Replace the BNF rule:
decision_head LBRACE decision_body RBRACE
by
decision_head LBRACE decision_body? RBRACE

A Model containing more than one Service. Entities that are
shared versus entities specific to a service. What about import
of external entities?? How to represent it?

RESOLUTION: Merged with issue 10961

Solved when applying resolution of issue 10961.

Should we allow global variables between dialogs that are not
connected (as it is currently)?

(1) In Section 8.3.1 Dialog, at the end of the actual property list, add a 'standalone' property with the following definition: "states whether the dialog is allowed to refer to global variables. If standalone is True no global variables can be used.
(2) Update Figure 8.5 by adding the Boolean standalone property in class Dialog.
(3) In the Textual syntax section (Section 10) add the 'standalone' keyword in the list of reserved words and adjust the BNF rule for dialog as follows:
Replace the definition of the 'dialog_head' non terminal by:
'dialog_head : 'standalone'? dialog_kind ID within_dialog_opt'

Allow usage of activity diagrams as alternative to state machine
when not available

After section 9.2 Stereotypes of the UML Voice Profile, add a section: "Using Activity diagrams to represent dialog behavior" with the following content.

For more flexibility in the implementation, the dialog behavior which, from a semantic point of view is defined by a state machine, can however be rendered by an activity diagram following some conventions.

When this variation in notation is used the following mappings should apply:

• An ActivityGraph replaces a StateMachine.
• A InitialNode replaces a Pseudostate with kind=initial
• A DecisionNode replaces a Pseudostate with kind=choice
• A MergeNode replaces a Pseudostate with kind=junction
• An ActivityFinalNode replaces a FinalState
• An Action replaces a State

The base classes for the stereotypes are changed according to these mappings.