EmotionML 1.0:
Implementation Report Plan

10 May 2012

Editor:

Marc Schröder (DFKI GmbH)

Authors:

(in alphabetic order)

Felix Burkhardt (Deutsche Telekom AG)

Christian Peter (Fraunhofer Gesellschaft)

Copyright © 2012 W3C^® (MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use rules apply.

---

Table of Contents

• 1. Introduction
  • 1.1 Implementation report objectives
  • 1.2 Implementation report non-objectives
• 2. Work during the Candidate Recommendation period
• 3. Participating in the implementation report
• 4. Entrance criteria for the Proposed Recommendation phase
• 5. Implementation report requirements
  • 5.1 Detailed requirements for implementation report
  • 5.2 Notes on testing
  • 5.3 Out of scope
• 6. Systems
• 7. Test assertions
  • 7.1 Classification of test assertions
  • 7.2 EmotionML XML Schema conformance
  • 7.3 EmotionML test assertions
• Appendices
  • Appendix A. Implementation report submission format
  • Appendix B. Acknowledgements

1. Introduction

The EmotionML Specification entered the Candidate Recommendation period on 10 May 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.

An implementation report must indicate the outcome of evaluating the implementation with respect to each of the test assertions. Possible outcomes are "pass", "fail" or "not-impl". Criteria for Producers and Consumers of EmotionML for determining the outcome of each test assertion are defined as follows.

If a consumer:

• does anything (other than ignoring) when encountering the EmotionML markup described in an assertion, the test outcome is "pass";
• crashes when reading a valid document containing the EmotionML markup described in the assertion, the test outcome is "fail";
• ignores the markup described in the assertion, the test outcome is "not-impl". This could be the case e.g. for a consumer encountering a document that includes reference to action tendencies, but the consumer does not support action tendencies.

If a producer:

• generates valid EmotionML content containing the EmotionML markup described in the assertion, the test outcome is "pass";
• never generates EmotionML content containing the EmotionML markup described in the assertion, the test outcome is "not-impl";
• generates invalid EmotionML content containing the EmotionML markup described in the assertion, the test outcome is "fail". Schema validation may be helpful to verify whether a generated EmotionML document is valid or invalid. For limitations of Schema validation, refer to the section on Schema validation and processor validation of EmotionML documents of the EmotionML specification.

1.1 Implementation report objectives

• Must verify that the specification is implementable.

1.2 Implementation report non-objectives

• The IR does not attempt conformance testing of implementations.

2. Work during the Candidate Recommendation period

During the CR period, the Working Group will carry out the following activities:

1. Clarification and improvement of the exposition of the specification.
2. Disposing of comments that are communicated to the WG during the CR period.
3. Preparation of an Implementation Report meeting the criteria outlined in this document.

3. Participating in the implementation report

You are invited to contribute to the assessment of the W3C EmotionML 1.0 Specification by participating in the Implementation Report process.

• Deadline for submission of a EmotionML Implementation Report is 10 August 2012.
• All the test assertions are reported in the table below.
• Comments on this document or requests for further information should be sent to the Working Group's public mailing list www-multimodal@w3.org (archive). If an updated version of this document or the test assertion set is published, a notification will be sent to this mailing list.

4. Entrance criteria for the Proposed Recommendation phase

The Multimodal Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:

1. Sufficient reports of implementation experience have been gathered to demonstrate that EmotionML processors based on the specification are implementable and have compatible behavior.
2. Specific Implementation Report Requirements (outlined below) have been met.
3. The Working Group has formally addressed and responded to all public comments received by the Working Group.

5. Implementation report requirements

5.1 Detailed requirements for implementation report

1. Testimonials from implementers will be included in the IR when provided to document the utility and implementability of the specification.
2. IR must cover all specified features in the specification. For each feature the IR should indicate:
   • Feature status: required, optional, other.
   • Feature utility/usefulness based on feedback from implementers.
   • Implementability of the feature specification.
3. Feature status is a factor in test coverage in the report:
   • Required specification features must have at least two implementations. Implementations that do not implement a required specification feature must document the reason for not implementing the feature.
   • Optional specification features must have at least one implementation. Implementations that do not implement an optional specification feature should document the reason for not implementing the feature.

5.3 Out of scope

6. Systems

Note: The testimonials with pink background from "Acme Labs" and "Beta Inc." are just examples and will be replaced with the actually submitted testimonials.

7. Test assertions

The aim of this section is to describe the range of test assertions developed for the EmotionML 1.0 Specification. The table lists all the assertions that were derived from the EmotionML 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 EmotionML 1.0 Specification from which the assertion was derived. The REQ column is a Y/N value indicating whether the test assertion is for a feature which is required. The SUB column is a Y/N value indicating whether the test assertion is a subconstraint which is dependent on the implementation of the preceding non subconstraint feature test assertion. 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.

7.1 Classification of test assertions

Test assertions are classified into two types, basic test assertions which test for the presence of each feature, and sub constraints which only apply if that particular feature is implemented. Generally, sub constraints encode structural constraints that could not be expressed in the EmotionML schema. Sub constraints are marked with 'SUB CONSTRAINT:' in the Semantics field.

7.2 EmotionML XML Schema conformance

The most fundamental test of a conforming EmotionML implementation is that the EmotionML documents it utilizes must successfully validate with respect to the EmotionML XML Schema.

7.3 EmotionML Test assertions

Appendices

Appendix A - Implementation report submission format

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-TESTIMOMIAL-CONTENT-HERE</testimonial>
	<assert id="100" res="pass|fail|not-impl">OPTIONAL-NOTES-HERE</assert>
</system-report>

Appendix B - Acknowledgements

The Multimodal Working Group would like to acknowledge the contributions of several individuals:

• Kazuyuki Ashimura, W3C
• Paolo Baggia (Loquendo, S.p.A.)
• Catherine Pelachaud (Telecom ParisTech)
• Enrico Zovato (Loquendo, S.p.A.)