Wiki

Version 124 (Herwin van Welbergen, 05/21/2012 04:47 pm)

1 1 Anonymous
h1. BML 1.0 Standard
2 1 Anonymous
3 53 Anonymous
{{toc}}
4 53 Anonymous
5 1 Anonymous
This document introduces and describes version 1.0 of the Behavior Markup Language standard. This document contains background information, descriptions of typical use contexts, and, most importantly, the syntactic and semantic details of the XML format of the Behavior Markup Language.
6 27 Anonymous
7 2 Anonymous
h1. Introduction
8 1 Anonymous
9 89 Herwin van Welbergen
The Behavior Markup Language, or BML, is an XML description language for controlling the verbal and nonverbal behavior of (humanoid) embodied conversational agents (ECAs). A BML block (see example in figure below) describes the physical realization of behaviors (such as speech and gesture) and the synchronization constraints between these behaviors. BML is _not_ concerned with the communicative intent underlying the requested behaviors. The module that executes behaviors specified in BML on the embodiment of the ECA is called a _BML Realizer_.
10 1 Anonymous
11 31 Anonymous
!bmlexample.png!
12 11 Anonymous
_Figure 1: Example of a BML Request_
13 2 Anonymous
14 3 Anonymous
h2. Core Standard and Extensions
15 2 Anonymous
16 2 Anonymous
The BML Standard consists of a small and lean core, plus a few clearly defined mechanisms for extending the language.
17 2 Anonymous
18 1 Anonymous
h3. Lean Core Standard
19 3 Anonymous
20 32 Anonymous
The Core of the BML Standard defines the form and use of BML blocks, mechanisms for synchronisation, the basic rules for feedback about the processing of BML messages (see later in this document), plus a number of generic basic behaviors. BML compliant realizers implement the complete BML Core Standard and provide a meaningful execution for all its behavior elements. Some realizers might offer only partial compliance, for example because they only steer a head (and therefore do not need to interpret bodily behaviors). In that case, a realizer should at least provide an exception/warning feedback when being requested to execute unsupported Core Standard behaviors (see [[Wiki#Feedback|Feedback]]).
21 1 Anonymous
22 11 Anonymous
    |*What:*         |BML Core Standard. |
23 1 Anonymous
    |*Status:*        |Mandatory. |
24 1 Anonymous
    |*XML namespace:* |http://www.bml-initiative.org/bml/bml-1.0 |
25 71 Anonymous
    |*Examples:*      |[[Wiki#ltspeechgt|basic speech]], [[Wiki#ltpointinggt|pointing gestures]] |
26 11 Anonymous
27 11 Anonymous
h3. Extensions
28 11 Anonymous
29 91 Herwin van Welbergen
BML provides several standardized mechanisms for extension. One can define new behaviors (in a custom namespace), or extend upon Core behaviors by adding custom attributes. *_Description extensions_* provide a standardized manner for a user to give more detail about how the BML Realizer should realize a given instance of a core behavior, while allowing a fallback to the Core specification when the BML Realizer does not support the extension.
30 11 Anonymous
31 92 Herwin van Welbergen
The BML standard defines a number of Core Extensions, both in the form of additional behaviors and in the form of description extensions. The Core Extensions provide behaviors and description levels that we  do not want to make mandatory, but we do want to be implemented in a standardized way whenever a BML Realizer implements them. We encourage authors of realizers to collaborate and define shared behavior types and descriptions beyond those provided by the core extensions.
32 11 Anonymous
33 11 Anonymous
    |*What:*         |BML Core Extensions. |
34 11 Anonymous
    |*Status:*        |Optional, but if a realizer implements the functionality of a Core Extension, it should exactly follow the standard specification. |
35 11 Anonymous
    |*XML namespace:* |http://www.bml-initiative.org/bml/...  (last part is specified in the definition of the Core Extension) |
36 49 Anonymous
    |*Examples:*      |[[Wiki#ltfaceFacsgt|FACS face expressions]], SSML description extension for speech |
37 11 Anonymous
38 11 Anonymous
h1. Global Context
39 11 Anonymous
40 11 Anonymous
h2. SAIBA
41 11 Anonymous
42 12 Anonymous
The Behavior Markup Language is part of the SAIBA Multimodal Behavior Generation Framework (see Figure 2 below). In this framework, the intention for the ECA to express something arises in the *_Intent Planner_*. The *_Behavior Planner_* is responsible for deciding which multimodal behaviors to choose for expressing the communicative intent (through speech, face expressions, gestures, etcetera) and for specifying proper synchronisation between the various modalities. This multimodal behavior is specified in the form of BML messages. A *_BML Realizer_* is responsible for physically realizing the specified BML message through sound and motion (animation, robot movement, ...), in such a way that the time constraints specified in the BML block are satisfied. At runtime, the BML realizer sends back feedback messages to keep the planning modules updated about the progress and result of the realization of previously sent BML messages, allowing, e.g., for monitoring and possible error recovery.
43 11 Anonymous
44 11 Anonymous
!http://www.mindmakers.org/attachments/download/187!
45 11 Anonymous
_Figure 2: SAIBA Framework_
46 11 Anonymous
47 11 Anonymous
  {{div_start_tag(intentplanning, inset)}}
48 11 Anonymous
        _The exact nature of the intent and behavior planning processes is left unspecified here. As far as the BML Realizer is concerned, it makes no difference whether BML messages are the result of a complicated multimodal affective dialog system, or are simply predefined BML messages pulled from a library of pre-authored materials._
49 11 Anonymous
  {{div_end_tag}}
50 11 Anonymous
51 11 Anonymous
h2. BML Messaging Architecture
52 11 Anonymous
53 11 Anonymous
BML does not prescribe a specific message transport. Different architectures have drastically different notions of a message. A message may come in the form of a string, an XML document or DOM, a message object, or just a function call. However, no matter what message transport is used, the transport and routing layer should adhere to the following requirements:
54 11 Anonymous
55 11 Anonymous
*  Messages must be received in sent order.
56 11 Anonymous
*  Messages must contain specific contents that can be fully expressed as XML expressions in the format detailed in this document.
57 11 Anonymous
 
58 11 Anonymous
Currently, there are two types of messages: 
59 11 Anonymous
    
60 11 Anonymous
*  BML Requests.
61 11 Anonymous
**  Sent by the Behavior Planner to the Behavior Realizer.
62 11 Anonymous
**  BML requests are sent as <bml> blocks containing a number of behavior elements with synchronisation.
63 11 Anonymous
*  Feedback Messages.
64 1 Anonymous
**  Sent by the Behavior Realizer.
65 1 Anonymous
**  Used to inform the planner (and possibly other processes) of the progress of the realization process.
66 11 Anonymous
    
67 12 Anonymous
h2. The BML Realizer
68 1 Anonymous
69 93 Herwin van Welbergen
Conceptually, BML Realizers execute a multimodal plan that is incrementally constructed (scheduled) on the basis of a stream of incoming BML Requests (see Figure 3). A BML Realizer is responsible for executing the behaviors specified in each BML request sent to it, in such a way that the time constraints specified in the BML request are satisfied. If a new request is sent before the realisation of previous requests has been completed, a composition attribute determines how to combine the behaviors in the new request with the behaviors from earlier requests (see [[Wiki#Composition|documentation of composition attribute]]).
70 1 Anonymous
71 14 Anonymous
Each BML Request represents a scheduling boundary. That is: if behaviors are in the same BML request, this means that the constraints between them are resolved before any of the behaviors in the request is executed. 
72 14 Anonymous
73 14 Anonymous
!{width:20em}Scheduling.png!
74 1 Anonymous
_Figure 3: Dealing with an incoming stream of BML Requests_
75 1 Anonymous
76 105 Anonymous
h2. The State of an ECA
77 105 Anonymous
78 105 Anonymous
BML assumes that there is something like a ground state of the ECA. This state comprises several elements, such as the permanent posture or the ground state of the face. For example, when a temporary @<posture>@ behavior ends, the ECA reverts to the posture defined in the groud state; when a temporary face expression ends, the face of the ECA reverts to a ground state. Some types of behavior have a residual effect. That is, after the end time of the behavior has been reached, the ground state of the ECA will be different than before the behavior started. Such behaviors are generally names @<...Shift>@. Details can be found at the documentation of each particular element; here we present a table of dimensions to the ground state of the ECA, and behaviors that may influence this ground state.
79 105 Anonymous
80 105 Anonymous
|_./ Ground state aspect |_. Behaviors that change this state |
81 105 Anonymous
| Body posture | @<postureShift>@ |
82 105 Anonymous
| Head pose | @<headDirectionShift>@ |
83 105 Anonymous
| Face expression | @<faceShift>@ |
84 105 Anonymous
|Gaze direction | @<gazeShift>@ |
85 105 Anonymous
| Location in the world | @<locomotion>@ |
86 105 Anonymous
87 1 Anonymous
h1. XML Format: Values and Types
88 15 Anonymous
89 15 Anonymous
Before describing the various XML elements in the BML Standard, we describe here the available attribute types.
90 15 Anonymous
91 95 Herwin van Welbergen
We use camelCase throughout for element names and attribute names. Values of type openSetItem and closedSetItem defined in this document are generally all uppercase. The names of default syncpoints for various behavior types are also written in camelCase (e.g., strokeStart).
92 15 Anonymous
93 15 Anonymous
h2. Attribute Value Types
94 15 Anonymous
95 15 Anonymous
Values for various types of behavior attributes can be one of the following:
96 15 Anonymous
97 15 Anonymous
* *ID:* An identifier that is unique within a specified context (see <bml> and "behavior element"). Adheres to "standard XML type ID":http://www.w3.org/TR/REC-xml/#sec-attribute-types 
98 87 Herwin van Welbergen
* *syncref:* describes the relative timing of sync points (see [[Wiki#Synchronisation|the section on synchronisation]])
99 29 Anonymous
* *worldObjectID:* A unique ID of an object in the character's world. Adheres to "standard XML type ID":http://www.w3.org/TR/REC-xml/#sec-attribute-types 
100 46 Anonymous
* *targetID:* A unique ID referring to a target in the character's world. Adheres to "standard XML type ID":http://www.w3.org/TR/REC-xml/#sec-attribute-types 
101 15 Anonymous
* *closedSetItem:* A string from a closed set of strings, where the standard will provide the exhaustive list of strings in the set. 
102 15 Anonymous
* *openSetItem:* A string from an open set of strings, where the standard may provide a few common strings in the set.
103 15 Anonymous
* *bool:* A truth value, either "true" or "false"
104 15 Anonymous
* *int:* A whole number
105 15 Anonymous
* *float:* A number with decimals
106 15 Anonymous
* *angle:* A float number specifying angle in degrees counterclockwise, from (-180, 180].
107 15 Anonymous
* *string:* An arbitrary string
108 15 Anonymous
* *direction:* A particular closedSetItem type from the ClosedSet [LEFT, RIGHT, UP, DOWN, FRONT, BACK, UPRIGHT, UPLEFT, DOWNLEFT, DOWNRIGHT]
109 15 Anonymous
* *vector:* a string of format “float; float; float” indicating the x, y, and z coordinates of a vector
110 15 Anonymous
111 15 Anonymous
h2. Coordinate System and Units
112 15 Anonymous
113 15 Anonymous
While we prefer specifying behavior by common verbs and nouns, for some attributes or applications it is unavoidable to use precise vectors. 
114 15 Anonymous
115 1 Anonymous
All units are in kms (kilograms, meters, seconds).
116 1 Anonymous
117 16 Anonymous
BML assumes a *global* coordinate system in which the positive Y-axis is up. The *local* (character-based) coordinate system[1] adheres to the guidelines of the H-Anim standard ( "v1.1":http://h-anim.org/Specifications/H-Anim1.1/#modeling and "H-Anim":http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774/concepts.html#ModellingOfHumanoids ): _"The humanoid shall be modelled in a standing position, facing in the +Z direction with +Y up and +X to the humanoid's left. The local character-based origin (0, 0, 0) shall be located at ground level, between the humanoid's feet."_ 
118 16 Anonymous
119 16 Anonymous
fn1. _Currently, there are no expressions in BML 1.0 that actually use the local character based coordinate system. However, future versions may introduce references such as "2 meters to the left of the character"._
120 1 Anonymous
121 63 Anonymous
h1. -------------------------------------------------
122 63 Anonymous
123 23 Anonymous
h1. <bml> request
124 16 Anonymous
125 25 Anonymous
All BML behaviors must belong to a @<bml>@ behavior block. A @<bml>@ block is formed by placing one or more BML behavior elements inside a top-level @<bml>@ element. Unless synchronization is specified (see [[Wiki#Synchronisation|the section on synchronisation]]), it is assumed that all behaviors in a @<bml>@ block start at the same time after arriving at the BML realizer.
126 16 Anonymous
127 61 Anonymous
h2. Syntax @ @
128 16 Anonymous
129 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
130 16 Anonymous
|*ELEMENT:*    |@<bml>@ |
131 16 Anonymous
|*ATTRIBUTES:* |@characterId@, @id@, @composition@ |
132 16 Anonymous
|*CONTENTS:*   |behaviors of various types, @<required>@ blocks, @<constraint>@ blocks |
133 16 Anonymous
134 1 Anonymous
<pre><code class="xml">
135 1 Anonymous
  <bml xmlns="http://www.bml-initiative.org/bml/bml-1.0" 
136 116 Alexis Heloir
       id="bml1" characterId="Alice" composition="MERGE">
137 1 Anonymous
  </bml>
138 1 Anonymous
</code></pre>
139 1 Anonymous
_Example: An empty @<bml>@ request_
140 44 Anonymous
141 59 Anonymous
h2. Attribute Details @ @
142 44 Anonymous
143 44 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
144 44 Anonymous
|characterId |worldObjectID |optional |"" |a reference towards the controlled character |
145 44 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ block. The id 'bml' is reserved. |
146 86 Herwin van Welbergen
|composition |openSetItem |optional |"MERGE" |one among [MERGE,APPEND,REPLACE], defines the composition policy to apply if the current @<bml>@ block overlaps with previous @<bml>@ blocks (see below). |
147 16 Anonymous
148 61 Anonymous
h2. Semantics @ @
149 16 Anonymous
150 59 Anonymous
h3. No Communicative Meaning @ @
151 16 Anonymous
152 16 Anonymous
The BML specification does not prescribe a communicative meaning for the BML Request. This allows users of BML to specify short spurts of behavior (for example: speech clauses or individual gaze shifts) and generate performances incrementally, or, if they prefer, to construct elaborate performances as a whole and send them in a single request (for example: entire monologues).
153 16 Anonymous
154 59 Anonymous
h3. Ordering is not meaningful @ @
155 1 Anonymous
156 39 Anonymous
The order of elements inside the @<bml>@ block does not have any semantic meaning. Authors writing BML expressions should not rely on a BML Realizer realizing something in a certain order because it is in a certain order in the BML block
157 16 Anonymous
158 59 Anonymous
h3. Start time, end time, delays @ @
159 16 Anonymous
160 1 Anonymous
Each @<bml>@ request represents a scheduling boundary. That is: if behaviors are in the same @<bml>@ request, this means that the constraints between them are resolved before any of the behaviors in the request is executed. 
161 16 Anonymous
162 17 Anonymous
*start time* -- the start time of a block b is the global timestamp when it actually starts being executed. The start time may be influenced by various delays, as well as by the composition attribute (both explained further below).
163 1 Anonymous
*end time* -- the end time of a block is the global timestamp when all behaviors in the block have ended.
164 17 Anonymous
165 16 Anonymous
  {{div_start_tag(realisationdelay, inset)}}
166 24 Anonymous
      _When a planner sends a @<bml>@ request to a realizer, there will be a slight (hopefully negligible) delay before the behavior actually starts being performed on the embodiment. The transport and routing layer supporting the transmission of a sequence of @<bml>@ blocks will introduce a transmission delay; parsing the request and solving the constraints may introduce another delay._
167 16 Anonymous
  {{div_end_tag}}
168 16 Anonymous
169 60 Anonymous
h3. Composition @ @
170 16 Anonymous
171 16 Anonymous
If a new request is sent before the realisation of previous requests has been completed, a composition attribute determines how to combine the behaviors in the new @<bml>@ block with the behaviors from prior @<bml>@ blocks. The values for the composition attribute have the following meaning.
172 16 Anonymous
173 86 Herwin van Welbergen
* *MERGE:* _(default)_ The start time of the new @<bml>@ block will be as soon as possible. The behaviors specified in the new @<bml>@ block will be realized together with the behaviors specified in prior @<bml>@ blocks. In case of conflict, behaviors in the newly merged @<bml>@ block cannot modify behaviors defined by prior @<bml>@ blocks. 
174 86 Herwin van Welbergen
* *APPEND:* The start time of the new block will be as soon as possible after the end time of all prior blocks. 
175 86 Herwin van Welbergen
* *REPLACE:* The start time of the new block will be as soon as possible. The new block will completely replace all prior @<bml>@ blocks. All behavior specified in earlier blocks will be ended and the ECA will revert to a neutral state before the new block starts.
176 28 Anonymous
177 1 Anonymous
  {{div_start_tag(betweenblockconflict, inset)}}
178 32 Anonymous
      _As an example of a merge conflict, one might consider two consecutive @<bml>@ blocks that both specify a right handed gesture, with the timing being such that they should be performed at the same time. When this turns out to be impossible, the gesture in the block that arrived last should be dropped, and an appropriate warning should be issued (see [[Wiki#Feedback|Feedback]] section)_
179 1 Anonymous
  {{div_end_tag}}
180 17 Anonymous
181 23 Anonymous
h1. <required>
182 17 Anonymous
183 32 Anonymous
It is generally assumed that the behavior realizer will attempt to realize all behaviors in a block, but if some of the behaviors don't successfully complete for some reason, other behaviors still get carried out (see [[Wiki#Feedback|Feedback]] and [[Wiki#Failure-and-Fallback|Failure and Fallback]]).
184 17 Anonymous
185 17 Anonymous
If there is an all-or-nothing requirement for all or some of the behaviors, they can be enclosed in a @<required>@ block inside the @<bml>@ block.
186 17 Anonymous
187 61 Anonymous
h2. Syntax @ @
188 17 Anonymous
189 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
190 17 Anonymous
|*ELEMENT:*    |@<required>@ |
191 17 Anonymous
|*ATTRIBUTES:* |none |
192 17 Anonymous
|*CONTENTS:*   |behaviors of various types, @<constraint>@ blocks |
193 17 Anonymous
194 61 Anonymous
h2. Semantics @ @
195 17 Anonymous
196 17 Anonymous
If behaviors or constraints enclosed in a @<required>@ block cannot be realized, the complete @<bml>@ block of which the @<required>@ block is a part should be aborted, with appropriate feedback.
197 17 Anonymous
198 32 Anonymous
In the following example, the entire performance in the @<bml>@ block will be aborted if either the gaze or the speech behavior is unsuccessful (and an appropriate feedback message sent back from the behavior realizer, see [[Wiki#Feedback|Feedback]] section), but if only the head nod is unsuccessful, the rest will be carried out regardless (and an appropriate feedback message sent back from the behavior realizer).
199 17 Anonymous
200 17 Anonymous
<pre><code language="xml">
201 17 Anonymous
  <bml id="bml1" xmlns="http://www.bml-initiative.org/bml/bml-1.0" character="Alice">
202 17 Anonymous
    <required>
203 17 Anonymous
      <gaze id="gaze1" target="PERSON1"/>
204 17 Anonymous
      <speech id="speech1"><text>Welcome to my humble abode</text></speech>
205 17 Anonymous
    </required>
206 17 Anonymous
    <head id="nod1" type="NOD"/>
207 17 Anonymous
  </bml>
208 17 Anonymous
</code></pre>
209 17 Anonymous
210 30 Anonymous
h1. Behaviors (common aspects)
211 17 Anonymous
212 17 Anonymous
A behavior element describes one kind of a behavior to the behavior realizer. In its simplest form, a behavior element is a single XML tag with a few key attributes:
213 17 Anonymous
214 17 Anonymous
<pre><code language="xml">
215 17 Anonymous
  <bml id="bml1" xmlns="http://www.bml-initiative.org/bml/bml-1.0" character="Alice">
216 17 Anonymous
     <gaze id="gaze1" target="PERSON1"/>
217 17 Anonymous
  </bml>
218 17 Anonymous
</code></pre>
219 17 Anonymous
220 17 Anonymous
221 61 Anonymous
h2. Syntax @ @
222 17 Anonymous
223 17 Anonymous
This document specifies a number of XML elements for specifying various sorts of behavior. Any behavior element has at least the following attributes: 
224 17 Anonymous
225 17 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
226 17 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular behavior. The id 'bml' is reserved. |
227 87 Herwin van Welbergen
|start |syncref |optional | |Determines the start time of the behavior, either as offset relative to the start time of the enclosing @<bml>@ block, or relative to another behavior contained in this block or in another block. If no syncrefs are specified for this behavior, start time is 0; if start is unspecified but other syncrefs are given for this behavior, start is determined by the other syncrefs (and the possible duration for this behavior). |
228 87 Herwin van Welbergen
|end |syncref |optional | |local end time of the behavior, either as offset relative to the start time of the enclosing @<bml>@ block, or relative to another behavior contained in this block or in another block. If unspecified, the end time will be dependent on the start time, other syncrefs specified on this behavior, and the possible duration of the behavior. |
229 17 Anonymous
230 72 Anonymous
In addition, there may be sync attributes concerning other default sync points for a specific behavior type.
231 17 Anonymous
232 61 Anonymous
h2. Semantics @ @
233 17 Anonymous
234 17 Anonymous
There are a few aspects concerning the semantics of behaviors that are common to all behavior types.
235 17 Anonymous
236 60 Anonymous
h3. Timing and synchronisation @ @
237 1 Anonymous
238 25 Anonymous
Unless synchronization or timing constraints are specified, it is assumed that all behaviors in a @<bml>@ block start at the start time of the @<bml>@ block. In [[Wiki#Synchronisation|the section on synchronisation]], more detail is given concerning how to specify such constraints.
239 18 Anonymous
240 60 Anonymous
h3. Targets in the world  @ @
241 1 Anonymous
242 1 Anonymous
Some of the behavior types specified in this document, require reference to a *target* in the world (gaze target, point target, ...). A BML Realizer may assume a number of predefined targets, referenced by an attribute value of type worldObjectID. 
243 1 Anonymous
244 1 Anonymous
  {{div_start_tag(target, inset)}}
245 75 Anonymous
      For next version, we are working on working out a "target" element that allows more control over specification and modification of targets in the world.
246 75 Anonymous
  {{div_end_tag}}
247 1 Anonymous
248 60 Anonymous
h3. Behaviors with residual effect @ @
249 24 Anonymous
250 24 Anonymous
Some types of behavior have a residual effect. That is, after the end time of the behavior has been reached, the ground state of the ECA will be different than before the behavior started. 
251 24 Anonymous
252 24 Anonymous
An example of a behavior type _with_ a residual effect is @<locomotion>@: after a @<locomotion>@ behavior has been completed, part of the ground state of the ECA (in this case: location and orientation in the world) will be different than before, and other behaviors will be realized from this new ground state. 
253 24 Anonymous
254 24 Anonymous
An example of a behavior type _without_ a residual effect is @<point>@: usually, realization of a @<point>@ behavior involves a final retraction phase that returns the ECA back to the ground state in which it was before starting realization of the @<point>@ behavior. 
255 24 Anonymous
256 1 Anonymous
A number of behavior types exist both in a version with and without residual effect. For example, after completion of a @<face>@ behavior, the face of the ECA returns to the state it was in before the @<face>@ behavior started, but a @<faceShift>@ behavior will cause the face of the ECA to have a new ground state. 
257 1 Anonymous
258 1 Anonymous
When both versions of a behavior are active at the same time, the version without residual effect has priority for being displayed, but the ground state is nevertheless changed by the behavior with residual effect. 
259 1 Anonymous
260 62 Anonymous
261 39 Anonymous
262 25 Anonymous
h1. Synchronisation
263 1 Anonymous
264 72 Anonymous
For every behavior, its realization may be broken down into phases. Each phase is bounded by a sync-point that carries the name of the transition it represents, making it relatively straight-forward to align behaviors at meaningful boundaries (see Figure 4 for an example of the sync points for gestures). In the example below, the speech behavior and the point gesture are aligned at their start times.
265 29 Anonymous
266 25 Anonymous
<pre><code language="xml">
267 25 Anonymous
  <bml id="bml1" xmlns="http://www.bml-initiative.org/bml/bml-1.0" character="Alice">
268 123 Herwin van Welbergen
    <pointing id="behavior1" target="blueBox" mode="RIGHT_HAND" start="speech1:start"/> 
269 25 Anonymous
    <speech id="speech1"><text>Look there!</text></speech>
270 25 Anonymous
  </bml>
271 25 Anonymous
</code></pre>
272 25 Anonymous
_Example: speech and gesture aligned at their start times_
273 25 Anonymous
274 25 Anonymous
!gesturephases.png!
275 25 Anonymous
_Figure 4: Synchronisation points for a gesture_
276 25 Anonymous
277 61 Anonymous
h2. Syntax @ @
278 25 Anonymous
279 87 Herwin van Welbergen
Synchronisation is specified by assigning a syncref value to one or more of the sync attributes of a behavior. 
280 25 Anonymous
281 87 Herwin van Welbergen
An syncref value is one of the following two forms:
282 25 Anonymous
283 87 Herwin van Welbergen
* @[block_id:]behavior_id:sync_id [+/- offset]@ -- A reference to a sync point of another behavior, optionally with a float offset in seconds. By default, this is a behavior in the same @<bml>@ block that the syncref is contained in; if optional prefix @block_id:@ is present, the syncref specifies a sync point of a behavior in the @<bml>@ block with that ID.)
284 25 Anonymous
* @offset@ --A positive float offset in seconds relative to the start time of the surrounding @<bml>@ block.
285 25 Anonymous
286 25 Anonymous
<pre><code language="xml">
287 25 Anonymous
  <!-- Timing example behaviors -->
288 25 Anonymous
  <gaze start="0.3" end="2.14" /><!-- absolute timing in seconds -->
289 25 Anonymous
  <gaze stroke="behavior1:stroke" /><!-- relative to another behavior -->
290 25 Anonymous
  <gaze ready="behavior1:relax + 1.1" /><!-- relative to another behavior, with offset -->
291 25 Anonymous
  <gaze ready="bml3:behavior1:relax" /><!-- relative to a behavior in another block -->
292 25 Anonymous
</code></pre>
293 25 Anonymous
294 96 Herwin van Welbergen
h3. The constraint element
295 97 Herwin van Welbergen
296 96 Herwin van Welbergen
The <constraint> element provides a container for specifying additional constraints on the performance. BML 1.0 only defines three timing constraints:
297 96 Herwin van Welbergen
298 96 Herwin van Welbergen
    * <synchronize> declares one or more sync points should be synchronized with a referenced sync-point notation
299 96 Herwin van Welbergen
    * <before> declares one or more sync points should be performed before a referenced sync-point notation
300 96 Herwin van Welbergen
    * <after> declares one or more sync points should be performed after a referenced sync-point notation
301 96 Herwin van Welbergen
302 96 Herwin van Welbergen
h4. <synchronize> 
303 96 Herwin van Welbergen
304 96 Herwin van Welbergen
<synchronize> constraints perform just like the sync-point attribute constaints, performing the sync-points of two or more behaviors at the same time.
305 96 Herwin van Welbergen
<pre>
306 96 Herwin van Welbergen
<constraint id="synchronize_example">
307 99 Herwin van Welbergen
  <synchronize>
308 99 Herwin van Welbergen
    <sync ref="speech1:sync4"/>
309 96 Herwin van Welbergen
    <sync ref="beat1:stroke:2"/>
310 96 Herwin van Welbergen
    <sync ref="nod1:stroke"/>
311 96 Herwin van Welbergen
  </synchronize>
312 96 Herwin van Welbergen
</constraint>
313 96 Herwin van Welbergen
</pre>
314 96 Herwin van Welbergen
315 96 Herwin van Welbergen
This generalizes the attribute notation in three ways:
316 96 Herwin van Welbergen
317 96 Herwin van Welbergen
    * A constraint can synchronize sync-points that do not have an attribute notation, such as speech word breaks and multi-stroke rhythmic gestures.
318 96 Herwin van Welbergen
    * A constraint can synchronize more than two behaviors to the same point.
319 96 Herwin van Welbergen
    * A constraint can remain optional (outside any <required> element) while the presence of the behaviors is still <required>.
320 96 Herwin van Welbergen
321 96 Herwin van Welbergen
h4. <before>
322 96 Herwin van Welbergen
323 96 Herwin van Welbergen
<before> constrains one or more sync-points to perform before a specified sync-point notation.
324 96 Herwin van Welbergen
325 96 Herwin van Welbergen
<pre>
326 96 Herwin van Welbergen
<constraint id="before_example">
327 96 Herwin van Welbergen
  <before ref="speech_1:start">
328 96 Herwin van Welbergen
    <sync ref="gaze_1:stroke"/>
329 96 Herwin van Welbergen
  </before>
330 96 Herwin van Welbergen
</constraint>
331 96 Herwin van Welbergen
</pre>
332 96 Herwin van Welbergen
333 96 Herwin van Welbergen
This constraint example requires the gaze_1 to acquire target (complete the stroke sync-point) before beginning speech_1.
334 96 Herwin van Welbergen
335 96 Herwin van Welbergen
h5. <after>
336 96 Herwin van Welbergen
337 96 Herwin van Welbergen
<after> constrains one or more sync-points to perform before a specified sync-point notation.
338 96 Herwin van Welbergen
339 96 Herwin van Welbergen
<pre>
340 96 Herwin van Welbergen
<constraint id="after_example">
341 96 Herwin van Welbergen
  <after ref="speech_1:end+2">
342 96 Herwin van Welbergen
    <sync ref="gaze_1:relax"/>
343 96 Herwin van Welbergen
  </after>
344 96 Herwin van Welbergen
</constraint>
345 96 Herwin van Welbergen
</pre>
346 96 Herwin van Welbergen
347 96 Herwin van Welbergen
This constraint example requires two seconds to pass after speech_1 completes before relaxing gaze_1.
348 96 Herwin van Welbergen
Extending <constraint>
349 96 Herwin van Welbergen
350 96 Herwin van Welbergen
We encourage BML developers to experiment with using the constraint element for the alternative functions through the use of namespaced elements and <description> extensions, for example:
351 96 Herwin van Welbergen
352 96 Herwin van Welbergen
    * To specify some tolerance range for a synchronization operation.
353 96 Herwin van Welbergen
    * To specify a certain priority for a particular synchronization operation.
354 96 Herwin van Welbergen
    * To specify non-timing constraints such as modality
355 96 Herwin van Welbergen
356 109 Anonymous
h3. The <wait> element
357 96 Herwin van Welbergen
358 109 Anonymous
The <wait> element is a NO-OP behavior that facilitates flexible waiting times between behaviors.
359 109 Anonymous
360 109 Anonymous
<pre><code class="xml">
361 109 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
362 109 Anonymous
		character="Alice"
363 109 Anonymous
		id="bml1">
364 109 Anonymous
	<speech id="behavior1" start="0">			
365 109 Anonymous
        <text>
366 109 Anonymous
        Good morning.
367 109 Anonymous
        </text>
368 109 Anonymous
    </speech>
369 122 Herwin van Welbergen
    <wait id="behavior2" start="behavior1:end" duration="1"/>
370 122 Herwin van Welbergen
    <speech id="behavior3" start="behavior2:end">			
371 109 Anonymous
        <text>
372 109 Anonymous
        Goodbye.
373 109 Anonymous
        </text>
374 109 Anonymous
    </speech>
375 109 Anonymous
</bml>
376 109 Anonymous
</code></pre>
377 109 Anonymous
_Example: Wait for one second between the two speech fragments._
378 119 Herwin van Welbergen
379 119 Herwin van Welbergen
h4. Syntax @ @
380 119 Herwin van Welbergen
381 119 Herwin van Welbergen
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
382 119 Herwin van Welbergen
|*ELEMENT:*    |@<wait>@ |
383 119 Herwin van Welbergen
|*SYNC POINTS:* | @start@, @end@ |
384 119 Herwin van Welbergen
|*ATTRIBUTES:* |@id@, @duration@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
385 119 Herwin van Welbergen
|*CONTENTS:*   |none |
386 120 Herwin van Welbergen
387 120 Herwin van Welbergen
h4. Attribute details
388 121 Herwin van Welbergen
389 120 Herwin van Welbergen
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
390 120 Herwin van Welbergen
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
391 1 Anonymous
|duration|float|optional||the duration of the wait in seconds|
392 1 Anonymous
393 122 Herwin van Welbergen
|_.Sync Attribute |_.Description |
394 122 Herwin van Welbergen
|start| start of wait |
395 122 Herwin van Welbergen
|end| end of wait |
396 1 Anonymous
  
397 61 Anonymous
h2. Semantics @ @
398 29 Anonymous
399 1 Anonymous
The synchronization constraints described above are all bidirectional. That is:
400 1 Anonymous
401 1 Anonymous
@<head id="head1" stroke="gesture1:stroke" ... />@
402 1 Anonymous
403 1 Anonymous
means that the the strokes of head1 and gesture1 should be aligned. This synchronization constraint must be interpreted bidirectional: the exact same time constraint can be expressed by:
404 1 Anonymous
405 1 Anonymous
@<gesture id="gesture1" stroke="head1:stroke" ... />@
406 1 Anonymous
407 72 Anonymous
h3. Default Sync Points and their Sync Attributes @ @
408 1 Anonymous
409 72 Anonymous
All behaviors have sync points called @start@ and @end@. Furthermore, for each behavior type a number of additional default sync points may be available. For every default sync point, the corresponding behavior XML element has a sync attribute of the same name. 
410 1 Anonymous
411 72 Anonymous
h3. New Sync Points  @ @
412 1 Anonymous
413 72 Anonymous
New sync points can be introduced for specific behavior types or description extensions. For example, in speech one can use the special @<sync>@ tag to insert additional sync points in speech.
414 1 Anonymous
415 72 Anonymous
When new sync-points are introduced for a behavior, it is assumed that @start@ and @end@ will still refer to the first and last sync-point for that behavior.
416 1 Anonymous
417 1 Anonymous
h1. Face behaviors
418 1 Anonymous
419 1 Anonymous
The face can be controlled through various mechanisms. The @<faceLexeme>@ behavior offers a range of predefined expressions such as "RAISE_EYEBROWS"; a limited set of mandatory lexemes is defined that should be offered by any BML Realizer. The optional @<faceFacs>@ Core Extension allows precise control of the face in terms of the Facial Action Coding Scheme of Ekman. Finally, @<face>@ and @<faceShift>@ allow one to combine a set of partial expressions into one compound face expression, where the former is temporary, and the latter changes the BASE state of the ECAs face.
420 1 Anonymous
421 72 Anonymous
All face behavior types use the same set of sync points @start@, @attackPeak@, @relax@, and @end@. These sync points define a dynamic progress like in Figure 6 below. By using the Core Extension attribute @overshoot@, one can use these same alignment points to achieve a dynamic progress like in Figure 7, where @attackPeak@ is the peak point of the initial overshoot of the face expression. 
422 72 Anonymous
423 72 Anonymous
!OnsetApexOffset.png!
424 72 Anonymous
_Figure 6: Onset/apex/offset dynamics specified using the sync points and the @amount@ attribute._
425 72 Anonymous
426 72 Anonymous
!AttackSustainRelease.png!
427 74 Anonymous
_Figure 7: Attack/sustain/release dynamics specified using the sync points and the @amount@ attribute plus the Core Extension @overshoot@ attribute._
428 72 Anonymous
429 72 Anonymous
h2. Shared face attributes
430 72 Anonymous
431 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
432 72 Anonymous
433 72 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
434 74 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
435 72 Anonymous
|amount|float|optional|0.5|A float value between 0..1 to indicate the amount to which the expression should be shown on the face, 0 meaning 'not at all' and 1 meaning 'maximum, highly exaggerated'|
436 72 Anonymous
437 72 Anonymous
438 72 Anonymous
|_.Sync Attribute |_.Description |
439 72 Anonymous
|start		|beginning of face expression |
440 72 Anonymous
|attackPeak	|maximum expression achieved	|
441 72 Anonymous
|relax		|decay phase starts, _not for <faceShift> behaviors!_ |
442 72 Anonymous
|end			|face expression ended, _not for <faceShift> behaviors!_ |
443 72 Anonymous
444 74 Anonymous
h2. "overshoot" Core Extension attribute
445 72 Anonymous
446 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/coreextensions-1.0 |
447 72 Anonymous
448 72 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
449 98 Herwin van Welbergen
|overshoot|float |optional | 0 | Fraction of overshoot of the attack peak, relative to @amount@ (which defines the level of the sustain phase)|
450 72 Anonymous
451 1 Anonymous
h2. <faceLexeme>
452 1 Anonymous
453 72 Anonymous
Show a (partial) face expression from a predefined lexicon.
454 72 Anonymous
455 72 Anonymous
h3. Syntax @ @
456 72 Anonymous
457 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
458 72 Anonymous
|*ELEMENT:*    |@<faceLexeme>@ |
459 72 Anonymous
|*SYNC POINTS:* | @start@, @attackPeak@, @relax@, @end@ |
460 72 Anonymous
|*ATTRIBUTES:* |@id@, @lexeme@, @amount@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]], Core Extension @overshoot@ |
461 72 Anonymous
|*CONTENTS:*   |none |
462 72 Anonymous
463 72 Anonymous
<pre><code class="xml">
464 72 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
465 72 Anonymous
		character="Alice"
466 72 Anonymous
		id="bml1">
467 72 Anonymous
	<faceLexeme id="behavior1" lexeme="RAISE_BROWS" amount="0.8" start="0" end="4"/>			
468 72 Anonymous
</bml>
469 72 Anonymous
</code></pre>
470 72 Anonymous
_Example: Raise both eye brows for 4 seconds._
471 72 Anonymous
472 72 Anonymous
h3. Attribute Details @ @
473 72 Anonymous
474 72 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
475 1 Anonymous
|lexeme|openSetItem|required||One of [OBLIQUE_BROWS, RAISE_BROWS, RAISE_LEFT_BROW, RAISE_RIGHT_BROW, LOWER_BROWS, LOWER_LEFT_BROW, LOWER_RIGHT_BROW, LOWER_MOUTH_CORNERS, LOWER_LEFT_MOUTH_CORNER, LOWER_RIGHT_MOUTH_CORNER, RAISE_MOUTH_CORNERS, RAISE_RIGHT_MOUTH_CORNER, RAISE_LEFT_MOUTH_CORNER, OPEN_MOUTH, OPEN_LIPS, WIDEN_EYES, CLOSE_EYES]|
476 1 Anonymous
477 75 Anonymous
The following table shows suggested interpretations that a BML Realizer can use for the lexemes using Ekman's Facial Action Coding System. To offer the user more detailed control of the face, providing an implementation of the @<faceFacs>@ element is suggested.
478 75 Anonymous
479 75 Anonymous
|_. Lexeme |_. FACS equivalent|
480 75 Anonymous
|OBLIQUE_BROWS | AU1+AU4 both sides |
481 75 Anonymous
| RAISE_BROWS | AU1+AU2 both sides |
482 75 Anonymous
| RAISE_LEFT_BROW | AU1+AU2 left side |
483 75 Anonymous
| RAISE_RIGHT_BROW | AU1+AU2 right side |
484 75 Anonymous
| LOWER_BROWS | AU4 both sides |
485 75 Anonymous
| LOWER_LEFT_BROW | AU4 left side  |
486 75 Anonymous
| LOWER_RIGHT_BROW | AU4 right side |
487 75 Anonymous
| LOWER_MOUTH_CORNERS | AU15 both sides |
488 75 Anonymous
| LOWER_LEFT_MOUTH_CORNER | AU15 left side |
489 75 Anonymous
| LOWER_RIGHT_MOUTH_CORNER | AU15 right side |
490 75 Anonymous
| RAISE_MOUTH_CORNERS | AU12 both sides |
491 75 Anonymous
| RAISE_LEFT_MOUTH_CORNER | AU12 left side   |
492 75 Anonymous
| RAISE_RIGHT_MOUTH_CORNER | AU12 right side |
493 75 Anonymous
| OPEN_MOUTH | AU25+AU26 |
494 75 Anonymous
| OPEN_LIPS | AU25 |
495 75 Anonymous
| WIDEN_EYES | AU5+AU7 |
496 75 Anonymous
| CLOSE_EYES | AU43 |
497 75 Anonymous
498 72 Anonymous
h3. Semantics @ @
499 72 Anonymous
500 72 Anonymous
This behavior shows a (partial) face expression from a predefined lexicon. A faceLexeme is a convenience shorthand for combinations of more detailed low level face controls. The provided set of core lexemes allows one to perform face expressions using meaningful lexeme names, which are easier to learn than the (more detailed) Action Units provided by the @faceFacs@ element.
501 72 Anonymous
502 1 Anonymous
h2. <faceFacs> Core Extension
503 1 Anonymous
504 72 Anonymous
This behavior provides control of the face through single Action Units from the Facial Action Coding Scheme. It is an Core Extension, that is, not every BML Compliant Realizer has to implement this behavior, but if a Realizer offers FACS based face control, they should adhere to the specification of this @<faceFacs>@ behavior
505 1 Anonymous
506 72 Anonymous
h3. Syntax @ @
507 72 Anonymous
508 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/coreextensions-1.0 |
509 72 Anonymous
|*ELEMENT:*    |@<faceFacs>@ |
510 72 Anonymous
|*SYNC POINTS:* | @start@, @attackPeak@, @relax@, @end@ |
511 72 Anonymous
|*ATTRIBUTES:* |@id@, @au@, @side@, @amount@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]], Core Extension @overshoot@ |
512 72 Anonymous
|*CONTENTS:*   |none |
513 72 Anonymous
514 72 Anonymous
<pre><code class="xml">
515 72 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
516 73 Anonymous
    xmlns:ext="http://www.bml-initiative.org/bml/coreextensions-1.0"
517 73 Anonymous
 		character="Alice"
518 73 Anonymous
 		id="bml1">
519 73 Anonymous
	<ext:faceFacs id="behavior1" au="1" side="BOTH" amount="0.8" start="0" end="4"/>			
520 72 Anonymous
</bml>
521 72 Anonymous
</code></pre>
522 72 Anonymous
_Example: Raise both eye brows for 4 seconds._
523 72 Anonymous
524 72 Anonymous
h3. Attribute Details @ @
525 72 Anonymous
526 72 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
527 72 Anonymous
|au|int|required||The number of the FACS Action Unit to be displayed |
528 72 Anonymous
|side|closedSetItem|optional|BOTH| Which side of the face to display the action unit on. Possible values: [LEFT,RIGHT,BOTH] Note that for some Action Units, BOTH is the only possible value. |
529 72 Anonymous
530 72 Anonymous
h3. Semantics @ @
531 72 Anonymous
532 72 Anonymous
This behavior provides control of the face through single Action Units from the Facial Action Coding Scheme. It is an Core Extension, that is, not every BML Compliant Realizer has to implement this behavior, but if a Realizer offers FACS based face control, they should adhere to the specification of this @<faceFacs>@ behavior
533 72 Anonymous
534 72 Anonymous
A BML Compliant Realizer that implements this extension will provide at least the set of Action Units listed below. The other Action Units are not mandatory, but implementing the full set of Action Units is strongly recommended.
535 1 Anonymous
536 1 Anonymous
h2. <face>
537 1 Anonymous
538 73 Anonymous
Compound behavior to specify the timing and alignment of several (partial) face expressions as one unit.
539 73 Anonymous
540 73 Anonymous
h3. Syntax @ @
541 73 Anonymous
542 73 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
543 73 Anonymous
|*ELEMENT:*    |@<face>@ |
544 1 Anonymous
|*SYNC POINTS:* | @start@, @attackPeak@, @relax@, @end@ |
545 1 Anonymous
|*ATTRIBUTES:* |@id@, @amount@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]], Core Extension @overshoot@ |
546 76 Anonymous
|*CONTENTS:*   | <lexeme>, with attributes @lexeme@ and @amount@ that can take the same values as for the @<faceLexeme>@ behavior.|
547 76 Anonymous
|| <facs>, with attributes @au@, @side@ and @amount@ that can take the same values as for the @<faceFacs>@ element. (This child element is only available if FACS Core Extension is implemented; this @<facs>@ child element has the same namespace as the @<faceFacs>@ behavior element) |
548 73 Anonymous
549 73 Anonymous
<pre><code class="xml">
550 73 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
551 73 Anonymous
     xmlns:ext="http://www.bml-initiative.org/bml/coreextensions-1.0"
552 73 Anonymous
		 character="Alice"
553 73 Anonymous
		 id="bml1">
554 73 Anonymous
	<face id="behavior1" amount="0.8" start="0" end="4">			
555 73 Anonymous
	  <ext:facs au="1" side="BOTH"/>
556 74 Anonymous
	  <lexeme lexeme="WIDEN_EYES"/>
557 73 Anonymous
	</face>
558 73 Anonymous
</bml>
559 73 Anonymous
</code></pre>
560 73 Anonymous
_Example: Raise both eye brows for 4 seconds._
561 73 Anonymous
562 73 Anonymous
563 1 Anonymous
h2. <faceShift>
564 73 Anonymous
565 73 Anonymous
Compound behavior to specify the timing and alignment of several (partial) face expressions as one unit, where the specified compound face expression becomes the new BASE state of the ECAs face.
566 73 Anonymous
567 73 Anonymous
h3. Syntax @ @
568 73 Anonymous
569 1 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
570 117 Alexis Heloir
|*ELEMENT:*    |@<faceShift>@ |
571 73 Anonymous
|*SYNC POINTS:* | @start@, @end@ |
572 73 Anonymous
|*ATTRIBUTES:* |@id@, @amount@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
573 76 Anonymous
|*CONTENTS:*   | <lexeme>, with attributes @lexeme@ and @amount@ that can take the same values as for the @<faceLexeme>@ behavior.|
574 76 Anonymous
|| <facs>, with attributes @au@, @side@ and @amount@ that can take the same values as for the @<faceFacs>@ element. (This child element is only available if FACS Core Extension is implemented; this @<facs>@ child element has the same namespace as the @<faceFacs>@ behavior element) |
575 73 Anonymous
576 73 Anonymous
<pre><code class="xml">
577 73 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
578 73 Anonymous
     xmlns:ext="http://www.bml-initiative.org/bml/coreextensions-1.0"
579 73 Anonymous
		 character="Alice"
580 73 Anonymous
		 id="bml1">
581 73 Anonymous
	<faceShift id="behavior1" amount="0.8" start="0" end="4">			
582 73 Anonymous
	  <ext:facs au="1" side="BOTH"/>
583 74 Anonymous
	  <lexeme lexeme="WIDEN_EYES"/>
584 74 Anonymous
	</faceShift>
585 73 Anonymous
</bml>
586 73 Anonymous
</code></pre>
587 73 Anonymous
_Example: Raise both eye brows for 4 seconds._
588 73 Anonymous
589 73 Anonymous
h3. Semantics @ @
590 73 Anonymous
591 73 Anonymous
Compound behavior to specify the timing and alignment of several (partial) face expressions as one unit, where the specified compound face expression becomes the new BASE state of the ECAs face as soon as the behavior ends. 
592 61 Anonymous
593 46 Anonymous
h1. Gaze behaviors
594 46 Anonymous
595 46 Anonymous
h2. <gaze>
596 1 Anonymous
597 55 Anonymous
Temporarily directs the gaze of the character towards a target.
598 46 Anonymous
599 46 Anonymous
h3. Syntax @ @
600 46 Anonymous
601 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
602 46 Anonymous
|*ELEMENT:*    |@<gaze>@ |
603 72 Anonymous
|*SYNC POINTS:* | @start@, @ready@, @relax@, @end@ |
604 118 Alexis Heloir
|*ATTRIBUTES:* |@id@, @target@, @influence@, @offsetAngle@, @offsetDirection@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
605 46 Anonymous
|*CONTENTS:*   |none |
606 46 Anonymous
607 46 Anonymous
<pre><code class="xml">
608 46 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
609 60 Anonymous
		character="Alice"
610 46 Anonymous
		id="bml1">
611 115 Herwin van Welbergen
	<gaze id="gaze1" start="1" end="10" influence="NECK" target="bluebox"/>	
612 65 Anonymous
</bml>
613 66 Anonymous
</code></pre>
614 66 Anonymous
_Example: Direct the gaze towards the blue box for 9 seconds, using the eyes and the neck._
615 66 Anonymous
616 66 Anonymous
h3. Attribute Details @ @
617 66 Anonymous
618 46 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
619 61 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
620 46 Anonymous
|target|targetID|required| |A reference towards a target instance that represents the target direction of the gaze. |
621 1 Anonymous
|influence|openSetItem|optional| | Determines what parts of the body to move to effect the gaze direction. [EYES, HEAD, SHOULDER, WAIST, WHOLE, ...] |
622 118 Alexis Heloir
|offsetAngle	|angle	|optional	|0.0	|Adds an angle degrees offset to gaze direction relative to the target in the direction specified in the @offsetDirection@ |
623 118 Alexis Heloir
|offsetDirection	|direction	|optional	|RIGHT	|Direction of the offsetDirection angle [RIGHT, LEFT, UP, DOWN, UPRIGHT, UPLEFT, DOWNLEFT, DOWNRIGHT, POLAR]|
624 1 Anonymous
625 1 Anonymous
|_.Sync Attribute |_.Description |
626 1 Anonymous
|start| gaze starts to move to new target |
627 1 Anonymous
|ready| gaze target acquired |
628 47 Anonymous
|relax| gaze starts returning to default direction |
629 47 Anonymous
|end| gaze returned to default direction |
630 47 Anonymous
631 61 Anonymous
h3. Semantics @ @
632 47 Anonymous
633 47 Anonymous
This behavior causes the character to temporarily direct its gaze to the requested target. The @influence@ parameter is read as follows: EYE means 'use only the eyes'; HEAD means 'use only head and eyes to change the gaze direction', etcetera.
634 1 Anonymous
635 47 Anonymous
h2. <gazeShift>
636 55 Anonymous
637 47 Anonymous
Permanently change the gaze direction of the character towards a certain target. 
638 47 Anonymous
639 47 Anonymous
h3. Syntax @ @
640 47 Anonymous
641 1 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
642 1 Anonymous
|*ELEMENT:*    |@<gazeShift>@ |
643 72 Anonymous
|*SYNC POINTS:* | @start@, @end@ |
644 118 Alexis Heloir
|*ATTRIBUTES:* |@id@, @target@, @influence@, @offsetAngle@, @offsetDirection@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
645 47 Anonymous
|*CONTENTS:*   |none |
646 47 Anonymous
647 47 Anonymous
<pre><code class="xml">
648 47 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
649 47 Anonymous
		character="Alice"
650 60 Anonymous
		id="bml1">
651 115 Herwin van Welbergen
	<gazeShift id="gaze1" start="1" end="2" influence="NECK" target="bluebox"/>	
652 47 Anonymous
</bml>
653 1 Anonymous
</code></pre>
654 1 Anonymous
_Example: Change the default gaze direction to be towards the blue box; the shift in gaze takes 1 second to be ready._
655 65 Anonymous
656 66 Anonymous
h3. Attribute Details @ @
657 47 Anonymous
658 61 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
659 47 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
660 1 Anonymous
|target|targetID|required| |A reference towards a target instance that represents the target direction of the gaze. |
661 1 Anonymous
|influence|openSetItem|optional| | Determines what parts of the body to move to effect the gaze direction. [EYES, HEAD, SHOULDER, WAIST, WHOLE, ...] |
662 118 Alexis Heloir
|offsetAngle	|angle	|optional	|0.0	|Adds an angle degrees offset to gaze direction relative to the target in the direction specified in the @offsetDirection@ |
663 118 Alexis Heloir
|offsetDirection	|direction	|optional	|RIGHT	|Direction of the offsetDirection angle [RIGHT, LEFT, UP, DOWN, UPRIGHT, UPLEFT, DOWNLEFT, DOWNRIGHT, POLAR]|
664 1 Anonymous
665 31 Anonymous
|_.Sync Attribute |_.Description |
666 71 Anonymous
|start|gaze starts to move to new target |
667 71 Anonymous
|end|gaze target acquired |
668 1 Anonymous
669 36 Anonymous
h3. Semantics @ @
670 69 Anonymous
671 69 Anonymous
This behavior causes the character to direct its gaze to the requested target. This changes the default state of the ECA: after completing this behavior, the new target is the default gaze direction of the ECA. The @influence@ parameter is read as follows: EYE means 'use only the eyes'; HEAD means 'use only head and eyes to change the gaze direction', etcetera.
672 69 Anonymous
673 69 Anonymous
h1. Gesture behaviors
674 69 Anonymous
675 69 Anonymous
Currently, BML offers two types of gesture behaviors. The first provides a set of gestures recalled by name from a gesticon; the second provides simple pointing gestures. 
676 69 Anonymous
677 69 Anonymous
h2. <gesture>
678 69 Anonymous
679 69 Anonymous
Coordinated movement with arms and hands, recalled from a gesticon by requesting the corresponding lexeme
680 69 Anonymous
681 69 Anonymous
h3. Syntax @ @
682 69 Anonymous
683 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
684 69 Anonymous
|*ELEMENT:*    |@<gesture>@ |
685 77 Anonymous
|*SYNC POINTS:* | @start@, @ready@, @strokeStart@, @stroke@, @strokeEnd@, @relax@, @end@ |
686 72 Anonymous
|*ATTRIBUTES:* |@id@, @lexeme@, @mode@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
687 69 Anonymous
|*CONTENTS:*   |none |
688 69 Anonymous
689 69 Anonymous
<pre><code class="xml">
690 69 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
691 69 Anonymous
		character="Alice"
692 69 Anonymous
		id="bml1">
693 69 Anonymous
	<gesture id="behavior1" lexeme="hello-waving" start="2"/>			
694 69 Anonymous
</bml>
695 69 Anonymous
</code></pre>
696 69 Anonymous
_Example: Make a waving gesture._
697 69 Anonymous
698 1 Anonymous
h3. Attribute Details @ @
699 1 Anonymous
700 1 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
701 69 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
702 102 Anonymous
|mode|closedSetItem|optional|RIGHT|What hand/arm is being used [LEFT_HAND, RIGHT_HAND, BOTH_HANDS]|
703 102 Anonymous
|lexeme|openSetItem|required||Refers to an animation or a controller to realize this particular gesture.Every realizer will offer at least this set of possible values: [BEAT] |
704 69 Anonymous
705 69 Anonymous
|_.Sync Attribute |_.Description |
706 69 Anonymous
|start		|beginning of gesture				|
707 69 Anonymous
|ready		|end of gesture preparation phase	 	|
708 77 Anonymous
|strokeStart	|start of the stroke					|
709 70 Anonymous
|stroke		|gesture stroke						|
710 77 Anonymous
|strokeEnd	|end of stroke						|
711 70 Anonymous
|relax		|start of retraction phase				|
712 70 Anonymous
|end			|end of gesture						|
713 70 Anonymous
714 70 Anonymous
h3. Semantics @ @
715 70 Anonymous
716 70 Anonymous
Coordinated movement with arms and hands, recalled from a gesticon by requesting the corresponding lexeme
717 70 Anonymous
718 70 Anonymous
h2. <pointing>
719 70 Anonymous
720 70 Anonymous
Deictic gesture towards the target specified by the target attribute
721 70 Anonymous
722 70 Anonymous
h3. Syntax @ @
723 70 Anonymous
724 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
725 70 Anonymous
|*ELEMENT:*    |@<pointing>@ |
726 77 Anonymous
|*SYNC POINTS:* | @start@, @ready@, @strokeStart@, @stroke@, @strokeEnd@, @relax@, @end@ |
727 72 Anonymous
|*ATTRIBUTES:* |@id@, @target@, @mode@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
728 70 Anonymous
|*CONTENTS:*   |none |
729 70 Anonymous
730 70 Anonymous
<pre><code class="xml">
731 70 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
732 70 Anonymous
		character="Alice"
733 70 Anonymous
		id="bml1">
734 124 Herwin van Welbergen
	<pointing id="behavior1" target="blueBox" mode="RIGHT_HAND" start="0" end="4"/>			
735 70 Anonymous
</bml>
736 70 Anonymous
</code></pre>
737 70 Anonymous
_Example: Point at the blue box._
738 1 Anonymous
739 70 Anonymous
h3. Attribute Details @ @
740 70 Anonymous
741 70 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
742 70 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
743 102 Anonymous
|mode|closedSetItem|optional|RIGHT|What hand/arm is being used [LEFT_HAND, RIGHT_HAND, BOTH_HANDS][3]|
744 1 Anonymous
|target|targetID|required||The gesture is directed towards this target|
745 1 Anonymous
746 70 Anonymous
fn3. _The set of values for @mode@ may in the future be extended with options such as HEAD or FOOT
747 70 Anonymous
748 70 Anonymous
|_.Sync Attribute |_.Description |
749 70 Anonymous
|start		|beginning of gesture				|
750 36 Anonymous
|ready		|end of gesture preparation phase	 	|
751 77 Anonymous
|strokeStart	|start of the stroke					|
752 36 Anonymous
|stroke		|gesture stroke						|
753 77 Anonymous
|strokeEnd	|end of stroke						|
754 45 Anonymous
|relax		|start of retraction phase				|
755 64 Anonymous
|end			|end of gesture						|
756 64 Anonymous
757 64 Anonymous
758 64 Anonymous
h3. Semantics @ @
759 64 Anonymous
760 64 Anonymous
Deictic gesture towards the target specified by the target attribute.
761 64 Anonymous
762 64 Anonymous
h1. Head behaviors
763 64 Anonymous
764 64 Anonymous
h2. <head>
765 64 Anonymous
766 64 Anonymous
Movement of the head, recalled from a gesticon by requesting the corresponding lexeme.
767 64 Anonymous
768 64 Anonymous
h3. Syntax @ @
769 64 Anonymous
770 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
771 67 Anonymous
|*ELEMENT:*    |@<head>@ |
772 77 Anonymous
|*SYNC POINTS:* | @start@, @ready@, @strokeStart@, @stroke@, @strokeEnd@, @relax@, @end@ |
773 78 Anonymous
|*ATTRIBUTES[2]:* |@id@, @lexeme@, @repetition@, @amount@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
774 1 Anonymous
|*CONTENTS:*   |none |
775 64 Anonymous
776 78 Anonymous
fn2. _The attribute @speed@ is being discussed as possible extensions; however, they are not part of the Core 1.0 Standard._
777 65 Anonymous
778 64 Anonymous
<pre><code class="xml">
779 65 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
780 66 Anonymous
		character="Alice"
781 66 Anonymous
		id="bml1">
782 66 Anonymous
	<head id="behavior1" lexeme="NOD" repetition="2" start="1" end="3"/>
783 66 Anonymous
</bml>
784 1 Anonymous
</code></pre>
785 1 Anonymous
_Example: Nod twice._
786 66 Anonymous
787 66 Anonymous
h3. Attribute Details @ @
788 66 Anonymous
789 66 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
790 64 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
791 1 Anonymous
|lexeme|openSetItem|required||Refers to an animation or a controller to realize this particular head behavior. Minimum set offered by all realizers: [NOD, SHAKE] |
792 64 Anonymous
|repetition| int|optional|1|Number of times the basic head motion is repeated.|
793 78 Anonymous
|amount| float|optional|1|How intense is the head nod? 0 means immeasurable small; 0.5 means "moderate"; 1 means maximally large |
794 64 Anonymous
795 64 Anonymous
|_.Sync Attribute |_.Description |
796 1 Anonymous
|start|start of the preparation phase |
797 1 Anonymous
|ready|end of the preparation phase |
798 77 Anonymous
|strokeStart |start of the stroke |
799 67 Anonymous
|stroke |stroke of the head motion. Note that the meaning of this sync point becomes undefined if @repetition > 1@ |
800 77 Anonymous
|strokeEnd |end of the stroke |
801 67 Anonymous
|relax |start of the retraction phase |
802 67 Anonymous
|end|end of the head motion |
803 67 Anonymous
804 67 Anonymous
h3. Semantics @ @
805 77 Anonymous
806 67 Anonymous
Movement of the head, recalled from a gesticon by requesting the corresponding lexeme. The stroke phase of the head motion (from @strokeStart@ till @strokeEnd@ is the "meaningful" part of the head motion. The @stroke@ sync point is the "peak" moment of the motion. If @repetition > 1@, the meaning of the @stroke@ sync point becomes undefined.
807 104 Anonymous
808 67 Anonymous
h2. <headDirectionShift>
809 104 Anonymous
810 67 Anonymous
Orient the head towards a target referenced by the target attribute.
811 1 Anonymous
812 67 Anonymous
h3. Syntax @ @
813 67 Anonymous
814 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
815 105 Anonymous
|*ELEMENT:*    |@<headDirectionShift>@ |
816 104 Anonymous
|*SYNC POINTS:* | @start@, @end@ |
817 72 Anonymous
|*ATTRIBUTES:* |@id@, @target@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
818 67 Anonymous
|*CONTENTS:*   |none |
819 67 Anonymous
820 67 Anonymous
<pre><code class="xml">
821 1 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
822 1 Anonymous
		character="Alice"
823 67 Anonymous
		id="bml1">
824 104 Anonymous
	<headDirectionShift id="behavior1" target="TARGET1" start="2"/>
825 67 Anonymous
</bml>
826 67 Anonymous
</code></pre>
827 67 Anonymous
_Example: Orient the head towards TARGET1._
828 67 Anonymous
829 67 Anonymous
h3. Attribute Details @ @
830 67 Anonymous
831 67 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
832 45 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
833 1 Anonymous
|target|targetID|required||target towards which the head is oriented|
834 45 Anonymous
835 45 Anonymous
|_.Sync Attribute |_.Description |
836 104 Anonymous
|start|beginning of headDirectionShift behavior |
837 104 Anonymous
|end|reached desired direction; set this direction as new BASE state |
838 45 Anonymous
839 45 Anonymous
h3. Semantics @ @
840 1 Anonymous
841 104 Anonymous
Permanently orient the head in a certain direction.
842 45 Anonymous
843 55 Anonymous
h1. Locomotion behavior
844 45 Anonymous
845 45 Anonymous
h2. <locomotion>
846 45 Anonymous
847 45 Anonymous
Move the body of the character from one location to another.
848 45 Anonymous
849 45 Anonymous
h3. Syntax @ @
850 1 Anonymous
851 72 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
852 1 Anonymous
|*ELEMENT:*    |@<locomotion>@ |
853 72 Anonymous
|*SYNC POINTS:* | @start@, @end@ |
854 72 Anonymous
|*ATTRIBUTES:* |@id@, @target@, @manner@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
855 45 Anonymous
|*CONTENTS:*   |none |
856 46 Anonymous
857 1 Anonymous
<pre><code class="xml">
858 1 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
859 46 Anonymous
		character="Alice"
860 1 Anonymous
		id="bml1">
861 1 Anonymous
	<locomotion id="behavior1" target="AUDIENCE" manner="WALKING"/>
862 65 Anonymous
</bml>
863 66 Anonymous
</code></pre>
864 66 Anonymous
_Example: Locomotion: walk to the audience._
865 66 Anonymous
866 61 Anonymous
h3. Attribute Details @ @
867 45 Anonymous
868 46 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
869 1 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
870 1 Anonymous
|target|targetID|required| |A reference towards a target instance that represents the end location of the locomotive behavior. |
871 36 Anonymous
|manner|openSetItem|optional|walk|The general manner of locomotion [WALK, RUN, STRAFE ...] (WALK is the only mandatory element in the set) |
872 36 Anonymous
873 1 Anonymous
|_.Sync Attribute |_.Description |
874 36 Anonymous
|start|start of the locomotion |
875 1 Anonymous
|end|end of the locomotion |
876 1 Anonymous
877 1 Anonymous
h3. Semantics @ @
878 1 Anonymous
879 1 Anonymous
This behavior causes the character to move to the requested target in the manner described. 
880 36 Anonymous
881 36 Anonymous
h1. Posture behaviors
882 1 Anonymous
883 74 Anonymous
BML allows one to specify _temporary_ postures using @<posture>@, and permanent shifts to a new BASE posture using the @<postureShift>@ behavior. Both behaviors have the same child elements to specify the form of the posture.
884 74 Anonymous
885 1 Anonymous
h2. <posture>
886 1 Anonymous
887 74 Anonymous
Temporarily change the posture of the ECA.
888 74 Anonymous
889 74 Anonymous
h3. Syntax @ @
890 74 Anonymous
891 74 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
892 74 Anonymous
|*ELEMENT:*    |@<posture>@ |
893 74 Anonymous
|*SYNC POINTS:* | @start@, @ready@, @relax@, @end@ |
894 74 Anonymous
|*ATTRIBUTES:* |@id@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
895 74 Anonymous
|*CONTENTS:*   | @<stance>@, @<pose>@ |
896 74 Anonymous
897 74 Anonymous
898 74 Anonymous
<pre><code class="xml">
899 74 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
900 74 Anonymous
		character="Alice"
901 74 Anonymous
		id="bml1">
902 101 Herwin van Welbergen
	<posture id="behavior1" start="5" end="15">			
903 74 Anonymous
    <stance type="CROUCHING"/> 
904 74 Anonymous
    <pose type="ARMS" lexeme="ARMS_OPEN"/>
905 74 Anonymous
  </posture>
906 74 Anonymous
</bml>
907 74 Anonymous
</code></pre>
908 74 Anonymous
_Example: Crouch down with open arms for a short while._
909 74 Anonymous
910 74 Anonymous
h3. Attribute Details @ @ 
911 74 Anonymous
912 74 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
913 74 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
914 74 Anonymous
915 74 Anonymous
916 74 Anonymous
|_.Sync Attribute |_.Description |
917 74 Anonymous
|start		|start moving to a new posture |
918 74 Anonymous
|ready	|new posture achieved	|
919 74 Anonymous
|relax		|start returning to BASE posture |
920 74 Anonymous
|end			|temporary posture ended, back at BASE posture |
921 74 Anonymous
922 74 Anonymous
h3. Semantics @ @
923 74 Anonymous
924 74 Anonymous
Temporarily change the posture of the ECA. After the @<posture>@ behavior has ended, return to the BASE posture.
925 74 Anonymous
926 74 Anonymous
927 1 Anonymous
h2. <postureShift>
928 1 Anonymous
929 74 Anonymous
Permanently change the BASE posture of the ECA.
930 74 Anonymous
931 74 Anonymous
h3. Syntax @ @
932 74 Anonymous
933 74 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
934 74 Anonymous
|*ELEMENT:*    |@<postureShift>@ |
935 74 Anonymous
|*SYNC POINTS:* | @start@, @end@ |
936 74 Anonymous
|*ATTRIBUTES:* |@id@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
937 74 Anonymous
|*CONTENTS:*   | @<stance>@ (max 1), @<pose>@ (any number) |
938 74 Anonymous
939 74 Anonymous
940 74 Anonymous
<pre><code class="xml">
941 74 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
942 74 Anonymous
		character="Alice"
943 74 Anonymous
		id="bml1">
944 100 Herwin van Welbergen
  <postureShift id="behavior1" start="5">			
945 74 Anonymous
    <stance type="SITTING"/> 
946 74 Anonymous
    <pose type="ARMS" lexeme="ARMS_CROSSED"/>
947 100 Herwin van Welbergen
  </postureShift>
948 74 Anonymous
</bml>
949 74 Anonymous
</code></pre>
950 74 Anonymous
_Example: Sit down with arms crossed, and make that the new BASE posture._
951 74 Anonymous
952 74 Anonymous
h3. Attribute Details @ @ 
953 74 Anonymous
954 74 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
955 74 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
956 74 Anonymous
957 74 Anonymous
958 74 Anonymous
|_.Sync Attribute |_.Description |
959 74 Anonymous
|start		|start moving to a new posture |
960 74 Anonymous
|end			|new BASE posture achieved	 |
961 74 Anonymous
962 74 Anonymous
h3. Semantics @ @
963 74 Anonymous
964 74 Anonymous
Permanently change the BASE posture of the ECA. 
965 74 Anonymous
966 74 Anonymous
h2. <stance>
967 74 Anonymous
968 74 Anonymous
Child element of @<posture>@ and @<postureShift>@ behaviors, defines global body posture of the ECA.
969 74 Anonymous
970 74 Anonymous
h3. Syntax @ @
971 74 Anonymous
972 74 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
973 74 Anonymous
|*ELEMENT:*    |@<stance>@ |
974 74 Anonymous
|*ATTRIBUTES:* |@type@[5]|
975 74 Anonymous
|*CONTENTS:*   |none |
976 74 Anonymous
977 74 Anonymous
fn5. _In the future, we plan to add a way to also specify the orientation of the posture._
978 74 Anonymous
979 74 Anonymous
h3. Attribute Details @ @
980 74 Anonymous
981 74 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
982 74 Anonymous
|type|closedSetItem|required||Global body posture. Possible values are [SITTING, CROUCHING, STANDING, LYING]|
983 74 Anonymous
984 74 Anonymous
h3. Semantics @ @
985 74 Anonymous
986 74 Anonymous
Child element of @<posture>@ and @<postureShift>@ behaviors, defines global body posture of the ECA. This global posture may then be modified by one or more @<pose>@ siblings.
987 74 Anonymous
988 74 Anonymous
h2. <pose>
989 74 Anonymous
990 74 Anonymous
Child element of @<posture>@ and @<postureShift>@ behaviors, defines additions to the global body posture of the ECA.
991 74 Anonymous
992 74 Anonymous
h3. Syntax @ @
993 74 Anonymous
994 74 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
995 74 Anonymous
|*ELEMENT:*    |@<pose>@ |
996 74 Anonymous
|*ATTRIBUTES:* |@part@, @lexeme@|
997 74 Anonymous
|*CONTENTS:*   |none |
998 74 Anonymous
999 74 Anonymous
h3. Attribute Details @ @
1000 74 Anonymous
1001 74 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
1002 74 Anonymous
|part|closedSetItem|required||What part of the body is affected? Possible values are [ARMS, LEFT_ARM, RIGHT_ARM, LEGS, LEFT_LEG, RIGHT_LEG, HEAD, WHOLEBODY]|
1003 74 Anonymous
|lexeme|openSetItem|required||What configuration is set to the given part? Some possible values are [ARMS_AKIMBO, ARMS_CROSSED, ARMS_NEUTRAL, ARMS_OPEN, LEGS_CROSSED, LEGS_NEUTRAL, LEGS_OPEN, LEANING_FORWARD, LEANING_BACKWARD, ...]|
1004 74 Anonymous
1005 74 Anonymous
h3. Semantics @ @
1006 74 Anonymous
1007 74 Anonymous
Child element of @<posture>@ and @<postureShift>@ behaviors, defines additions that modify the global body posture of the ECA. For each value of the @part@ attribute, only one @<pose>@ child is expected to be present. A BML Realizer may define any number of lexemes beyond the ones specified above.
1008 74 Anonymous
1009 1 Anonymous
h1. Speech behaviors
1010 64 Anonymous
1011 1 Anonymous
h2. <speech>
1012 1 Anonymous
1013 1 Anonymous
Utterance to be spoken by a character. 
1014 1 Anonymous
1015 1 Anonymous
h3. Syntax @ @
1016 72 Anonymous
1017 1 Anonymous
|*NAMESPACE:*  |http://www.bml-initiative.org/bml/bml-1.0 |
1018 72 Anonymous
|*ELEMENT:*    |@<speech>@ |
1019 72 Anonymous
|*SYNC POINTS:* | @start@, @end@, any @<sync>@ element in the speech (see below) |
1020 42 Anonymous
|*ATTRIBUTES:* |@id@, [[Wiki#Default-Sync-Points-and-their-Sync-Attributes| sync attributes]] |
1021 42 Anonymous
|*CONTENTS:*   |exactly one @<text>@ child containing the text to be spoken, which in turn may contain one or more @<sync>@ markers. |
1022 42 Anonymous
| | A @<sync>@ marker has an attribute @id@ of type ID, the value of which is unique within the context of this @<speech>@ element. |
1023 42 Anonymous
1024 42 Anonymous
1025 46 Anonymous
<pre><code class="xml">
1026 60 Anonymous
<bml xmlns="http://www.bml-initiative.org/bml/bml-1.0"
1027 46 Anonymous
		character="Alice"
1028 1 Anonymous
		id="bml1">
1029 1 Anonymous
	<speech id="speech1" start="6"><text>This is a complete <sync id="syncstart1" /> 
1030 46 Anonymous
	BML core speech description.</text></speech>		
1031 65 Anonymous
</bml>
1032 66 Anonymous
</code></pre>
1033 66 Anonymous
_Example: This is an example of a complete speech behavior, synchronized to a beat gesture (striking on "speech")._
1034 66 Anonymous
1035 42 Anonymous
h3. Attribute Details @ @
1036 61 Anonymous
1037 71 Anonymous
|_.Attribute |_.Type |_.Use |_.Default |_.Description |
1038 71 Anonymous
|id |ID |required | |Unique ID that allows referencing to a particular @<bml>@ behavior. The id 'bml' is reserved. |
1039 71 Anonymous
1040 71 Anonymous
|_.Sync Attribute |_.Description |
1041 31 Anonymous
|start|start of the speech |
1042 31 Anonymous
|end|end of the speech |
1043 1 Anonymous
1044 1 Anonymous
h3. Semantics @ @
1045 1 Anonymous
1046 1 Anonymous
Realization of the @<speech>@ element generates both speech audio (or text) and speech movement, for example using a speech synthesizer and viseme morphing.
1047 1 Anonymous
The @<speech>@ element requires a sub-element. This sub-element is a @<text>@ element that contains the text to be spoken, with optionally embedded @<sync>@ elements for alignment with other behaviors. 
1048 1 Anonymous
1049 1 Anonymous
h2. SSML Core Description Extension
1050 74 Anonymous
1051 76 Anonymous
The SSML description extension is of type "application/ssml+xml". Its namespace is "http://www.w3.org/2001/10/synthesis".
1052 74 Anonymous
1053 74 Anonymous
The format of the content of this extension is defined at http://www.w3.org/TR/speech-synthesis/
1054 74 Anonymous
1055 74 Anonymous
<pre><code language="xml">
1056 74 Anonymous
  <speech id="s1">
1057 74 Anonymous
     <text>Hello! This is a basic SSML <sync id="bml"/>BML test.</text>
1058 74 Anonymous
    <description priority="2" type="application/ssml+xml">
1059 74 Anonymous
      <speak xmlns="http://www.w3.org/2001/10/synthesis">        
1060 74 Anonymous
        Hello! <break time="3s"/> <prosody pitch="high">This is a basic SSML <mark name="bml"/>BML test</prosody>.
1061 74 Anonymous
      </speak>
1062 1 Anonymous
    </description>
1063 74 Anonymous
  </speech>
1064 74 Anonymous
</code></pre>
1065 74 Anonymous
_Example: Using the SSML Description extension for speech_
1066 1 Anonymous
1067 1 Anonymous
h2. MaryXML Core Description Extension
1068 74 Anonymous
1069 76 Anonymous
The MaryXML description extension is of type "maryxml". Its namespace is "http://mary.dfki.de/2002/MaryXML". It allows one to specify more detail for the TTS engine, if one uses [[http://mary.dfki.de MaryTTS]] for speech generation.
1070 74 Anonymous
1071 74 Anonymous
The format of the content of this extension is defined at http://mary.dfki.de/documentation/maryxml
1072 74 Anonymous
1073 74 Anonymous
<pre><code language="xml">
1074 74 Anonymous
  <speech id="s1">
1075 74 Anonymous
     <text>Hello! This is a basic Mary <sync id="bml"/>BML test.</text>
1076 74 Anonymous
    <description priority="2" type="maryxml">
1077 74 Anonymous
      <maryxml xmlns="http://mary.dfki.de/2002/MaryXML">
1078 74 Anonymous
        Hello! This is a basic Mary <mark name="bml"/>BML test.
1079 74 Anonymous
      </maryxml>    
1080 74 Anonymous
    </description>
1081 74 Anonymous
  </speech>
1082 74 Anonymous
</code></pre>
1083 74 Anonymous
_Example: Using the MaryXML Description extension for speech. Only works when one uses MaryTTS for speech generation._
1084 32 Anonymous
1085 41 Anonymous
h1. Description levels and other extension mechanisms 
1086 32 Anonymous
1087 32 Anonymous
The core BML behavior elements are by no means comprehensive, and much of the ongoing work behind BML involves identifying and defining a broad and flexible library of behavior (types). Implementors are encouraged to explore new behavior elements and more detailed ways to specify existing core behaviors. BML allows such extensions in several ways:
1088 32 Anonymous
1089 32 Anonymous
* Additional behaviors should be designed as new XML elements using custom XML namespaces.
1090 32 Anonymous
* Specialized attributes can be used to extend core BML behaviors. Such attributes should be identified as non-standard BML by utilizing XML namespaces.
1091 32 Anonymous
* Behavior Description Extensions provide a principled way of specifying core BML behaviors in a more detailed manner, typically using existing XML languages for that specific behavior.
1092 1 Anonymous
1093 32 Anonymous
!Extension.png!
1094 32 Anonymous
_Figure 5: Extending BML_
1095 32 Anonymous
1096 32 Anonymous
The following example utilizes a customized @animation@ behavior and a customized @joint-speeds@ attribute. The latter specifies the core gaze behavior in a more detailed manner. Both extensions are from the SmartBody project.
1097 32 Anonymous
1098 32 Anonymous
<pre><code language="xml">
1099 32 Anonymous
  <bml xmlns="http://www.bml-initiative.org/bml/bml-1.0" xmlns:sbm="http://www.smartbody-anim.org/sbm">
1100 32 Anonymous
     <gaze id="gaze1"  target="AUDIENCE" sbm:joint-speeds="100 100 100 300 600"/>
1101 32 Anonymous
     <sbm:animation name="CrossedArms_RArm_beat"/>   
1102 32 Anonymous
  </bml>
1103 32 Anonymous
</code></pre>
1104 32 Anonymous
_Example: Using extensions_
1105 32 Anonymous
1106 32 Anonymous
If a realizer cannot interpret extended BML, it should deal with it in the way suggested in the Section [[Wiki#Failure-and-Fallback|Failure and Fallback]].
1107 32 Anonymous
1108 32 Anonymous
h2. Behavior Description Extensions
1109 32 Anonymous
1110 1 Anonymous
BML allows for additional behavior descriptions that go beyond the core BML behavior specification in describing the form of a behavior. Additional descriptions are embedded within a behavior element as children elements of the type description. The type attribute of the description element should identify the type of content, indicating how it should be interpreted. Even if additional descriptions are included in a behavior, the core attributes of the behavior element itself cannot be omitted since the core specification is always the default fall-back.
1111 32 Anonymous
1112 32 Anonymous
Description elements in BML can include existing representation languages such as SSML, Tobi, etc. or new languages can be created that make use of advanced realization capabilities. Each description element should be a self-contained description of a behavior because a behavior realizer may not know how to combine multiple behavior descriptions. It is required that each description provides exactly the same synchronization points as its accompanying core BML. It is however allowed to place the synchronization points in the description level at slightly different positions than those in the core BML. This can be used to, for example, to provide synchronization at syllable level rather than a word level in a description extension of a speech behavior.
1113 64 Anonymous
1114 32 Anonymous
If a realizer does not known how to interpret the available description types, it should default to the core behavior.
1115 32 Anonymous
1116 32 Anonymous
If multiple description elements are given, and a realizer is capable of interpreting more than one, the realizer should use the highest priority description.
1117 32 Anonymous
1118 72 Anonymous
Example: use an audio file to play back this speech behavior. If that's not supported, use SSML. As a last resort, fall back to the core behavior. Note that the descriptions specify the same sync points as the core behavior.
1119 32 Anonymous
1120 32 Anonymous
<pre><code language="xml">
1121 32 Anonymous
  <speech id="s1">
1122 32 Anonymous
     <text>This is the proposed BML <sync id="tm1"/> extended speech specification.</text>
1123 32 Anonymous
     <description priority="1" type="application/ssml+xml">
1124 32 Anonymous
        <ssml:speak xmlns:ssml="http://www.w3.org/2001/10/synthesis">
1125 32 Anonymous
        This is the <ssml:emphasis>proposed</ssml:emphasis>  BML  <ssml:mark name=”tm1”/> extended speech specification.
1126 32 Anonymous
        </ssml:speak>
1127 1 Anonymous
     </description>
1128 32 Anonymous
     <description priority="3" type="audio/x-wav">
1129 32 Anonymous
        <audio:sound xmlns:audio="http://www.ouraudiodesc.com/">
1130 1 Anonymous
          <audio:file ref="bml.wav"/>
1131 72 Anonymous
          <audio:sync id="tm1" time="2.3" />
1132 32 Anonymous
        </audio:sound>
1133 32 Anonymous
     </description>
1134 32 Anonymous
  </speech>
1135 1 Anonymous
</code></pre>
1136 32 Anonymous
_Example: Using description extensions for speech_
1137 32 Anonymous
1138 32 Anonymous
1139 32 Anonymous
<pre><code language="xml">
1140 64 Anonymous
  <speech id="s1">
1141 32 Anonymous
     <text>This is the proposed BML <sync id="tm1"/> extended speech specification.</text>
1142 1 Anonymous
     <description priority="1" type="application/ssml+xml">
1143 1 Anonymous
        <speak xmlns="http://www.w3.org/2001/10/synthesis">
1144 32 Anonymous
        This is the <emphasis>proposed</emphasis>  BML  <mark name=”tm1”/> extended speech specification.
1145 1 Anonymous
        </speak>
1146 32 Anonymous
     </description>
1147 32 Anonymous
     <description priority="3" type="audio/x-wav">
1148 32 Anonymous
        <sound xmlns="http://www.ouraudiodesc.com/">
1149 33 Anonymous
          <file ref="bml.wav"/>
1150 33 Anonymous
          <sync id="tm1" time="2.3" />
1151 64 Anonymous
        </sound>
1152 33 Anonymous
     </description>
1153 1 Anonymous
  </speech>
1154 33 Anonymous
</code></pre>
1155 33 Anonymous
_Example: A slightly less verbose example of the same behavior, using default namespaces for audio and SSML._
1156 33 Anonymous
1157 33 Anonymous
h1. Failure and Fallback
1158 33 Anonymous
1159 39 Anonymous
When a realizer is unable to interpret or execute part of a @<bml>@ block, it should deal with it in the following ways.
1160 64 Anonymous
1161 68 Anonymous
*  if unable to execute @<required>@ block: drop complete @<bml>@ block; send warning feedback
1162 68 Anonymous
*  if unable to execute a behavior child: drop behavior, send warning feedback
1163 68 Anonymous
*  if unable to adhere to a constraint specified in an attribute in a behavior child: drop behavior, send warning feedback
1164 85 Herwin van Welbergen
*  if unable to *interpret* a description extension: fallback to lower priority description extension, or to core behavior
1165 68 Anonymous
*  if unable to *interpret* extended behaviors: drop behavior, send warning feedback
1166 68 Anonymous
*  if unable to *interpret* extended attributes: drop attribute, send warning feedback
1167 1 Anonymous
1168 1 Anonymous
h1. Feedback
1169 1 Anonymous
1170 79 Anonymous
A BML realizer should provide a behavior planner with various types of feedback. Progress feedback gives information on the execution status of ongoing behaviors. Prediction feedback provides the "scheduling solution" of behaviors, such as the expected timing of sync points. Warning feedback indicates that the execution or scheduling of some behavior(s) failed, or that some time constraints could not be achieved.
1171 79 Anonymous
1172 79 Anonymous
h2.  Prediction feedback  
1173 81 Anonymous
1174 79 Anonymous
Prediction feedback provides information about the expected realization of the @<bml>@ request. It consists of block prediction, and behavior prediction feedback. Block prediction feedback contains information on the global start and end time of a block. Behavior prediction feedback contains information on the local timing of all sync points of the behavior. 
1175 79 Anonymous
1176 79 Anonymous
Prediction feedback may be revised -- later feedback counts as a 'revision' overriding all previous prediction feedback concerning the same @<bml>@ block or the same behavior element.
1177 79 Anonymous
1178 79 Anonymous
    |*What:*         |Prediction feedback. |
1179 79 Anonymous
    |*Status:*        |Optional. |
1180 79 Anonymous
    |*XML namespace:* |http://www.bml-initiative.org/bml/bml-1.0 |
1181 79 Anonymous
1182 79 Anonymous
h3. Syntax @ @
1183 79 Anonymous
1184 79 Anonymous
The syntax is similar to that of the BML blocks. The prediction feedback is wrapped into a @<predictionFeedback>@ element, which has an optional @characterId@ attribute indicating the ID of the character.
1185 79 Anonymous
1186 79 Anonymous
<pre><code language="xml">
1187 83 Herwin van Welbergen
<predictionFeedback characterId="doctor"  (optional attribute)>
1188 79 Anonymous
  <bml id="bml1" globalStart="1" globalEnd="30"/>
1189 83 Herwin van Welbergen
</predictionFeedback>
1190 79 Anonymous
</code></pre>
1191 79 Anonymous
_Example: Block solution example_
1192 79 Anonymous
1193 79 Anonymous
<pre><code language="xml">
1194 83 Herwin van Welbergen
<predictionFeedback>
1195 114 Herwin van Welbergen
  <gesture id="bml1:gesture1" lexeme="BEAT" start="0" ready="1" strokeStart="3" stroke="4" strokeEnd="5" relax="6" end="7"/>
1196 83 Herwin van Welbergen
</predictionFeedback>
1197 79 Anonymous
</code></pre>
1198 79 Anonymous
_Example: Behavior solution example_
1199 79 Anonymous
1200 79 Anonymous
<pre><code language="xml">
1201 83 Herwin van Welbergen
<predictionFeedback>
1202 88 Herwin van Welbergen
 <speech start="0" ready="0" strokeStart="0" stroke="4" strokeEnd="4" relax="4" end="4" id="bml1:speech1">
1203 79 Anonymous
   <text>Hello <sync id="s1" time="2"/> world</text>
1204 79 Anonymous
 </speech>
1205 83 Herwin van Welbergen
</predictionFeedback>
1206 79 Anonymous
</code></pre>
1207 79 Anonymous
_Example: Solution for speech, internal syncs are resolved by a time attribute in the sync tag._
1208 79 Anonymous
1209 79 Anonymous
<pre><code language="xml">
1210 83 Herwin van Welbergen
<predictionFeedback>
1211 88 Herwin van Welbergen
  <gesture id="bml1:gesture1" type="LEXICALIZED" lexeme="CUSTOM_LEXEME" start="0" ready="0" strokeStart="0" stroke="4" strokeEnd="4" relax="4" end="4">
1212 79 Anonymous
    <sync id="customsync1" time="3"/>
1213 79 Anonymous
  </gesture>
1214 83 Herwin van Welbergen
</predictionFeedback>
1215 79 Anonymous
</code></pre>
1216 79 Anonymous
_Example: Solution for a behavior with a custom sync point. The solution for the custom sync point is provided in an embedded the sync tag._
1217 79 Anonymous
1218 79 Anonymous
<pre><code language="xml">
1219 83 Herwin van Welbergen
<predictionFeedback>
1220 79 Anonymous
  <bml id="bml1" globalStart="1" globalEnd="7"/>
1221 114 Herwin van Welbergen
  <gesture id="bml1:gesture1" lexeme="BEAT" start="0" ready="1" strokeStart="3" stroke="4" strokeEnd="5" relax="6" end="7"/>
1222 114 Herwin van Welbergen
  <head id="bml1:head1" lexeme="NOD" start="0" ready="1" strokeStart="3" stroke="4" strokeEnd="5" relax="6" end="7"/>
1223 83 Herwin van Welbergen
</predictionFeedback>
1224 79 Anonymous
</code></pre>
1225 79 Anonymous
_Example: A solution feedback may contain multiple behaviors or blocks._
1226 79 Anonymous
1227 106 Herwin van Welbergen
h4. Shape feedback
1228 108 Herwin van Welbergen
1229 106 Herwin van Welbergen
The behaviors elements within a prediction feedback may be used to provide the behavior planner with information on the shape of a to be executed behavior. 
1230 106 Herwin van Welbergen
For example, the BML block:
1231 106 Herwin van Welbergen
<pre><code language="xml">
1232 106 Herwin van Welbergen
<bml id=“bml1”>
1233 106 Herwin van Welbergen
 <gesture id=“b1” lexeme=“beat”/>
1234 106 Herwin van Welbergen
</bml>
1235 106 Herwin van Welbergen
</code></pre>
1236 106 Herwin van Welbergen
may result in feedback of the form:
1237 106 Herwin van Welbergen
<pre><code language="xml">
1238 113 Herwin van Welbergen
<predictionFeedback>
1239 124 Herwin van Welbergen
   <gesture id=“b1” lexeme=“beat” mode=“RIGHT_HAND”
1240 106 Herwin van Welbergen
         start=“0” ready=“1”  
1241 107 Herwin van Welbergen
         strokeStart=“1” strokeEnd=“2” 
1242 106 Herwin van Welbergen
         relax=“2” end=“3”/>
1243 113 Herwin van Welbergen
</predictionFeedback>
1244 106 Herwin van Welbergen
</code></pre>
1245 106 Herwin van Welbergen
In addition to informing the behavior planner on the timing of gesture b1, this feedback message also informs the behavior planner that the realizer chose to execute the beat gesture with the right hand. When desired, description levels can be employed to provide very detailed shape information.
1246 106 Herwin van Welbergen
1247 79 Anonymous
h3. Semantics @ @
1248 79 Anonymous
1249 79 Anonymous
h4. Multiple revisions @ @
1250 79 Anonymous
1251 79 Anonymous
Prediction feedback may be revised -- later feedback counts as a 'revision' overriding all previous prediction feedback concerning the same @<bml>@ block or the same behavior element. As such, the feedback can be used as (potentially continually updated) predictions of the timing of behaviors. 
1252 79 Anonymous
1253 79 Anonymous
h4. Maximum information @ @
1254 79 Anonymous
1255 79 Anonymous
The BML Realizer must send information about all sync points that it does know about. If it does not know, it will leave out the sync point from the returned BML expression. 
1256 79 Anonymous
      
1257 79 Anonymous
h2. Progress feedback  
1258 79 Anonymous
1259 110 Herwin van Welbergen
Provides real-time information on the progress of ongoing behavior. Consists of progress feedback on the bml block and individual sync point level.
1260 79 Anonymous
1261 79 Anonymous
    |*What:*         |Progress feedback. |
1262 79 Anonymous
    |*Status:*        |Mandatory. |
1263 79 Anonymous
    |*XML namespace:* |http://www.bml-initiative.org/bml/bml-1.0 |
1264 79 Anonymous
1265 110 Herwin van Welbergen
h3. <blockProgress> 
1266 79 Anonymous
1267 79 Anonymous
Block start block start contains the following attributes:
1268 110 Herwin van Welbergen
| id | ID | required | | id of the bml block synchronization to which the feedback belongs |
1269 110 Herwin van Welbergen
|globalTime | float | required | | global time stamp |
1270 79 Anonymous
|characterId | ID | optional | | ID of the character to which the feedback belongs |
1271 79 Anonymous
1272 1 Anonymous
<pre><code language="xml">
1273 113 Herwin van Welbergen
<blockProgress id="bml1:start" globalTime="10" characterId="doctor"/>
1274 79 Anonymous
</code></pre>
1275 111 Herwin van Welbergen
_Example: block start feedback_
1276 79 Anonymous
1277 79 Anonymous
<pre><code language="xml">
1278 113 Herwin van Welbergen
<blockProgress id="bml1:end" globalTime="15" characterId="doctor"/>
1279 79 Anonymous
</code></pre>
1280 111 Herwin van Welbergen
_Example: block end feedback_
1281 79 Anonymous
1282 110 Herwin van Welbergen
BML compliant realizers should provide progress feedback for at least the start and end of the BML block (the format for this is shown in the examples above). 
1283 110 Herwin van Welbergen
Optionally, realizers might provide feedback on other time events of a BML block. For example: a realizer might indicate that it is subsiding (all behavior in the block is either ended or in a relax phase) in the following manner:
1284 110 Herwin van Welbergen
<pre><code language="xml">
1285 110 Herwin van Welbergen
<blockProgress id="bml1:relax" globalTime="14" characterId="doctor"/>
1286 110 Herwin van Welbergen
</code></pre>
1287 79 Anonymous
1288 79 Anonymous
h3. <syncPointProgress>
1289 79 Anonymous
1290 79 Anonymous
Sync point progress feedback contains the following attributes:
1291 79 Anonymous
| id | ID | required | | full id of the sync point to which the feedback belongs |
1292 79 Anonymous
|globalTime | float | required | | global time stamp of when the sync point happened |
1293 79 Anonymous
|time | float | required | | local time stamp of when the sync point happened, relative to the block start of the corresponding @<bml>@ block |
1294 79 Anonymous
|characterId | ID | optional | | ID of the character to which the feedback belongs |
1295 79 Anonymous
1296 79 Anonymous
<pre><code language="xml">
1297 79 Anonymous
<syncPointProgress id="bml1:gesture1:stroke" time="10" globalTime="1111"/>
1298 79 Anonymous
</code></pre>
1299 112 Herwin van Welbergen
_Example: sync point progress feedback_
1300 79 Anonymous
1301 79 Anonymous
h3. The order of progress feedback 
1302 79 Anonymous
1303 79 Anonymous
Some order constraints are enforced upon the sending of progress feedback:
1304 79 Anonymous
1305 79 Anonymous
* The block start feedback of a bml block should occur before all sync point progress feedback messages of all behaviors in the block.
1306 79 Anonymous
* The block end feedback of a bml block should occur after all sync point progress feedback messages of all behaviors in the block.
1307 79 Anonymous
* The sync point progress feedback of behaviors should arrive in the default order. For example, if a @start@ and @ready@ sync of a behavior occur at the same time, the sync point progress feedback of the @start@ sync should still be sent before that of the @ready@ sync.
1308 68 Anonymous
1309 80 Anonymous
h2. Warning feedback 
1310 80 Anonymous
1311 80 Anonymous
Warning feedback notifies the behavior planner that requested behaviors and/or constraints have failed to realize, and possibly led to aborting the performance.
1312 80 Anonymous
1313 80 Anonymous
It contains the following information:
1314 80 Anonymous
* bml id
1315 80 Anonymous
* warning type [BML parsing failure, no such gaze/walk/point target, impossible to schedule, realizer does not support behavior type x, realizer cannot construct behavior type x, ...]
1316 80 Anonymous
* whether the block was interrupted as a whole or the id of the behavior that failed
1317 80 Anonymous
* optional: a human-readable description of the error
1318 80 Anonymous
* optional: character id
1319 80 Anonymous
1320 80 Anonymous
1321 80 Anonymous
<pre><code language="xml">
1322 80 Anonymous
  <warningFeedback id="bml1" characterId="armandia" type="PARSING_FAILURE">
1323 80 Anonymous
      Cannot parse BML block
1324 80 Anonymous
  </warningFeedback>
1325 80 Anonymous
</code></pre>
1326 80 Anonymous
_Example: bml1 fails as a whole_
1327 80 Anonymous
1328 80 Anonymous
1329 80 Anonymous
<pre><code language="xml">
1330 80 Anonymous
  <warningFeedback id="bml1:gaze1" characterId="armandia" type="NO_SUCH_TARGET">
1331 80 Anonymous
      "doctor" is not a valid gaze target.
1332 80 Anonymous
  </warningFeedback>
1333 80 Anonymous
</code></pre>
1334 80 Anonymous
_Example: behavior gaze1 in bml1 fails_
1335 80 Anonymous
1336 103 Anonymous
The content of the warningFeedback element is left open. In the examples we show how human readable error messages could be embedded in warning feedback. Alternatively, realizers could embed a custom XML element that describes the warning in more detail.  
1337 103 Anonymous
1338 103 Anonymous
This is the list of feedback types in BML 1.0:
1339 103 Anonymous
* PARSING_FAILURE: there is an error in the syntax of the BML block
1340 103 Anonymous
* NO_SUCH_TARGET: locomotion/gaze/.. target does not exist in the world
1341 103 Anonymous
* IMPOSSIBLE_TO_SCHEDULE: the BML block contains conflicting constraints(e.g. @beh1:start=beh1:end+1@)
1342 103 Anonymous
* BEHAVIOR_TYPE_NOT_SUPPORTED: the realizer does not support a core behavior type requested in the BML block (e.g. when a realizer steer a head only avatar is asked to do a locomotion behavior)
1343 103 Anonymous
* CUSTOM_BEHAVIOR_NOT_SUPPORTED: the realizer does not support a custom (non core) behavior
1344 103 Anonymous
* CUSTOM_ATTRIBUTE_NOT_SUPPORTED: the realizer does not support a custom attribute specified on a core behavior
1345 103 Anonymous
* CANNOT_CREATE_BEHAVIOR: the realizer cannot construct a behavior (given specified time constraints and shape attributes)
1346 80 Anonymous
1347 69 Anonymous
h1. -------------------------------------------------
1348 1 Anonymous
1349 1 Anonymous
h1. Contributors
1350 1 Anonymous
1351 1 Anonymous
Over the years, a large number of people have contributed to the papers, workshops and developer meetings leading to this standard. Below, you find an (incomplete[4]) list of names. 
1352 1 Anonymous
1353 1 Anonymous
Aleksandra Cerekovic, Alex Hill, Alexis Heloir, Andrew Marshall, Ari Shapiro, Brigitte Krenn, Catherine Pelachaud, Dan Loehr, Dennis Reidsma, Hannes Högni Vilhjálmsson, Hannes Pirker, Herwin van Welbergen, James Gruber, Job Zwiers, John Borland, Jon Homer, Justine Cassell, Kristinn R. Thórisson, Marco Vala, Maurizio Mancini, Michael Kipp, Michael Krieger, Michael Neff, Michael Wißner, N. Cantelmo, N.E. Chafai, Nicolas Schulz, Paul Tepper, Prasan Samtani, Quoc Anh Le, Radek Niewiadomski, Rick van der Werf, Stacy Marsella, Stefan Kopp, Tim Bickmore, W. Lewis Johnson, Zsofia Ruttkay
1354 1 Anonymous
1355 1 Anonymous
fn4. _Feel free to suggest missing names._