Copyright © 2012 W3C ® (MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use rules apply.
The Multimodal Architecture and Interfaces Specification entered the Candidate Recommendation period on 12 January 2012.
Preparation of an Implementation Report is a key criterion for moving beyond the Candidate Recommendation phase. This document describes the requirements for the Implementation Report and the process that the Multimodal Working Group will follow in preparing the report.
During the CR period, the Working Group will carry out the following activities:
You are invited to contribute to the assessment of the W3C Multimodal Architecture and Interfaces 1.0 Specification by participating in the Implementation Report process.
The Multimodal Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:
pass
", "fail
" or
"not-impl
". "not-impl
" means the
Multimodal Architecture constituent has not implemented the specific feature required
by a test.The Multimodal Architecture Implementation Report will not cover:
Note: The testimonials with pink background from "Acme Labs" and "Beta Inc." are just examples and will be replaced with the actually submitted testimonials.
The W3C Multimodal Architecture 1.0 Specification is well-written, easily implementable and extremely useful. Acme Labs used it to describe the recipe for haggis.
The W3C Multimodal Architecture 1.0 Specification is the best thing since sliced bread, extremely useful, easily implementable and well-written. Beta Inc. used it to build a new generation of interactive services, establish world peace, build a new chianti-spaghetti hybrid vehicle, and mix a perfect martini.
The aim of this section is to describe the range of test assertions developed for the Multimodal Architecture 1.0 Specification. The table lists all the assertions that were derived from the Multimodal Architecture 1.0 Specification.
The Assert ID column uniquely identifies the assertion. The Feature column indicates the specific elements or attributes which the test assertion applies to. The Spec column identifies the section of the Multimodal Architecture Specification from which the assertion was derived. The Semantics column specifies the semantics of the feature or the constraint which must be met. The Result column will be annotated with the number of 'pass', 'fail', and 'not implemented' (P/F/NI) in the set of implementation reports.
A conforming Multimodal Architecture implementation which uses XML to represent MMI Lifecycle Events must utilize documents that successfully validate with respect to the MMI Lifecycle Event XML Schema.
Spec | Assert ID | Feature | Semantics | Results | ||
---|---|---|---|---|---|---|
P | F | NI | ||||
5.2.1 | 144 | The Interaction Manager | All events that the Modality Components generate MUST be delivered to the Interaction Manager. | |||
5.2.1 | 145 | All events that are delivered to Modality Components MUST be sent by the Interaction Manager | ||||
5.2.1 | 87 | A modality component may contain its own interaction manager. | ||||
5.2.4.1 | 118 | The Event Transport Layer | The event delivery mechanism MUST guarantee that events delivered from the same source are delivered in that order. | |||
5.2.4.1 | 211 | The event delivery mechanism MUST report an error if an event can not be delivered. | ||||
6 | 89 | Modality Components communicate with the Interaction manager via events. | ||||
6 | 90 | Modality Components communicate with the Interaction manager via asynchronous events. | ||||
6 | 91 | Constituents must be able to send events. | ||||
6 | 92 | Constituents must be able to handle events that are delivered to them asynchronously. | ||||
6.1 | 32 | All lifecycle events must use a common basic concept of 'context'. | ||||
6.1 | 33 | A context must represent a single extended interaction with zero or more users across one or more modality components. | ||||
6.1 | 34 | A context should cover the longest period of interaction over which it would make sense for components to store information. | ||||
6.1.1 | 35 | Context | The Context attribute must be a URI that is unique for the lifetime of the system. | |||
6.1.1 | 36 | All events relating to a given interaction must use the same context URI. | ||||
6.1.1 | 146 | Any two events that use different context URIs must be interpreted as parts of unrelated interactions. | ||||
6.1.2 | 37 | Source | The Source attribute must be a URI representing the address of the sender of the event. | |||
6.1.3 | 38 | Target | The Target attribute must be a URI representing the address of the destination of the event. | |||
6.1.4 | 39 | RequestID | The RequestID attribute must be an identifier that is unique within the given context for each Request/Response pair. | |||
6.1.4 | 40 | For any Request/Response event pair, the RequestID in the Response event must match the RequestID specified in the Request event. | ||||
6.1.5 | 41 | Status | The Status attribute must be either 'success' or 'failure'. | |||
6.1.5 | 42 | The Response event of a Request/Response pair must use the Status field to report whether it succeeded in carrying out the request. | ||||
6.1.6 | 43 | StatusInfo | The Response event of a Request/Response pair MAY use the StatusInfo field to provide additional status information. | |||
6.1.6 | 208 | All constituents MUST be able to process Life-Cycle events that use the StatusInfo field to provide additional status information. | ||||
6.1.7 | 44 | Data | Any event MAY may use the Data field to contain arbitrary data. | |||
6.1.7 | 209 | All constituents MUST be able to process Life-Cycle events that use the Data field to provide arbitrary data. | ||||
6.1.8 | 147 | Confidential | Any event MAY use the Confidential field to indicate whether the contents of this event are confidential. | |||
6.1.8 | 148 | The default value of the Confidential field must be 'false' | ||||
6.1.8 | 149 | If the value of Confidential is 'true', the Interaction Manager and Modality Component implementations MUST not log the information or make it available in any way to third parties unless explicitly instructed to do so by the author of the application. | ||||
6.2.1 | 95 | NewContext | A modality component MAY send a NewContextRequest event to the interaction manager to request that a new context be created. | |||
6.2.1 | 151 | The IM MAY create a new context without a previous NewContextRequest by sending a PrepareRequest containing a new context ID to the Modality Components. | ||||
6.2.1 | 152 | The IM MAY create a new context without a previous NewContextRequest by sending a StartRequest containing a new context ID to the Modality Components. | ||||
6.2.2 | 154 | Prepare | The IM MAY send a PrepareRequest to allow the Modality Components to pre-load markup and prepare to run. | |||
6.2.2 | 157 | The Interaction Manager MAY send multiple PrepareRequest events to a Modality Component for the same Context before sending a StartRequest. | ||||
6.2.2 | 158 | Each PrepareRequest the IM sends to a Modality Component MAY reference a different ContentURL or contain different in-line Content. | ||||
6.2.2.1 | 160 | The IM MAY use the same context value in successive PrepareRequest events when it wishes to execute multiple instances of markup in the same context. | ||||
6.2.2.1 | 161 | The PrepareRequest event MAY contain a ContentURL field with the URL of the content that the Modality Component SHOULD prepare to execute. | ||||
6.2.2.1 | 162 | The PrepareRequest event MAY contain a Content field with inline markup that the Modality Component SHOULD prepare to execute. | ||||
6.2.2.1 | 164 | The IM MAY leave both contentURL and content fields of a PrepareRequest event empty. | ||||
6.2.3 | 168 | The IM MAY include a value in the ContentURL or Content field of the StartRequest event. | ||||
6.2.3.1 | 171 | The IM MAY use the same context value in multiple StartRequest events when it wishes to execute multiple instances of markup in the same context. | ||||
6.2.3.1 | 172 | The StartRequest event MAY contain a ContentURL field with the URL of the content that the Modality Component MUST attempt to execute | ||||
6.2.3.1 | 173 | The StartRequest event MAY contain a Content field with inline markup that the Modality Component MUST attempt to execute. | ||||
6.2.3.1 | 175 | The IM MAY leave both contentURL and content fields of a StartRequest event empty. | ||||
6.2.5.1 | 17 | The IM MAY send a CancelRequest to stop processing in the Modality Component. | ||||
6.2.6.1 | 31 | The IM MAY send a PauseRequest to suspend processing by the Modality Component. | ||||
6.2.7 | 1 | Resume | The IM MAY send the ResumeRequest to resume processing that was paused by a previous PauseRequest. | |||
6.2.8 | 61 | ExtensionNotification | The ExtensionNotification event MAY be generated by the IM to encapsulate application-specific events. | |||
6.2.8 | 188 | The ExtensionNotification event MAY be generated by the Modality Component to encapsulate application-specific events. | ||||
6.2.8 | 210 | All constituents MUST be able to process ExtensionNotification events. | ||||
6.2.10 | 74 | Status | The IM MAY send a StatusRequest event to a MC to inquire about the status of a specific user interaction (context) or the status of the MC itself. | |||
6.2.10 | 79 | The recipient of a StatusRequest event MUST respond with a StatusResponse event. | ||||
6.2.10 | 190 | A MC MAY send a StatusRequest event to the IM to inquire about the status of a specific user interaction (context) or the status of the IM itself. | ||||
6.2.10.1 | 75 | The sender of a StartRequest event MAY use the Context field to specify the context for which the status is requested. | ||||
6.2.10.1 | 78 | The StatusRequest event MUST contain a RequestAutomaticUpdate field which is a boolean value. | ||||
6.2.10.1 | 191 | If the Context field is present in a StatusRequest message, the recipient MUST respond with a StatusResponse message indicating the status of the specified context. | ||||
6.2.10.1 | 192 | If the Context field is not present in a StatusRequest message, the recipient MUST send a StatusResponse message indicating the status of the underlying server. | ||||
6.2.10.1 | 195 | If the RequestAutomaticUpdate field of a StatusRequest message is 'true', the recipient SHOULD send periodic StatusResponse messages without waiting for an additional StatusRequest message. | ||||
6.2.10.1 | 196 | If the RequestAutomaticUpdate field of a StatusRequest message is 'false', the recipient SHOULD send one and only one StatusResponse message in response to this request. | ||||
6.2.10.2 | 81 | The sender of a StartResponse event MAY use the Context field to specify the context for which the status is being returned. | ||||
6.2.10.2 | 194 | The StatusResponse event MUST contain an AutomaticUpdate field which is a boolean value. | ||||
6.2.10.2 | 198 | If the AutomaticUpdate field of a StatusResponse message is 'true', the sender MUST keep sending StatusResponse messages in the future without waiting for another StatusRequest message. | ||||
6.2.10.2 | 199 | If the AutomaticUpdate field of a StatusResponse message is 'false', the sender MUST wait for a subsequent StatusRequest message before sending another StatusResponse message. | ||||
6.2.10.2 | 200 | If the Context field is present in a StatusResponse event, the response MUST represent the status of the specified context. | ||||
6.2.10.2 | 201 | If the Context field is not present in a StatusResponse event, the response MUST represent the status of the underlying server. | ||||
6.2.10.2 | 202 | The Status field of a StatusResponse message is an enumeration of 'Alive' or 'Dead'. | ||||
6.2.10.2 | 203 | If the StatusResponse message specifies a context which is still active and capable of handling new life cycle events, the sender MUST set the Status field to 'Alive' | ||||
6.2.10.2 | 204 | If the StatusResponse message specifies a context which has terminated or is otherwise unable to process new life cycle events, the sender MUST set the Status to 'Dead'. | ||||
6.2.10.2 | 205 | If the StatusResponse message doesn't provide a Context field, and the sender is able to create new contexts, it MUST set the Status to 'Alive'. | ||||
6.2.10.2 | 206 | If the StatusResponse message doesn't provide a Context field, and the sender is unable to create new contexts, it MUST set the Status to 'Dead'. |
Spec | Assert ID | Feature | Semantics | Results | ||
---|---|---|---|---|---|---|
P | F | NI | ||||
6.2 | 150 | The Interaction Manager must support the basic life-cycle events. | ||||
6.2.1 | 96 | When the Interaction Manager receives a NewContextRequest event it MUST respond with a NewContextResponse event. | ||||
6.2.1 | 103 | The NewContextResponse event MUST ONLY be sent in response to the NewContextRequest event. | ||||
6.2.1.2 | 107 | If IM has accepted the NewContextRequest, it MUST set the Status field to Success. | ||||
6.2.1.2 | 108 | If the Status property of the NewContextResponse event is Failure then the context identifier MUST be empty. | ||||
6.2.1.2 | 153 | If the NewContextRequest Status field is set to Success, the IM MUST include a new context identifier. | ||||
6.2.2.1 | 163 | The IM MUST NOT specify both the ContentURL and Content in a single PrepareRequest. | ||||
6.2.3 | 166 | Start | To invoke a modality component, the IM MUST send a StartRequest. | |||
6.2.3 | 174 | The IM MUST NOT specify both the ContentURL and Content in a single StartRequest event. | ||||
6.2.7 | 185 | The IM MUST NOT send the ResumeRequest to a context that is not paused due to a previous PauseRequest. | ||||
6.2.9 | 65 | Clear Context | The IM SHOULD send a ClearContextRequest event to a MC to indicate that the specified context is no longer active and that any resources associated with it may be freed. | |||
6.2.9 | 189 | Once the IM has sent a ClearContextRequest to a Modality Component, it MUST NOT send the Modality Component any more events for that context. |
Spec | Assert ID | Feature | Semantics | Results | ||
---|---|---|---|---|---|---|
P | F | NI | ||||
6.2 | 94 | All Modality Components must support the basic life-cycle events. | ||||
6.2.2 | 155 | Modality Components MUST return a PrepareResponse event in response to a PrepareRequest event. | ||||
6.2.2 | 156 | Modality Components that return a PrepareResponse event with Status of 'Success' SHOULD be ready to run with close to 0 delay upon receipt of the StartRequest. | ||||
6.2.2 | 159 | When it receives multiple PrepareRequests, the Modality Component SHOULD prepare to run any of the specified content. | ||||
6.2.2.1 | 165 | If both contentURL and content of a PrepareRequest are empty, the Modality Component MUST revert to its default behavior. | ||||
6.2.2.1 | 207 | If a MC receives a PrepareRequest containing a new context (without a previous NewContextRequest/Response exchange), it MUST accept the new context and return a PrepareResponse message. | ||||
6.2.3 | 167 | The Modality Component MUST return a StartResponse event in response to a StartRequest event. | ||||
6.2.3 | 169 | If the IM includes a value in the ContentURL or Content field of the StartRequest event, the Modality Component MUST use this value. | ||||
6.2.3 | 170 | If a Modality Component receives a new StartRequest while it is executing a previous one, it MUST either cease execution of the previous StartRequest and begin executing the content specified in the most recent StartRequest, or reject the new StartRequest, returning a StartResponse with status equal to 'failure'. | ||||
6.2.3.1 | 176 | If the IM leaves both contentURL and content of a StartRequest event empty, the Modality Component MUST run the content specified in the most recent PrepareRequest in this context, if there is one. | ||||
6.2.3.1 | 177 | If the Modality Component did not receive a PrepareRequest event prior to receiving a StartRequest event with empty Content and ContentURL fields, it MUST revert to its default behavior. | ||||
6.2.4 | 8 | DoneNotification | If a modality component finishes processing it MUST send a DoneNotification | |||
6.2.5 | 178 | Cancel | A Modality Component MUST return a CancelResponse event in response to a CancelRequest event. | |||
6.2.5 | 184 | A Modality Component that receives a CancelRequest event MUST stop processing and then MUST return a CancelResponse. | ||||
6.2.5.2 | 24 | CancelResponse MUST be sent by the Modality Component as a response to the CancelRequest event | ||||
6.2.5.2 | 27 | CancelResponse MUST contain a Status field. | ||||
6.2.6 | 181 | Pause | Modality Components MUST return a PauseResponse once they have paused, or once they determine that they will be unable to pause. | |||
6.2.6.2 | 186 | Implementations that have received a ResumeRequest event even though they haven't paused MUST return a ResumeResponse with a Status of 'success'. | ||||
6.2.7 | 187 | The 'Status' of a ResumeResponse event MUST be 'success' if the implementation has succeeded in resuming processing and MUST be failure otherwise | ||||
6.2.7.1 | 5 | Implementations that have paused MUST attempt to resume processing upon receipt of this event and MUST return a ResumeResponse afterward. | ||||
6.2.9 | 69 | A MC MUST send a ClearContextResponse event in response to a ClearContextRequest event, even if doesn't take any particular action. |
The following XML should be used as a template for providing an implementation report.
<system-report name="YOUR-SYSTEM-NAME-HERE"> <testimonial>YOUR-WELL-FORMED-TESTIMONIAL-CONTENT-HERE</testimonial> <assert id="100" res="pass|fail|not-impl">OPTIONAL-NOTES-HERE</assert> </system-report>
The Multimodal Working Group would like to acknowledge the contributions of several individuals: