Fwd: [EmotionML] implementation release and feedbacks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [EmotionML] implementation release and feedbacks

Felix.Burkhardt
Dear implementers of EmotionML
To make a long story short: Alexandre Denis of Loria did a thorough review and implementation of EmotionML and found several flaws that we managed to fix, now two issues are still open and we need to know from you whether your implementation supports two features, namely:
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.

Please respond to this mail until 25th of November and state for both features whether it's "pass", "fail"  or "not-impl"
Please send the answer to the public mailing list:
[hidden email]

EmotionML will then soon become a real recommendation!

Thanks a lot,
Felix

>-----Ursprüngliche Nachricht-----
>Von: Kazuyuki Ashimura [mailto:[hidden email]]
>Gesendet: Montag, 28. Oktober 2013 07:57
>An: [hidden email]; [hidden email]
>Cc: Burkhardt, Felix; [hidden email]
>Betreff: Re: AW: [EmotionML] implementation release and feedbacks
>
>Dear Alexandre and EmotionML implementers,
>
>Thank you very much for implementing EmotionML, Alexandre!
>Also your thorough review on the EmotionML [1] specification and the
>Implementation Report [2] is really appreciated.
>
>We are very sorry it took much longer to get consensus about how to respond
>to you and wrap-up the procedure [3] to publish EmotionML as a W3C
>Recommendation.
>
>We the W3C Multimodal Interaction Working Group have already fixed typos
>in the spec and added necessary clarifications to it.  In addition, we have
>generated an updated version of the schema [5, 6].
>
>Now the remaining question is how to deal with your comments on the
>Implementation Report which wouldn't change the spec itself.
>
>I talked within the W3C Team about what we should have done from the W3C
>Process viewpoint, and it seems we need to make sure that there are enough
>implementation experience for the following two features which were not
>explicitly described in the published Implementation Report [2].
>
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.
>
>We have already checked with EmotionML implementers (including you) and
>it seems we can get several implementations for the above two features as
>well.
>
>Now we would like to ask all the EmotionML implementers to respond to this
>message and express if the aobve features are implmented so that we can
>finalize the procedure and publish EmotionML as a W3C Recommendation.
>
>[1] http://www.w3.org/TR/2013/PR-emotionml-20130416/
>[2] http://www.w3.org/2002/mmi/2013/emotionml-ir/
>[3] http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels
>[4] http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html
>[5] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd
>[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-
>fragments.xsd
>
>Sincerely,
>
>Kazuyuki Ashimura;
>for the W3C Multimodal Interaction Working Group
>
>
>
>On 05/02/2013 07:00 PM, [hidden email] wrote:
>> Congratulations, Alexandre
>>
>>  >Sorry to give you more work!
>>
>> Not at all, I'm indeed very happy you work with EmotionML and grateful
>> you do such a thorough job in revising it!
>>
>> It's just it'll take me/us some time to react on this, sorry about this.
>>
>> Kind regards,
>>
>> Felix
>>
>> *Von:*Alexandre Denis [mailto:[hidden email]]
>> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>> *An:* [hidden email]; Samuel CRUZ-LARA
>> *Betreff:* [EmotionML] implementation release and feedbacks
>>
>> Hello all,
>>
>> I'm happy to announce that we released the very first version of our
>> EmotionML Java implementation. It is hosted on google code and
>> released under the MIT license:
>> https://code.google.com/p/loria-synalp-emotionml/
>>
>> It is still considered as an alpha version, we would need some users
>> to validate its use. And there is still some work on the documentation
>> but the core of the code is there.
>>
>> If we could be listed as an implementation in the next round of the
>> implementation report it would be nice. Here is the description:
>>
>> Alexandre Denis, LORIA laboratory, SYNALP team, France
>>
>> The LORIA/SYNALP implementation of EmotionML is a Java standalone
>> library developed in the context of the ITEA Empathic Products project
>> by the LORIA/SYNALP team. It enables to import Java objects from
>> EmotionML XML files and export them to EmotionML as well. It
>> guarantees standard compliance by performing a two steps validation
>> after all export operations and before all import operations: first
>> the EmotionML schema is tested, then all EmotionML assertions are
>> tested. If one or the other fails, an error message is produced and
>> the document cannot be imported or exported. The library contains a
>> corpus of badly formatted EmotionML files that enables to double check
>> if both the schema and the assertions manage to correctly invalidate
>> them. The API is hosted on google code
>> (https://code.google.com/p/loria-synalp-emotionml/) and is released under
>the MIT License.
>>
>> Moreover I don't come to you with empty hands, and I have a bunch of
>> remarks related to the EmotionML specification. Sorry to give you more
>work!
>>
>> best regards,
>>
>> Alexandre Denis
>>
>> *** Comments about EmotionML specification
>>
>> In what follows:
>>
>> - "specification" refers to the document at
>> http://www.w3.org/TR/2013/PR-emotionml-20130416/ (version of 16 April
>> 2013)
>>
>> - "assertions" refers to the list of assertions at
>> http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class
>>
>> - "schema" refers to the schemas
>> http://www.w3.org/TR/emotionml/emotionml.xsd and
>> http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
>>
>> ** Specification clarification questions
>>
>> - About relative and absolute timing ?
>>
>>              - Is that possible to mix relative and absolute timing ?
>> Intuitively this would seem weird but nothing in the
>>
>>              specification prevents it.
>>
>> - About consistency of start/end/duration ?
>>
>>              - I think the specification does not enforce the
>> consistency of start, end and duration which are
>>
>>              possible alltogether. Hence it is possible to have
>> inconsistent triplets (start=0, end=5, duration=10).
>>
>> - About text nodes ?
>>
>>              - the emotion element can have text nodes children, it is
>> not specified how many. Is it possible to intersperse text nodes all
>> over
>>
>>              an emotion element ? The fact that an emotion element can
>> have text children is not specified in its children list.
>>
>> - About emotion children combinations ?
>>
>>              - the specification states "There are no constraints on
>> the combinations of children that are allowed.", it is maybe confusing
>> since
>>
>>              an emotion cannot contain two categories that belong to
>> different category-sets or two categories with the same name.
>>
>> - About default values ?
>>
>>              - some attributes have default values (reference role,
>> time ref anchor point, duration, etc.), is it desirable to have a
>> default
>>
>>              value also for other attributes, especially for the "value"
>> attribute ? For instance, how would you compare <category
>> name="surprise"/>
>>
>>              and <category name="surprise" value="1.0"/> ? Are they
>> semantically equivalent ? A similar question could be made about the
>> "confidence"
>>
>>              attribute, how would you compare <category
>> name="surprise"/> and <category name="surprise" confidence="1.0"/> ?
>>
>> - About the number of <trace> ?
>>
>>              - the specification does not state clearly if it is
>> possible to have several <trace> elements inside a descriptor, it is
>> stated
>>
>>              "a <trace> element". Maybe it should be stated "If
>> present the following child element can occur one or more time: <trace>".
>>
>>              The schema allows that. If this comment is accepted, the
>> assertions 215, 224, 235, 245 should also be clarified.
>>
>> - About conformance ?
>>
>>              - In section 4.3, it is stated "It is the responsibility
>> of an EmotionML processor to verify that the use of descriptor names
>> and values
>>
>>              is consistent with the vocabulary definition", which is
>> true but incomplete with regards to the assertions,
>>
>>              maybe it would be beneficial to specify all the
>> assertions that are not under the schema responsability but rather the
>> EmotionML processor
>>
>>              (see below) or at least warn that there are many
>> assertions not checked by the schema.
>>
>> ** Discrepancies between schema/assertions/specification
>>
>> - Assertions not tested by the schema
>>
>>              - I found that the following assertions are not tested by
>> the schema : 114, 117, 120, 123, 161, 164, 167, 170, 172, 210, 212,
>>
>>              216, 220, 222, 224, 230, 232, 236, 240, 242, 246, 410, 417.
>>
>>              There are assertions that are impossible to test with a
>> XSD schema I think:
>>
>>                          114, 117, 120, 123, 161, 164, 167, 170 :
>> vocabulary set id and type checking
>>
>>                          212, 222, 232, 242 : vocabulary name
>> membership
>>
>>                          417 : media type (unless enumerating them)
>>
>>              Some may be possible with some tweaking:
>>
>>                          210, 220, 230, 240 : vocabulary set presence
>>
>>                          216, 224, 236, 246 : <trace> and "value"
>>
>>              There are two "true" errors I think:
>>
>>                          172 : The "version" attribute of <emotion>,
>> if present, MUST have the  value "1.0"
>>
>>                                      I think it should not be
>> "optional with default value 1.0" but rather "optional with fixed value 1.0"
>>
>>                          410 : The <reference> element MUST contain a
>> "uri" attribute
>>
>>                                      the "uri" attribute is optional
>> by default in the schema
>>
>> - 2.4.1, "The end value MUST be greater than or equal to the start
>> value",
>>
>>              - the schema does not check it and there is no assertion
>> enforcing it
>>
>> - 2.1.2, "a typical use case is expected to be embedding an <emotion>
>> into some other markup",
>>
>>              - there is no assertion that describe that <emotion> may
>> be embedded in another markup, does it imply we could embed other
>elements ?
>>
>>              - is a document containing a sole <emotion> a valid
>> document (not in the sense of <emotionml> document) ? If yes, maybe an
>> assertion clarifiying the use of <emotion> would be useful.
>>
>> - assertions 105, 155, 601, 606, status "Req=N"
>>
>>              - the assertions mix the presence of <info> and the
>> number of <info> elements, while the presence is not restricted, the
>> number
>>
>>              MUST be 0 or 1, hence the required status wrt this part
>> of assertions should be "Req=Y"
>>
>> - 2.1.2, "There are no constraints on the order in which children occur"
>>
>>              - the schema does actually restrict the order of
>> elements, <info> needs to be first, then the descriptors, then the
>> references
>>
>> ** Invalid documents
>>
>> (I have not systematically tested examples with non-valid vocabulary
>> URIs such as http://www.example....)
>>
>> - http://www.w3.org/TR/emotion-voc/xml does not comply with assertion
>> 110 (hence all examples that refer to vocabularies there also fail)
>>
>> - 2.3.3 The <info> element
>>
>>              - The last example of this section does not comply with
>> assertion 212 since the name "neutral" does not belong to every-day
>> categories
>>
>> - 5.1.1 Annotation of Text, "Annotation of text" Lewis Caroll example:
>>
>>              - In the <meta:doc> element, the character & is found,
>> which does not pass XML validation, it should be &amp; (so does the
>> example below)
>>
>>              - It also does not comply with assertion 212 since
>> Disgust and Anger are not part of every-day categories
>>
>
>
>--
>Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>Tel: +81 466 49 1170

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] implementation release and feedbacks

Alexandre Denis
Hello all,

LORIA/Synalp EmotionML:
Feature1: pass
Feature2: pass

best,
Alexandre



On Thu, Nov 7, 2013 at 12:50 PM, <[hidden email]> wrote:
Dear implementers of EmotionML
To make a long story short: Alexandre Denis of Loria did a thorough review and implementation of EmotionML and found several flaws that we managed to fix, now two issues are still open and we need to know from you whether your implementation supports two features, namely:
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.

Please respond to this mail until 25th of November and state for both features whether it's "pass", "fail"  or "not-impl"
Please send the answer to the public mailing list:
[hidden email]

EmotionML will then soon become a real recommendation!

Thanks a lot,
Felix

>-----Ursprüngliche Nachricht-----
>Von: Kazuyuki Ashimura [mailto:[hidden email]]
>Gesendet: Montag, 28. Oktober 2013 07:57
>An: [hidden email]; [hidden email]
>Cc: Burkhardt, Felix; [hidden email]
>Betreff: Re: AW: [EmotionML] implementation release and feedbacks
>
>Dear Alexandre and EmotionML implementers,
>
>Thank you very much for implementing EmotionML, Alexandre!
>Also your thorough review on the EmotionML [1] specification and the
>Implementation Report [2] is really appreciated.
>
>We are very sorry it took much longer to get consensus about how to respond
>to you and wrap-up the procedure [3] to publish EmotionML as a W3C
>Recommendation.
>
>We the W3C Multimodal Interaction Working Group have already fixed typos
>in the spec and added necessary clarifications to it.  In addition, we have
>generated an updated version of the schema [5, 6].
>
>Now the remaining question is how to deal with your comments on the
>Implementation Report which wouldn't change the spec itself.
>
>I talked within the W3C Team about what we should have done from the W3C
>Process viewpoint, and it seems we need to make sure that there are enough
>implementation experience for the following two features which were not
>explicitly described in the published Implementation Report [2].
>
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.
>
>We have already checked with EmotionML implementers (including you) and
>it seems we can get several implementations for the above two features as
>well.
>
>Now we would like to ask all the EmotionML implementers to respond to this
>message and express if the aobve features are implmented so that we can
>finalize the procedure and publish EmotionML as a W3C Recommendation.
>
>[1] http://www.w3.org/TR/2013/PR-emotionml-20130416/
>[2] http://www.w3.org/2002/mmi/2013/emotionml-ir/
>[3] http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels
>[4] http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html
>[5] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd
>[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-
>fragments.xsd
>
>Sincerely,
>
>Kazuyuki Ashimura;
>for the W3C Multimodal Interaction Working Group
>
>
>
>On 05/02/2013 07:00 PM, [hidden email] wrote:
>> Congratulations, Alexandre
>>
>>  >Sorry to give you more work!
>>
>> Not at all, I'm indeed very happy you work with EmotionML and grateful
>> you do such a thorough job in revising it!
>>
>> It's just it'll take me/us some time to react on this, sorry about this.
>>
>> Kind regards,
>>
>> Felix
>>
>> *Von:*Alexandre Denis [mailto:[hidden email]]
>> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>> *An:* [hidden email]; Samuel CRUZ-LARA
>> *Betreff:* [EmotionML] implementation release and feedbacks
>>
>> Hello all,
>>
>> I'm happy to announce that we released the very first version of our
>> EmotionML Java implementation. It is hosted on google code and
>> released under the MIT license:
>> https://code.google.com/p/loria-synalp-emotionml/
>>
>> It is still considered as an alpha version, we would need some users
>> to validate its use. And there is still some work on the documentation
>> but the core of the code is there.
>>
>> If we could be listed as an implementation in the next round of the
>> implementation report it would be nice. Here is the description:
>>
>> Alexandre Denis, LORIA laboratory, SYNALP team, France
>>
>> The LORIA/SYNALP implementation of EmotionML is a Java standalone
>> library developed in the context of the ITEA Empathic Products project
>> by the LORIA/SYNALP team. It enables to import Java objects from
>> EmotionML XML files and export them to EmotionML as well. It
>> guarantees standard compliance by performing a two steps validation
>> after all export operations and before all import operations: first
>> the EmotionML schema is tested, then all EmotionML assertions are
>> tested. If one or the other fails, an error message is produced and
>> the document cannot be imported or exported. The library contains a
>> corpus of badly formatted EmotionML files that enables to double check
>> if both the schema and the assertions manage to correctly invalidate
>> them. The API is hosted on google code
>> (https://code.google.com/p/loria-synalp-emotionml/) and is released under
>the MIT License.
>>
>> Moreover I don't come to you with empty hands, and I have a bunch of
>> remarks related to the EmotionML specification. Sorry to give you more
>work!
>>
>> best regards,
>>
>> Alexandre Denis
>>
>> *** Comments about EmotionML specification
>>
>> In what follows:
>>
>> - "specification" refers to the document at
>> http://www.w3.org/TR/2013/PR-emotionml-20130416/ (version of 16 April
>> 2013)
>>
>> - "assertions" refers to the list of assertions at
>> http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class
>>
>> - "schema" refers to the schemas
>> http://www.w3.org/TR/emotionml/emotionml.xsd and
>> http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
>>
>> ** Specification clarification questions
>>
>> - About relative and absolute timing ?
>>
>>              - Is that possible to mix relative and absolute timing ?
>> Intuitively this would seem weird but nothing in the
>>
>>              specification prevents it.
>>
>> - About consistency of start/end/duration ?
>>
>>              - I think the specification does not enforce the
>> consistency of start, end and duration which are
>>
>>              possible alltogether. Hence it is possible to have
>> inconsistent triplets (start=0, end=5, duration=10).
>>
>> - About text nodes ?
>>
>>              - the emotion element can have text nodes children, it is
>> not specified how many. Is it possible to intersperse text nodes all
>> over
>>
>>              an emotion element ? The fact that an emotion element can
>> have text children is not specified in its children list.
>>
>> - About emotion children combinations ?
>>
>>              - the specification states "There are no constraints on
>> the combinations of children that are allowed.", it is maybe confusing
>> since
>>
>>              an emotion cannot contain two categories that belong to
>> different category-sets or two categories with the same name.
>>
>> - About default values ?
>>
>>              - some attributes have default values (reference role,
>> time ref anchor point, duration, etc.), is it desirable to have a
>> default
>>
>>              value also for other attributes, especially for the "value"
>> attribute ? For instance, how would you compare <category
>> name="surprise"/>
>>
>>              and <category name="surprise" value="1.0"/> ? Are they
>> semantically equivalent ? A similar question could be made about the
>> "confidence"
>>
>>              attribute, how would you compare <category
>> name="surprise"/> and <category name="surprise" confidence="1.0"/> ?
>>
>> - About the number of <trace> ?
>>
>>              - the specification does not state clearly if it is
>> possible to have several <trace> elements inside a descriptor, it is
>> stated
>>
>>              "a <trace> element". Maybe it should be stated "If
>> present the following child element can occur one or more time: <trace>".
>>
>>              The schema allows that. If this comment is accepted, the
>> assertions 215, 224, 235, 245 should also be clarified.
>>
>> - About conformance ?
>>
>>              - In section 4.3, it is stated "It is the responsibility
>> of an EmotionML processor to verify that the use of descriptor names
>> and values
>>
>>              is consistent with the vocabulary definition", which is
>> true but incomplete with regards to the assertions,
>>
>>              maybe it would be beneficial to specify all the
>> assertions that are not under the schema responsability but rather the
>> EmotionML processor
>>
>>              (see below) or at least warn that there are many
>> assertions not checked by the schema.
>>
>> ** Discrepancies between schema/assertions/specification
>>
>> - Assertions not tested by the schema
>>
>>              - I found that the following assertions are not tested by
>> the schema : 114, 117, 120, 123, 161, 164, 167, 170, 172, 210, 212,
>>
>>              216, 220, 222, 224, 230, 232, 236, 240, 242, 246, 410, 417.
>>
>>              There are assertions that are impossible to test with a
>> XSD schema I think:
>>
>>                          114, 117, 120, 123, 161, 164, 167, 170 :
>> vocabulary set id and type checking
>>
>>                          212, 222, 232, 242 : vocabulary name
>> membership
>>
>>                          417 : media type (unless enumerating them)
>>
>>              Some may be possible with some tweaking:
>>
>>                          210, 220, 230, 240 : vocabulary set presence
>>
>>                          216, 224, 236, 246 : <trace> and "value"
>>
>>              There are two "true" errors I think:
>>
>>                          172 : The "version" attribute of <emotion>,
>> if present, MUST have the  value "1.0"
>>
>>                                      I think it should not be
>> "optional with default value 1.0" but rather "optional with fixed value 1.0"
>>
>>                          410 : The <reference> element MUST contain a
>> "uri" attribute
>>
>>                                      the "uri" attribute is optional
>> by default in the schema
>>
>> - 2.4.1, "The end value MUST be greater than or equal to the start
>> value",
>>
>>              - the schema does not check it and there is no assertion
>> enforcing it
>>
>> - 2.1.2, "a typical use case is expected to be embedding an <emotion>
>> into some other markup",
>>
>>              - there is no assertion that describe that <emotion> may
>> be embedded in another markup, does it imply we could embed other
>elements ?
>>
>>              - is a document containing a sole <emotion> a valid
>> document (not in the sense of <emotionml> document) ? If yes, maybe an
>> assertion clarifiying the use of <emotion> would be useful.
>>
>> - assertions 105, 155, 601, 606, status "Req=N"
>>
>>              - the assertions mix the presence of <info> and the
>> number of <info> elements, while the presence is not restricted, the
>> number
>>
>>              MUST be 0 or 1, hence the required status wrt this part
>> of assertions should be "Req=Y"
>>
>> - 2.1.2, "There are no constraints on the order in which children occur"
>>
>>              - the schema does actually restrict the order of
>> elements, <info> needs to be first, then the descriptors, then the
>> references
>>
>> ** Invalid documents
>>
>> (I have not systematically tested examples with non-valid vocabulary
>> URIs such as http://www.example....)
>>
>> - http://www.w3.org/TR/emotion-voc/xml does not comply with assertion
>> 110 (hence all examples that refer to vocabularies there also fail)
>>
>> - 2.3.3 The <info> element
>>
>>              - The last example of this section does not comply with
>> assertion 212 since the name "neutral" does not belong to every-day
>> categories
>>
>> - 5.1.1 Annotation of Text, "Annotation of text" Lewis Caroll example:
>>
>>              - In the <meta:doc> element, the character & is found,
>> which does not pass XML validation, it should be &amp; (so does the
>> example below)
>>
>>              - It also does not comply with assertion 212 since
>> Disgust and Anger are not part of every-day categories
>>
>
>
>--
>Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170">+81 466 49 1170


Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] implementation release and feedbacks

Patrick Gebhard
In reply to this post by Felix.Burkhardt
Dear Felix,

I've updated ALMA (a DFKI EmotionML implementation) last October in esp. these two features, see attachment. Maybe my email got lost.

Anyway, Feature 1: pass, Feature 2: pass.

Best
Patrick

Am 07.11.2013 um 18:16 schrieb Marc Schröder <[hidden email]>:

Hi all,

DFKI's implementation has not-impl for both of these (unless it has been changed since I left).

Looking forward to seeing EmotionML become a Rec!

Best,
Marc


On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]> wrote:
Dear implementers of EmotionML
To make a long story short: Alexandre Denis of Loria did a thorough review and implementation of EmotionML and found several flaws that we managed to fix, now two issues are still open and we need to know from you whether your implementation supports two features, namely:
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.

Please respond to this mail until 25th of November and state for both features whether it's "pass", "fail"  or "not-impl"
Please send the answer to the public mailing list:
[hidden email]

EmotionML will then soon become a real recommendation!

Thanks a lot,
Felix

>-----Ursprüngliche Nachricht-----
>Von: Kazuyuki Ashimura [mailto:[hidden email]]
>Gesendet: Montag, 28. Oktober 2013 07:57
>An: [hidden email]; [hidden email]
>Cc: Burkhardt, Felix; [hidden email]
>Betreff: Re: AW: [EmotionML] implementation release and feedbacks
>
>Dear Alexandre and EmotionML implementers,
>
>Thank you very much for implementing EmotionML, Alexandre!
>Also your thorough review on the EmotionML [1] specification and the
>Implementation Report [2] is really appreciated.
>
>We are very sorry it took much longer to get consensus about how to respond
>to you and wrap-up the procedure [3] to publish EmotionML as a W3C
>Recommendation.
>
>We the W3C Multimodal Interaction Working Group have already fixed typos
>in the spec and added necessary clarifications to it.  In addition, we have
>generated an updated version of the schema [5, 6].
>
>Now the remaining question is how to deal with your comments on the
>Implementation Report which wouldn't change the spec itself.
>
>I talked within the W3C Team about what we should have done from the W3C
>Process viewpoint, and it seems we need to make sure that there are enough
>implementation experience for the following two features which were not
>explicitly described in the published Implementation Report [2].
>
>Feature1:
>    In Section 2.4.1 of the sepc [1], there is a feature "The end value
>    MUST be greater than or equal to the start value", which is not
>    checked in the Implementation Report.
>
>Feature2:
>    In Section 2.1.2 of the spec [1], there is a feature "a typical use
>    case is expected to be embedding an <emotion> into some other
>    markup", which is not checked in the Implementation Report.
>
>We have already checked with EmotionML implementers (including you) and
>it seems we can get several implementations for the above two features as
>well.
>
>Now we would like to ask all the EmotionML implementers to respond to this
>message and express if the aobve features are implmented so that we can
>finalize the procedure and publish EmotionML as a W3C Recommendation.
>
>[1] http://www.w3.org/TR/2013/PR-emotionml-20130416/
>[2] http://www.w3.org/2002/mmi/2013/emotionml-ir/
>[3] http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels
>[4] http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html
>[5] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd
>[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-
>fragments.xsd
>
>Sincerely,
>
>Kazuyuki Ashimura;
>for the W3C Multimodal Interaction Working Group
>
>
>
>On 05/02/2013 07:00 PM, [hidden email] wrote:
>> Congratulations, Alexandre
>>
>>  >Sorry to give you more work!
>>
>> Not at all, I'm indeed very happy you work with EmotionML and grateful
>> you do such a thorough job in revising it!
>>
>> It's just it'll take me/us some time to react on this, sorry about this.
>>
>> Kind regards,
>>
>> Felix
>>
>> *Von:*Alexandre Denis [mailto:[hidden email]]
>> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>> *An:* [hidden email]; Samuel CRUZ-LARA
>> *Betreff:* [EmotionML] implementation release and feedbacks
>>
>> Hello all,
>>
>> I'm happy to announce that we released the very first version of our
>> EmotionML Java implementation. It is hosted on google code and
>> released under the MIT license:
>> https://code.google.com/p/loria-synalp-emotionml/
>>
>> It is still considered as an alpha version, we would need some users
>> to validate its use. And there is still some work on the documentation
>> but the core of the code is there.
>>
>> If we could be listed as an implementation in the next round of the
>> implementation report it would be nice. Here is the description:
>>
>> Alexandre Denis, LORIA laboratory, SYNALP team, France
>>
>> The LORIA/SYNALP implementation of EmotionML is a Java standalone
>> library developed in the context of the ITEA Empathic Products project
>> by the LORIA/SYNALP team. It enables to import Java objects from
>> EmotionML XML files and export them to EmotionML as well. It
>> guarantees standard compliance by performing a two steps validation
>> after all export operations and before all import operations: first
>> the EmotionML schema is tested, then all EmotionML assertions are
>> tested. If one or the other fails, an error message is produced and
>> the document cannot be imported or exported. The library contains a
>> corpus of badly formatted EmotionML files that enables to double check
>> if both the schema and the assertions manage to correctly invalidate
>> them. The API is hosted on google code
>> (https://code.google.com/p/loria-synalp-emotionml/) and is released under
>the MIT License.
>>
>> Moreover I don't come to you with empty hands, and I have a bunch of
>> remarks related to the EmotionML specification. Sorry to give you more
>work!
>>
>> best regards,
>>
>> Alexandre Denis
>>
>> *** Comments about EmotionML specification
>>
>> In what follows:
>>
>> - "specification" refers to the document at
>> http://www.w3.org/TR/2013/PR-emotionml-20130416/ (version of 16 April
>> 2013)
>>
>> - "assertions" refers to the list of assertions at
>> http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class
>>
>> - "schema" refers to the schemas
>> http://www.w3.org/TR/emotionml/emotionml.xsd and
>> http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
>>
>> ** Specification clarification questions
>>
>> - About relative and absolute timing ?
>>
>>              - Is that possible to mix relative and absolute timing ?
>> Intuitively this would seem weird but nothing in the
>>
>>              specification prevents it.
>>
>> - About consistency of start/end/duration ?
>>
>>              - I think the specification does not enforce the
>> consistency of start, end and duration which are
>>
>>              possible alltogether. Hence it is possible to have
>> inconsistent triplets (start=0, end=5, duration=10).
>>
>> - About text nodes ?
>>
>>              - the emotion element can have text nodes children, it is
>> not specified how many. Is it possible to intersperse text nodes all
>> over
>>
>>              an emotion element ? The fact that an emotion element can
>> have text children is not specified in its children list.
>>
>> - About emotion children combinations ?
>>
>>              - the specification states "There are no constraints on
>> the combinations of children that are allowed.", it is maybe confusing
>> since
>>
>>              an emotion cannot contain two categories that belong to
>> different category-sets or two categories with the same name.
>>
>> - About default values ?
>>
>>              - some attributes have default values (reference role,
>> time ref anchor point, duration, etc.), is it desirable to have a
>> default
>>
>>              value also for other attributes, especially for the "value"
>> attribute ? For instance, how would you compare <category
>> name="surprise"/>
>>
>>              and <category name="surprise" value="1.0"/> ? Are they
>> semantically equivalent ? A similar question could be made about the
>> "confidence"
>>
>>              attribute, how would you compare <category
>> name="surprise"/> and <category name="surprise" confidence="1.0"/> ?
>>
>> - About the number of <trace> ?
>>
>>              - the specification does not state clearly if it is
>> possible to have several <trace> elements inside a descriptor, it is
>> stated
>>
>>              "a <trace> element". Maybe it should be stated "If
>> present the following child element can occur one or more time: <trace>".
>>
>>              The schema allows that. If this comment is accepted, the
>> assertions 215, 224, 235, 245 should also be clarified.
>>
>> - About conformance ?
>>
>>              - In section 4.3, it is stated "It is the responsibility
>> of an EmotionML processor to verify that the use of descriptor names
>> and values
>>
>>              is consistent with the vocabulary definition", which is
>> true but incomplete with regards to the assertions,
>>
>>              maybe it would be beneficial to specify all the
>> assertions that are not under the schema responsability but rather the
>> EmotionML processor
>>
>>              (see below) or at least warn that there are many
>> assertions not checked by the schema.
>>
>> ** Discrepancies between schema/assertions/specification
>>
>> - Assertions not tested by the schema
>>
>>              - I found that the following assertions are not tested by
>> the schema : 114, 117, 120, 123, 161, 164, 167, 170, 172, 210, 212,
>>
>>              216, 220, 222, 224, 230, 232, 236, 240, 242, 246, 410, 417.
>>
>>              There are assertions that are impossible to test with a
>> XSD schema I think:
>>
>>                          114, 117, 120, 123, 161, 164, 167, 170 :
>> vocabulary set id and type checking
>>
>>                          212, 222, 232, 242 : vocabulary name
>> membership
>>
>>                          417 : media type (unless enumerating them)
>>
>>              Some may be possible with some tweaking:
>>
>>                          210, 220, 230, 240 : vocabulary set presence
>>
>>                          216, 224, 236, 246 : <trace> and "value"
>>
>>              There are two "true" errors I think:
>>
>>                          172 : The "version" attribute of <emotion>,
>> if present, MUST have the  value "1.0"
>>
>>                                      I think it should not be
>> "optional with default value 1.0" but rather "optional with fixed value 1.0"
>>
>>                          410 : The <reference> element MUST contain a
>> "uri" attribute
>>
>>                                      the "uri" attribute is optional
>> by default in the schema
>>
>> - 2.4.1, "The end value MUST be greater than or equal to the start
>> value",
>>
>>              - the schema does not check it and there is no assertion
>> enforcing it
>>
>> - 2.1.2, "a typical use case is expected to be embedding an <emotion>
>> into some other markup",
>>
>>              - there is no assertion that describe that <emotion> may
>> be embedded in another markup, does it imply we could embed other
>elements ?
>>
>>              - is a document containing a sole <emotion> a valid
>> document (not in the sense of <emotionml> document) ? If yes, maybe an
>> assertion clarifiying the use of <emotion> would be useful.
>>
>> - assertions 105, 155, 601, 606, status "Req=N"
>>
>>              - the assertions mix the presence of <info> and the
>> number of <info> elements, while the presence is not restricted, the
>> number
>>
>>              MUST be 0 or 1, hence the required status wrt this part
>> of assertions should be "Req=Y"
>>
>> - 2.1.2, "There are no constraints on the order in which children occur"
>>
>>              - the schema does actually restrict the order of
>> elements, <info> needs to be first, then the descriptors, then the
>> references
>>
>> ** Invalid documents
>>
>> (I have not systematically tested examples with non-valid vocabulary
>> URIs such as http://www.example....)
>>
>> - http://www.w3.org/TR/emotion-voc/xml does not comply with assertion
>> 110 (hence all examples that refer to vocabularies there also fail)
>>
>> - 2.3.3 The <info> element
>>
>>              - The last example of this section does not comply with
>> assertion 212 since the name "neutral" does not belong to every-day
>> categories
>>
>> - 5.1.1 Annotation of Text, "Annotation of text" Lewis Caroll example:
>>
>>              - In the <meta:doc> element, the character & is found,
>> which does not pass XML validation, it should be &amp; (so does the
>> example below)
>>
>>              - It also does not comply with assertion 212 since
>> Disgust and Anger are not part of every-day categories
>>
>
>
>--
>Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170">+81 466 49 1170



EmotionML-Implementation Report Submission.xml (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Kazuyuki Ashimura
Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

Thank you very much for your EmotionML implementations!  And I am very
sorry I did not respond to you earlier.  It seems my original message
did not go out due to some trouble.

As you know, there were the following two features which were not
explicitly listed on the EmotionML Implementation Report Plan [a].

----------------------------------------------------------
Two features not listed on the Implementation Report Plan:
----------------------------------------------------------
Feature1:
   In Section 2.4.1 of the spec [b], there is a feature "The end value
   MUST be greater than or equal to the start value", which is not
   checked in the Implementation Report.

Feature2:
   In Section 2.1.2 of the spec [b], there is a feature "a typical use
   case is expected to be embedding an <emotion> into some other
   markup", which is not checked in the Implementation Report.

However, according to the responses so far, we have already
got the following implementations for the above features.

------------------------------------------------
Implementation status of the above two features:
------------------------------------------------

Feature1: 3 implementations
- Gerhard Fobe:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html
- Alexandre Denis:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html
- Patrick Gebhard:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html

Feature2: 4 implementations
- Gerhard Fobe:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html
- Debbie Dahl:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html
- Alexandre Denis:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html
- Patrick Gebhard:
http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html

As I reported in October [c], we have already fixed typos in the spec
and added necessary clarifications to it.  Also we have fixed the
errors in the EmotionML schema.

So I would like to confirm that it is the time for us all to go ahead
and publish EmotionML as a W3C Recommendation.

Alexandre (as the original commenter), is that OK by you?

[a] http://www.w3.org/2002/mmi/2012/emotionml-irp/
[b] http://www.w3.org/TR/2013/PR-emotionml-20130416/
[c] http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html

Thanks,

Kazuyuki


On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

> Dear Felix,
>
> I've updated ALMA (a DFKI EmotionML implementation) last October in esp.
> these two features, see attachment. Maybe my email got lost.
>
> Anyway, Feature 1: pass, Feature 2: pass.
>
> Best
> Patrick
>
> Am 07.11.2013 um 18:16 schrieb Marc Schröder <[hidden email]
> <mailto:[hidden email]>>:
>
>> Hi all,
>>
>> DFKI's implementation has not-impl for both of these (unless it has
>> been changed since I left).
>>
>> Looking forward to seeing EmotionML become a Rec!
>>
>> Best,
>> Marc
>>
>>
>> On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Dear implementers of EmotionML
>>     To make a long story short: Alexandre Denis of Loria did a
>>     thorough review and implementation of EmotionML and found several
>>     flaws that we managed to fix, now two issues are still open and we
>>     need to know from you whether your implementation supports two
>>     features, namely:
>>     >Feature1:
>>     >    In Section 2.4.1 of the sepc [1], there is a feature "The end
>>     value
>>     >    MUST be greater than or equal to the start value", which is not
>>     >    checked in the Implementation Report.
>>     >
>>     >Feature2:
>>     >    In Section 2.1.2 of the spec [1], there is a feature "a
>>     typical use
>>     >    case is expected to be embedding an <emotion> into some other
>>     >    markup", which is not checked in the Implementation Report.
>>
>>     Please respond to this mail until 25th of November and state for
>>     both features whether it's "pass", "fail"  or "not-impl"
>>     Please send the answer to the public mailing list:
>>     [hidden email] <mailto:[hidden email]>
>>
>>     EmotionML will then soon become a real recommendation!
>>
>>     Thanks a lot,
>>     Felix
>>
>>     >-----Ursprüngliche Nachricht-----
>>     >Von: Kazuyuki Ashimura [mailto:[hidden email]
>>     <mailto:[hidden email]>]
>>     >Gesendet: Montag, 28. Oktober 2013 07:57
>>     >An: [hidden email] <mailto:[hidden email]>;
>>     [hidden email] <mailto:[hidden email]>
>>     >Cc: Burkhardt, Felix; [hidden email]
>>     <mailto:[hidden email]>
>>     >Betreff: Re: AW: [EmotionML] implementation release and feedbacks
>>     >
>>     >Dear Alexandre and EmotionML implementers,
>>     >
>>     >Thank you very much for implementing EmotionML, Alexandre!
>>     >Also your thorough review on the EmotionML [1] specification and the
>>     >Implementation Report [2] is really appreciated.
>>     >
>>     >We are very sorry it took much longer to get consensus about how
>>     to respond
>>     >to you and wrap-up the procedure [3] to publish EmotionML as a W3C
>>     >Recommendation.
>>     >
>>     >We the W3C Multimodal Interaction Working Group have already
>>     fixed typos
>>     >in the spec and added necessary clarifications to it.  In
>>     addition, we have
>>     >generated an updated version of the schema [5, 6].
>>     >
>>     >Now the remaining question is how to deal with your comments on the
>>     >Implementation Report which wouldn't change the spec itself.
>>     >
>>     >I talked within the W3C Team about what we should have done from
>>     the W3C
>>     >Process viewpoint, and it seems we need to make sure that there
>>     are enough
>>     >implementation experience for the following two features which
>>     were not
>>     >explicitly described in the published Implementation Report [2].
>>     >
>>     >Feature1:
>>     >    In Section 2.4.1 of the sepc [1], there is a feature "The end
>>     value
>>     >    MUST be greater than or equal to the start value", which is not
>>     >    checked in the Implementation Report.
>>     >
>>     >Feature2:
>>     >    In Section 2.1.2 of the spec [1], there is a feature "a
>>     typical use
>>     >    case is expected to be embedding an <emotion> into some other
>>     >    markup", which is not checked in the Implementation Report.
>>     >
>>     >We have already checked with EmotionML implementers (including
>>     you) and
>>     >it seems we can get several implementations for the above two
>>     features as
>>     >well.
>>     >
>>     >Now we would like to ask all the EmotionML implementers to
>>     respond to this
>>     >message and express if the aobve features are implmented so that
>>     we can
>>     >finalize the procedure and publish EmotionML as a W3C Recommendation.
>>     >
>>     >[1] http://www.w3.org/TR/2013/PR-emotionml-20130416/
>>     >[2] http://www.w3.org/2002/mmi/2013/emotionml-ir/
>>     >[3]
>>     http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels
>>     >[4]
>>     http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html
>>     >[5] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd
>>     >[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-
>>     >fragments.xsd
>>     >
>>     >Sincerely,
>>     >
>>     >Kazuyuki Ashimura;
>>     >for the W3C Multimodal Interaction Working Group
>>     >
>>     >
>>     >
>>     >On 05/02/2013 07:00 PM, [hidden email]
>>     <mailto:[hidden email]> wrote:
>>     >> Congratulations, Alexandre
>>     >>
>>     >>  >Sorry to give you more work!
>>     >>
>>     >> Not at all, I'm indeed very happy you work with EmotionML and
>>     grateful
>>     >> you do such a thorough job in revising it!
>>     >>
>>     >> It's just it'll take me/us some time to react on this, sorry
>>     about this.
>>     >>
>>     >> Kind regards,
>>     >>
>>     >> Felix
>>     >>
>>     >> *Von:*Alexandre Denis [mailto:[hidden email]
>>     <mailto:[hidden email]>]
>>     >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>>     >> *An:* [hidden email] <mailto:[hidden email]>;
>>     Samuel CRUZ-LARA
>>     >> *Betreff:* [EmotionML] implementation release and feedbacks
>>     >>
>>     >> Hello all,
>>     >>
>>     >> I'm happy to announce that we released the very first version
>>     of our
>>     >> EmotionML Java implementation. It is hosted on google code and
>>     >> released under the MIT license:
>>     >> https://code.google.com/p/loria-synalp-emotionml/
>>     >>
>>     >> It is still considered as an alpha version, we would need some
>>     users
>>     >> to validate its use. And there is still some work on the
>>     documentation
>>     >> but the core of the code is there.
>>     >>
>>     >> If we could be listed as an implementation in the next round of the
>>     >> implementation report it would be nice. Here is the description:
>>     >>
>>     >> Alexandre Denis, LORIA laboratory, SYNALP team, France
>>     >>
>>     >> The LORIA/SYNALP implementation of EmotionML is a Java standalone
>>     >> library developed in the context of the ITEA Empathic Products
>>     project
>>     >> by the LORIA/SYNALP team. It enables to import Java objects from
>>     >> EmotionML XML files and export them to EmotionML as well. It
>>     >> guarantees standard compliance by performing a two steps validation
>>     >> after all export operations and before all import operations: first
>>     >> the EmotionML schema is tested, then all EmotionML assertions are
>>     >> tested. If one or the other fails, an error message is produced and
>>     >> the document cannot be imported or exported. The library contains a
>>     >> corpus of badly formatted EmotionML files that enables to
>>     double check
>>     >> if both the schema and the assertions manage to correctly
>>     invalidate
>>     >> them. The API is hosted on google code
>>     >> (https://code.google.com/p/loria-synalp-emotionml/) and is
>>     released under
>>     >the MIT License.
>>     >>
>>     >> Moreover I don't come to you with empty hands, and I have a
>>     bunch of
>>     >> remarks related to the EmotionML specification. Sorry to give
>>     you more
>>     >work!
>>     >>
>>     >> best regards,
>>     >>
>>     >> Alexandre Denis
>>     >>
>>     >> *** Comments about EmotionML specification
>>     >>
>>     >> In what follows:
>>     >>
>>     >> - "specification" refers to the document at
>>     >> http://www.w3.org/TR/2013/PR-emotionml-20130416/ (version of 16
>>     April
>>     >> 2013)
>>     >>
>>     >> - "assertions" refers to the list of assertions at
>>     >> http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class
>>     >>
>>     >> - "schema" refers to the schemas
>>     >> http://www.w3.org/TR/emotionml/emotionml.xsd and
>>     >> http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
>>     >>
>>     >> ** Specification clarification questions
>>     >>
>>     >> - About relative and absolute timing ?
>>     >>
>>     >>              - Is that possible to mix relative and absolute
>>     timing ?
>>     >> Intuitively this would seem weird but nothing in the
>>     >>
>>     >>              specification prevents it.
>>     >>
>>     >> - About consistency of start/end/duration ?
>>     >>
>>     >>              - I think the specification does not enforce the
>>     >> consistency of start, end and duration which are
>>     >>
>>     >>              possible alltogether. Hence it is possible to have
>>     >> inconsistent triplets (start=0, end=5, duration=10).
>>     >>
>>     >> - About text nodes ?
>>     >>
>>     >>              - the emotion element can have text nodes
>>     children, it is
>>     >> not specified how many. Is it possible to intersperse text
>>     nodes all
>>     >> over
>>     >>
>>     >>              an emotion element ? The fact that an emotion
>>     element can
>>     >> have text children is not specified in its children list.
>>     >>
>>     >> - About emotion children combinations ?
>>     >>
>>     >>              - the specification states "There are no
>>     constraints on
>>     >> the combinations of children that are allowed.", it is maybe
>>     confusing
>>     >> since
>>     >>
>>     >>              an emotion cannot contain two categories that
>>     belong to
>>     >> different category-sets or two categories with the same name.
>>     >>
>>     >> - About default values ?
>>     >>
>>     >>              - some attributes have default values (reference role,
>>     >> time ref anchor point, duration, etc.), is it desirable to have a
>>     >> default
>>     >>
>>     >>              value also for other attributes, especially for
>>     the "value"
>>     >> attribute ? For instance, how would you compare <category
>>     >> name="surprise"/>
>>     >>
>>     >>              and <category name="surprise" value="1.0"/> ? Are they
>>     >> semantically equivalent ? A similar question could be made
>>     about the
>>     >> "confidence"
>>     >>
>>     >>              attribute, how would you compare <category
>>     >> name="surprise"/> and <category name="surprise"
>>     confidence="1.0"/> ?
>>     >>
>>     >> - About the number of <trace> ?
>>     >>
>>     >>              - the specification does not state clearly if it is
>>     >> possible to have several <trace> elements inside a descriptor,
>>     it is
>>     >> stated
>>     >>
>>     >>              "a <trace> element". Maybe it should be stated "If
>>     >> present the following child element can occur one or more time:
>>     <trace>".
>>     >>
>>     >>              The schema allows that. If this comment is
>>     accepted, the
>>     >> assertions 215, 224, 235, 245 should also be clarified.
>>     >>
>>     >> - About conformance ?
>>     >>
>>     >>              - In section 4.3, it is stated "It is the
>>     responsibility
>>     >> of an EmotionML processor to verify that the use of descriptor
>>     names
>>     >> and values
>>     >>
>>     >>              is consistent with the vocabulary definition",
>>     which is
>>     >> true but incomplete with regards to the assertions,
>>     >>
>>     >>              maybe it would be beneficial to specify all the
>>     >> assertions that are not under the schema responsability but
>>     rather the
>>     >> EmotionML processor
>>     >>
>>     >>              (see below) or at least warn that there are many
>>     >> assertions not checked by the schema.
>>     >>
>>     >> ** Discrepancies between schema/assertions/specification
>>     >>
>>     >> - Assertions not tested by the schema
>>     >>
>>     >>              - I found that the following assertions are not
>>     tested by
>>     >> the schema : 114, 117, 120, 123, 161, 164, 167, 170, 172, 210, 212,
>>     >>
>>     >>              216, 220, 222, 224, 230, 232, 236, 240, 242, 246,
>>     410, 417.
>>     >>
>>     >>              There are assertions that are impossible to test
>>     with a
>>     >> XSD schema I think:
>>     >>
>>     >>                          114, 117, 120, 123, 161, 164, 167, 170 :
>>     >> vocabulary set id and type checking
>>     >>
>>     >>                          212, 222, 232, 242 : vocabulary name
>>     >> membership
>>     >>
>>     >>                          417 : media type (unless enumerating them)
>>     >>
>>     >>              Some may be possible with some tweaking:
>>     >>
>>     >>                          210, 220, 230, 240 : vocabulary set
>>     presence
>>     >>
>>     >>                          216, 224, 236, 246 : <trace> and "value"
>>     >>
>>     >>              There are two "true" errors I think:
>>     >>
>>     >>                          172 : The "version" attribute of
>>     <emotion>,
>>     >> if present, MUST have the  value "1.0"
>>     >>
>>     >>                                      I think it should not be
>>     >> "optional with default value 1.0" but rather "optional with
>>     fixed value 1.0"
>>     >>
>>     >>                          410 : The <reference> element MUST
>>     contain a
>>     >> "uri" attribute
>>     >>
>>     >>                                      the "uri" attribute is
>>     optional
>>     >> by default in the schema
>>     >>
>>     >> - 2.4.1, "The end value MUST be greater than or equal to the start
>>     >> value",
>>     >>
>>     >>              - the schema does not check it and there is no
>>     assertion
>>     >> enforcing it
>>     >>
>>     >> - 2.1.2, "a typical use case is expected to be embedding an
>>     <emotion>
>>     >> into some other markup",
>>     >>
>>     >>              - there is no assertion that describe that
>>     <emotion> may
>>     >> be embedded in another markup, does it imply we could embed other
>>     >elements ?
>>     >>
>>     >>              - is a document containing a sole <emotion> a valid
>>     >> document (not in the sense of <emotionml> document) ? If yes,
>>     maybe an
>>     >> assertion clarifiying the use of <emotion> would be useful.
>>     >>
>>     >> - assertions 105, 155, 601, 606, status "Req=N"
>>     >>
>>     >>              - the assertions mix the presence of <info> and the
>>     >> number of <info> elements, while the presence is not
>>     restricted, the
>>     >> number
>>     >>
>>     >>              MUST be 0 or 1, hence the required status wrt this
>>     part
>>     >> of assertions should be "Req=Y"
>>     >>
>>     >> - 2.1.2, "There are no constraints on the order in which
>>     children occur"
>>     >>
>>     >>              - the schema does actually restrict the order of
>>     >> elements, <info> needs to be first, then the descriptors, then the
>>     >> references
>>     >>
>>     >> ** Invalid documents
>>     >>
>>     >> (I have not systematically tested examples with non-valid
>>     vocabulary
>>     >> URIs such as http://www.example. <http://www.example./>...)
>>     >>
>>     >> - http://www.w3.org/TR/emotion-voc/xml does not comply with
>>     assertion
>>     >> 110 (hence all examples that refer to vocabularies there also fail)
>>     >>
>>     >> - 2.3.3 The <info> element
>>     >>
>>     >>              - The last example of this section does not comply
>>     with
>>     >> assertion 212 since the name "neutral" does not belong to every-day
>>     >> categories
>>     >>
>>     >> - 5.1.1 Annotation of Text, "Annotation of text" Lewis Caroll
>>     example:
>>     >>
>>     >>              - In the <meta:doc> element, the character & is found,
>>     >> which does not pass XML validation, it should be &amp; (so does the
>>     >> example below)
>>     >>
>>     >>              - It also does not comply with assertion 212 since
>>     >> Disgust and Anger are not part of every-day categories
>>     >>
>>     >
>>     >
>>     >--
>>     >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>>     >Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
>>
>>
> =
>
>


--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Alexandre Denis
Hello all,
yes sure, but since I don't see the new specification, I can only trust you that the (small) mistakes are corrected. As for the schemas,  

>[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-fragments.xsd

The only difference I see with the schemas stored in our implementation is the required status of the version attribute of the <emotionml> tag, and it's possible I altered the schema myself because of the lack of the version in http://www.w3.org/TR/emotion-voc/xml. It is also important to fix the version attribute on this document, otherwise every emotionml document referring to these vocabularies will fail to pass validation (I had to manually disable the corresponding assertion check in the code),

best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]> wrote:
Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

Thank you very much for your EmotionML implementations!  And I am very
sorry I did not respond to you earlier.  It seems my original message
did not go out due to some trouble.

As you know, there were the following two features which were not
explicitly listed on the EmotionML Implementation Report Plan [a].

----------------------------------------------------------
Two features not listed on the Implementation Report Plan:
----------------------------------------------------------
Feature1:
  In Section 2.4.1 of the spec [b], there is a feature "The end value
  MUST be greater than or equal to the start value", which is not
  checked in the Implementation Report.

Feature2:
  In Section 2.1.2 of the spec [b], there is a feature "a typical use
  case is expected to be embedding an <emotion> into some other
  markup", which is not checked in the Implementation Report.

However, according to the responses so far, we have already
got the following implementations for the above features.

------------------------------------------------
Implementation status of the above two features:
------------------------------------------------

Feature1: 3 implementations
- Gerhard Fobe: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html
- Alexandre Denis: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html
- Patrick Gebhard: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html

Feature2: 4 implementations
- Gerhard Fobe: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html
- Debbie Dahl: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html
- Alexandre Denis: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html
- Patrick Gebhard: http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html

As I reported in October [c], we have already fixed typos in the spec
and added necessary clarifications to it.  Also we have fixed the
errors in the EmotionML schema.

So I would like to confirm that it is the time for us all to go ahead
and publish EmotionML as a W3C Recommendation.

Alexandre (as the original commenter), is that OK by you?

[a] http://www.w3.org/2002/mmi/2012/emotionml-irp/
[b] http://www.w3.org/TR/2013/PR-emotionml-20130416/
[c] http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html

Thanks,

Kazuyuki


On 11/08/2013 04:52 AM, Patrick Gebhard wrote:
Dear Felix,

I've updated ALMA (a DFKI EmotionML implementation) last October in esp.
these two features, see attachment. Maybe my email got lost.

Anyway, Feature 1: pass, Feature 2: pass.

Best
Patrick

Am 07.11.2013 um 18:16 schrieb Marc Schröder <[hidden email]
<mailto:[hidden email]>>:

Hi all,

DFKI's implementation has not-impl for both of these (unless it has
been changed since I left).

Looking forward to seeing EmotionML become a Rec!

Best,
Marc


On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
<mailto:[hidden email]>> wrote:

    Dear implementers of EmotionML
    To make a long story short: Alexandre Denis of Loria did a
    thorough review and implementation of EmotionML and found several
    flaws that we managed to fix, now two issues are still open and we
    need to know from you whether your implementation supports two
    features, namely:
    >Feature1:
    >    In Section 2.4.1 of the sepc [1], there is a feature "The end
    value
    >    MUST be greater than or equal to the start value", which is not
    >    checked in the Implementation Report.
    >
    >Feature2:
    >    In Section 2.1.2 of the spec [1], there is a feature "a
    typical use
    >    case is expected to be embedding an <emotion> into some other
    >    markup", which is not checked in the Implementation Report.

    Please respond to this mail until 25th of November and state for
    both features whether it's "pass", "fail"  or "not-impl"
    Please send the answer to the public mailing list:
    [hidden email] <mailto:[hidden email]>

    EmotionML will then soon become a real recommendation!

    Thanks a lot,
    Felix

    >-----Ursprüngliche Nachricht-----
    >Von: Kazuyuki Ashimura [mailto:[hidden email]
    <mailto:[hidden email]>]
    >Gesendet: Montag, 28. Oktober 2013 07:57
    >An: [hidden email] <mailto:[hidden email]>;
    [hidden email] <mailto:[hidden email]>
    >Cc: Burkhardt, Felix; [hidden email]
    <mailto:[hidden email]>
    >Betreff: Re: AW: [EmotionML] implementation release and feedbacks
    >
    >Dear Alexandre and EmotionML implementers,
    >
    >Thank you very much for implementing EmotionML, Alexandre!
    >Also your thorough review on the EmotionML [1] specification and the
    >Implementation Report [2] is really appreciated.
    >
    >We are very sorry it took much longer to get consensus about how
    to respond
    >to you and wrap-up the procedure [3] to publish EmotionML as a W3C
    >Recommendation.
    >
    >We the W3C Multimodal Interaction Working Group have already
    fixed typos
    >in the spec and added necessary clarifications to it.  In
    addition, we have
    >generated an updated version of the schema [5, 6].
    >
    >Now the remaining question is how to deal with your comments on the
    >Implementation Report which wouldn't change the spec itself.
    >
    >I talked within the W3C Team about what we should have done from
    the W3C
    >Process viewpoint, and it seems we need to make sure that there
    are enough
    >implementation experience for the following two features which
    were not
    >explicitly described in the published Implementation Report [2].
    >
    >Feature1:
    >    In Section 2.4.1 of the sepc [1], there is a feature "The end
    value
    >    MUST be greater than or equal to the start value", which is not
    >    checked in the Implementation Report.
    >
    >Feature2:
    >    In Section 2.1.2 of the spec [1], there is a feature "a
    typical use
    >    case is expected to be embedding an <emotion> into some other
    >    markup", which is not checked in the Implementation Report.
    >
    >We have already checked with EmotionML implementers (including
    you) and
    >it seems we can get several implementations for the above two
    features as
    >well.
    >
    >Now we would like to ask all the EmotionML implementers to
    respond to this
    >message and express if the aobve features are implmented so that
    we can
    >finalize the procedure and publish EmotionML as a W3C Recommendation.
    >
    >[1] http://www.w3.org/TR/2013/PR-emotionml-20130416/
    >[2] http://www.w3.org/2002/mmi/2013/emotionml-ir/
    >[3]
    http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels
    >[4]
    http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html
    >[5] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd
    >[6] http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml-
    >fragments.xsd
    >
    >Sincerely,
    >
    >Kazuyuki Ashimura;
    >for the W3C Multimodal Interaction Working Group
    >
    >
    >
    >On 05/02/2013 07:00 PM, [hidden email]
    <mailto:[hidden email]> wrote:
    >> Congratulations, Alexandre
    >>
    >>  >Sorry to give you more work!
    >>
    >> Not at all, I'm indeed very happy you work with EmotionML and
    grateful
    >> you do such a thorough job in revising it!
    >>
    >> It's just it'll take me/us some time to react on this, sorry
    about this.
    >>
    >> Kind regards,
    >>
    >> Felix
    >>
    >> *Von:*Alexandre Denis [mailto:[hidden email]
    <mailto:[hidden email]>]
    >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
    >> *An:* [hidden email] <mailto:[hidden email]>;
    Samuel CRUZ-LARA
    >> *Betreff:* [EmotionML] implementation release and feedbacks
    >>
    >> Hello all,
    >>
    >> I'm happy to announce that we released the very first version
    of our
    >> EmotionML Java implementation. It is hosted on google code and
    >> released under the MIT license:
    >> https://code.google.com/p/loria-synalp-emotionml/
    >>
    >> It is still considered as an alpha version, we would need some
    users
    >> to validate its use. And there is still some work on the
    documentation
    >> but the core of the code is there.
    >>
    >> If we could be listed as an implementation in the next round of the
    >> implementation report it would be nice. Here is the description:
    >>
    >> Alexandre Denis, LORIA laboratory, SYNALP team, France
    >>
    >> The LORIA/SYNALP implementation of EmotionML is a Java standalone
    >> library developed in the context of the ITEA Empathic Products
    project
    >> by the LORIA/SYNALP team. It enables to import Java objects from
    >> EmotionML XML files and export them to EmotionML as well. It
    >> guarantees standard compliance by performing a two steps validation
    >> after all export operations and before all import operations: first
    >> the EmotionML schema is tested, then all EmotionML assertions are
    >> tested. If one or the other fails, an error message is produced and
    >> the document cannot be imported or exported. The library contains a
    >> corpus of badly formatted EmotionML files that enables to
    double check
    >> if both the schema and the assertions manage to correctly
    invalidate
    >> them. The API is hosted on google code
    >> (https://code.google.com/p/loria-synalp-emotionml/) and is
    released under
    >the MIT License.
    >>
    >> Moreover I don't come to you with empty hands, and I have a
    bunch of
    >> remarks related to the EmotionML specification. Sorry to give
    you more
    >work!
    >>
    >> best regards,
    >>
    >> Alexandre Denis
    >>
    >> *** Comments about EmotionML specification
    >>
    >> In what follows:
    >>
    >> - "specification" refers to the document at
    >> http://www.w3.org/TR/2013/PR-emotionml-20130416/ (version of 16
    April
    >> 2013)
    >>
    >> - "assertions" refers to the list of assertions at
    >> http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class
    >>
    >> - "schema" refers to the schemas
    >> http://www.w3.org/TR/emotionml/emotionml.xsd and
    >> http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
    >>
    >> ** Specification clarification questions
    >>
    >> - About relative and absolute timing ?
    >>
    >>              - Is that possible to mix relative and absolute
    timing ?
    >> Intuitively this would seem weird but nothing in the
    >>
    >>              specification prevents it.
    >>
    >> - About consistency of start/end/duration ?
    >>
    >>              - I think the specification does not enforce the
    >> consistency of start, end and duration which are
    >>
    >>              possible alltogether. Hence it is possible to have
    >> inconsistent triplets (start=0, end=5, duration=10).
    >>
    >> - About text nodes ?
    >>
    >>              - the emotion element can have text nodes
    children, it is
    >> not specified how many. Is it possible to intersperse text
    nodes all
    >> over
    >>
    >>              an emotion element ? The fact that an emotion
    element can
    >> have text children is not specified in its children list.
    >>
    >> - About emotion children combinations ?
    >>
    >>              - the specification states "There are no
    constraints on
    >> the combinations of children that are allowed.", it is maybe
    confusing
    >> since
    >>
    >>              an emotion cannot contain two categories that
    belong to
    >> different category-sets or two categories with the same name.
    >>
    >> - About default values ?
    >>
    >>              - some attributes have default values (reference role,
    >> time ref anchor point, duration, etc.), is it desirable to have a
    >> default
    >>
    >>              value also for other attributes, especially for
    the "value"
    >> attribute ? For instance, how would you compare <category
    >> name="surprise"/>
    >>
    >>              and <category name="surprise" value="1.0"/> ? Are they
    >> semantically equivalent ? A similar question could be made
    about the
    >> "confidence"
    >>
    >>              attribute, how would you compare <category
    >> name="surprise"/> and <category name="surprise"
    confidence="1.0"/> ?
    >>
    >> - About the number of <trace> ?
    >>
    >>              - the specification does not state clearly if it is
    >> possible to have several <trace> elements inside a descriptor,
    it is
    >> stated
    >>
    >>              "a <trace> element". Maybe it should be stated "If
    >> present the following child element can occur one or more time:
    <trace>".
    >>
    >>              The schema allows that. If this comment is
    accepted, the
    >> assertions 215, 224, 235, 245 should also be clarified.
    >>
    >> - About conformance ?
    >>
    >>              - In section 4.3, it is stated "It is the
    responsibility
    >> of an EmotionML processor to verify that the use of descriptor
    names
    >> and values
    >>
    >>              is consistent with the vocabulary definition",
    which is
    >> true but incomplete with regards to the assertions,
    >>
    >>              maybe it would be beneficial to specify all the
    >> assertions that are not under the schema responsability but
    rather the
    >> EmotionML processor
    >>
    >>              (see below) or at least warn that there are many
    >> assertions not checked by the schema.
    >>
    >> ** Discrepancies between schema/assertions/specification
    >>
    >> - Assertions not tested by the schema
    >>
    >>              - I found that the following assertions are not
    tested by
    >> the schema : 114, 117, 120, 123, 161, 164, 167, 170, 172, 210, 212,
    >>
    >>              216, 220, 222, 224, 230, 232, 236, 240, 242, 246,
    410, 417.
    >>
    >>              There are assertions that are impossible to test
    with a
    >> XSD schema I think:
    >>
    >>                          114, 117, 120, 123, 161, 164, 167, 170 :
    >> vocabulary set id and type checking
    >>
    >>                          212, 222, 232, 242 : vocabulary name
    >> membership
    >>
    >>                          417 : media type (unless enumerating them)
    >>
    >>              Some may be possible with some tweaking:
    >>
    >>                          210, 220, 230, 240 : vocabulary set
    presence
    >>
    >>                          216, 224, 236, 246 : <trace> and "value"
    >>
    >>              There are two "true" errors I think:
    >>
    >>                          172 : The "version" attribute of
    <emotion>,
    >> if present, MUST have the  value "1.0"
    >>
    >>                                      I think it should not be
    >> "optional with default value 1.0" but rather "optional with
    fixed value 1.0"
    >>
    >>                          410 : The <reference> element MUST
    contain a
    >> "uri" attribute
    >>
    >>                                      the "uri" attribute is
    optional
    >> by default in the schema
    >>
    >> - 2.4.1, "The end value MUST be greater than or equal to the start
    >> value",
    >>
    >>              - the schema does not check it and there is no
    assertion
    >> enforcing it
    >>
    >> - 2.1.2, "a typical use case is expected to be embedding an
    <emotion>
    >> into some other markup",
    >>
    >>              - there is no assertion that describe that
    <emotion> may
    >> be embedded in another markup, does it imply we could embed other
    >elements ?
    >>
    >>              - is a document containing a sole <emotion> a valid
    >> document (not in the sense of <emotionml> document) ? If yes,
    maybe an
    >> assertion clarifiying the use of <emotion> would be useful.
    >>
    >> - assertions 105, 155, 601, 606, status "Req=N"
    >>
    >>              - the assertions mix the presence of <info> and the
    >> number of <info> elements, while the presence is not
    restricted, the
    >> number
    >>
    >>              MUST be 0 or 1, hence the required status wrt this
    part
    >> of assertions should be "Req=Y"
    >>
    >> - 2.1.2, "There are no constraints on the order in which
    children occur"
    >>
    >>              - the schema does actually restrict the order of
    >> elements, <info> needs to be first, then the descriptors, then the
    >> references
    >>
    >> ** Invalid documents
    >>
    >> (I have not systematically tested examples with non-valid
    vocabulary
    >> URIs such as http://www.example. <http://www.example./>...)
    >>
    >> - http://www.w3.org/TR/emotion-voc/xml does not comply with
    assertion
    >> 110 (hence all examples that refer to vocabularies there also fail)
    >>
    >> - 2.3.3 The <info> element
    >>
    >>              - The last example of this section does not comply
    with
    >> assertion 212 since the name "neutral" does not belong to every-day
    >> categories
    >>
    >> - 5.1.1 Annotation of Text, "Annotation of text" Lewis Caroll
    example:
    >>
    >>              - In the <meta:doc> element, the character & is found,
    >> which does not pass XML validation, it should be &amp; (so does the
    >> example below)
    >>
    >>              - It also does not comply with assertion 212 since
    >> Disgust and Anger are not part of every-day categories
    >>
    >
    >
    >--
    >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
    >Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>


=




--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Kazuyuki Ashimura
Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?

On 12/16/2013 06:43 PM, Alexandre Denis wrote:
> Hello all,
> yes sure, but since I don't see the new specification, I can only trust
> you that the (small) mistakes are corrected. As for the schemas,

Thanks!

>>[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
> <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
>>[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml
> <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd
>
> The only difference I see with the schemas stored in our implementation
> is the required status of the version attribute of the <emotionml> tag,
> and it's possible I altered the schema myself because of the lack of the
> version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
> fix the version attribute on this document, otherwise every emotionml
> document referring to these vocabularies will fail to pass validation (I
> had to manually disable the corresponding assertion check in the code),

OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki


>
> best regards,
> Alexandre
>
>
>
>
> On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,
>
>     Thank you very much for your EmotionML implementations!  And I am very
>     sorry I did not respond to you earlier.  It seems my original message
>     did not go out due to some trouble.
>
>     As you know, there were the following two features which were not
>     explicitly listed on the EmotionML Implementation Report Plan [a].
>
>     ------------------------------__----------------------------
>     Two features not listed on the Implementation Report Plan:
>     ------------------------------__----------------------------
>     Feature1:
>        In Section 2.4.1 of the spec [b], there is a feature "The end value
>        MUST be greater than or equal to the start value", which is not
>        checked in the Implementation Report.
>
>     Feature2:
>        In Section 2.1.2 of the spec [b], there is a feature "a typical use
>        case is expected to be embedding an <emotion> into some other
>        markup", which is not checked in the Implementation Report.
>
>     However, according to the responses so far, we have already
>     got the following implementations for the above features.
>
>     ------------------------------__------------------
>     Implementation status of the above two features:
>     ------------------------------__------------------
>
>     Feature1: 3 implementations
>     - Gerhard Fobe:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
>     - Alexandre Denis:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
>     - Patrick Gebhard:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
>
>     Feature2: 4 implementations
>     - Gerhard Fobe:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
>     - Debbie Dahl:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html>
>     - Alexandre Denis:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
>     - Patrick Gebhard:
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
>
>     As I reported in October [c], we have already fixed typos in the spec
>     and added necessary clarifications to it.  Also we have fixed the
>     errors in the EmotionML schema.
>
>     So I would like to confirm that it is the time for us all to go ahead
>     and publish EmotionML as a W3C Recommendation.
>
>     Alexandre (as the original commenter), is that OK by you?
>
>     [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
>     <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
>     [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>     <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
>     [c]
>     http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>
>
>     Thanks,
>
>     Kazuyuki
>
>
>     On 11/08/2013 04:52 AM, Patrick Gebhard wrote:
>
>         Dear Felix,
>
>         I've updated ALMA (a DFKI EmotionML implementation) last October
>         in esp.
>         these two features, see attachment. Maybe my email got lost.
>
>         Anyway, Feature 1: pass, Feature 2: pass.
>
>         Best
>         Patrick
>
>         Am 07.11.2013 um 18:16 schrieb Marc Schröder
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>>:
>
>             Hi all,
>
>             DFKI's implementation has not-impl for both of these (unless
>             it has
>             been changed since I left).
>
>             Looking forward to seeing EmotionML become a Rec!
>
>             Best,
>             Marc
>
>
>             On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> wrote:
>
>                  Dear implementers of EmotionML
>                  To make a long story short: Alexandre Denis of Loria did a
>                  thorough review and implementation of EmotionML and
>             found several
>                  flaws that we managed to fix, now two issues are still
>             open and we
>                  need to know from you whether your implementation
>             supports two
>                  features, namely:
>                  >Feature1:
>                  >    In Section 2.4.1 of the sepc [1], there is a
>             feature "The end
>                  value
>                  >    MUST be greater than or equal to the start value",
>             which is not
>                  >    checked in the Implementation Report.
>                  >
>                  >Feature2:
>                  >    In Section 2.1.2 of the spec [1], there is a
>             feature "a
>                  typical use
>                  >    case is expected to be embedding an <emotion> into
>             some other
>                  >    markup", which is not checked in the
>             Implementation Report.
>
>                  Please respond to this mail until 25th of November and
>             state for
>                  both features whether it's "pass", "fail"  or "not-impl"
>                  Please send the answer to the public mailing list:
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>                  EmotionML will then soon become a real recommendation!
>
>                  Thanks a lot,
>                  Felix
>
>                  >-----Ursprüngliche Nachricht-----
>                  >Von: Kazuyuki Ashimura [mailto:[hidden email]
>             <mailto:[hidden email]>
>                  <mailto:[hidden email] <mailto:[hidden email]>>]
>                  >Gesendet: Montag, 28. Oktober 2013 07:57
>                  >An: [hidden email]
>             <mailto:[hidden email]>
>             <mailto:alexandre.denis@loria.__fr
>             <mailto:[hidden email]>>;
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>                  >Cc: Burkhardt, Felix; [hidden email]
>             <mailto:[hidden email]>
>                  <mailto:[hidden email]
>             <mailto:[hidden email]>>
>                  >Betreff: Re: AW: [EmotionML] implementation release
>             and feedbacks
>                  >
>                  >Dear Alexandre and EmotionML implementers,
>                  >
>                  >Thank you very much for implementing EmotionML, Alexandre!
>                  >Also your thorough review on the EmotionML [1]
>             specification and the
>                  >Implementation Report [2] is really appreciated.
>                  >
>                  >We are very sorry it took much longer to get consensus
>             about how
>                  to respond
>                  >to you and wrap-up the procedure [3] to publish
>             EmotionML as a W3C
>                  >Recommendation.
>                  >
>                  >We the W3C Multimodal Interaction Working Group have
>             already
>                  fixed typos
>                  >in the spec and added necessary clarifications to it.  In
>                  addition, we have
>                  >generated an updated version of the schema [5, 6].
>                  >
>                  >Now the remaining question is how to deal with your
>             comments on the
>                  >Implementation Report which wouldn't change the spec
>             itself.
>                  >
>                  >I talked within the W3C Team about what we should have
>             done from
>                  the W3C
>                  >Process viewpoint, and it seems we need to make sure
>             that there
>                  are enough
>                  >implementation experience for the following two
>             features which
>                  were not
>                  >explicitly described in the published Implementation
>             Report [2].
>                  >
>                  >Feature1:
>                  >    In Section 2.4.1 of the sepc [1], there is a
>             feature "The end
>                  value
>                  >    MUST be greater than or equal to the start value",
>             which is not
>                  >    checked in the Implementation Report.
>                  >
>                  >Feature2:
>                  >    In Section 2.1.2 of the spec [1], there is a
>             feature "a
>                  typical use
>                  >    case is expected to be embedding an <emotion> into
>             some other
>                  >    markup", which is not checked in the
>             Implementation Report.
>                  >
>                  >We have already checked with EmotionML implementers
>             (including
>                  you) and
>                  >it seems we can get several implementations for the
>             above two
>                  features as
>                  >well.
>                  >
>                  >Now we would like to ask all the EmotionML implementers to
>                  respond to this
>                  >message and express if the aobve features are
>             implmented so that
>                  we can
>                  >finalize the procedure and publish EmotionML as a W3C
>             Recommendation.
>                  >
>                  >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>             <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
>                  >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
>             <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
>                  >[3]
>             http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
>             <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
>                  >[4]
>             http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
>             <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
>                  >[5]
>             http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
>             <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
>                  >[6]
>             http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-
>             <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
>                  >fragments.xsd
>                  >
>                  >Sincerely,
>                  >
>                  >Kazuyuki Ashimura;
>                  >for the W3C Multimodal Interaction Working Group
>                  >
>                  >
>                  >
>                  >On 05/02/2013 07:00 PM, [hidden email]
>             <mailto:[hidden email]>
>                  <mailto:[hidden email]
>             <mailto:[hidden email]>> wrote:
>                  >> Congratulations, Alexandre
>                  >>
>                  >>  >Sorry to give you more work!
>                  >>
>                  >> Not at all, I'm indeed very happy you work with
>             EmotionML and
>                  grateful
>                  >> you do such a thorough job in revising it!
>                  >>
>                  >> It's just it'll take me/us some time to react on
>             this, sorry
>                  about this.
>                  >>
>                  >> Kind regards,
>                  >>
>                  >> Felix
>                  >>
>                  >> *Von:*Alexandre Denis
>             [mailto:alexandre.denis@loria.__fr
>             <mailto:[hidden email]>
>                  <mailto:alexandre.denis@loria.__fr
>             <mailto:[hidden email]>>]
>                  >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>                  >> *An:* [hidden email]
>             <mailto:[hidden email]> <mailto:[hidden email]
>             <mailto:[hidden email]>>__;
>                  Samuel CRUZ-LARA
>                  >> *Betreff:* [EmotionML] implementation release and
>             feedbacks
>                  >>
>                  >> Hello all,
>                  >>
>                  >> I'm happy to announce that we released the very
>             first version
>                  of our
>                  >> EmotionML Java implementation. It is hosted on
>             google code and
>                  >> released under the MIT license:
>                  >> https://code.google.com/p/__loria-synalp-emotionml/
>             <https://code.google.com/p/loria-synalp-emotionml/>
>                  >>
>                  >> It is still considered as an alpha version, we would
>             need some
>                  users
>                  >> to validate its use. And there is still some work on the
>                  documentation
>                  >> but the core of the code is there.
>                  >>
>                  >> If we could be listed as an implementation in the
>             next round of the
>                  >> implementation report it would be nice. Here is the
>             description:
>                  >>
>                  >> Alexandre Denis, LORIA laboratory, SYNALP team, France
>                  >>
>                  >> The LORIA/SYNALP implementation of EmotionML is a
>             Java standalone
>                  >> library developed in the context of the ITEA
>             Empathic Products
>                  project
>                  >> by the LORIA/SYNALP team. It enables to import Java
>             objects from
>                  >> EmotionML XML files and export them to EmotionML as
>             well. It
>                  >> guarantees standard compliance by performing a two
>             steps validation
>                  >> after all export operations and before all import
>             operations: first
>                  >> the EmotionML schema is tested, then all EmotionML
>             assertions are
>                  >> tested. If one or the other fails, an error message
>             is produced and
>                  >> the document cannot be imported or exported. The
>             library contains a
>                  >> corpus of badly formatted EmotionML files that
>             enables to
>                  double check
>                  >> if both the schema and the assertions manage to
>             correctly
>                  invalidate
>                  >> them. The API is hosted on google code
>                  >> (https://code.google.com/p/__loria-synalp-emotionml/
>             <https://code.google.com/p/loria-synalp-emotionml/>) and is
>                  released under
>                  >the MIT License.
>                  >>
>                  >> Moreover I don't come to you with empty hands, and I
>             have a
>                  bunch of
>                  >> remarks related to the EmotionML specification.
>             Sorry to give
>                  you more
>                  >work!
>                  >>
>                  >> best regards,
>                  >>
>                  >> Alexandre Denis
>                  >>
>                  >> *** Comments about EmotionML specification
>                  >>
>                  >> In what follows:
>                  >>
>                  >> - "specification" refers to the document at
>                  >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>             <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
>             of 16
>                  April
>                  >> 2013)
>                  >>
>                  >> - "assertions" refers to the list of assertions at
>                  >>
>             http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class
>             <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
>                  >>
>                  >> - "schema" refers to the schemas
>                  >> http://www.w3.org/TR/__emotionml/emotionml.xsd
>             <http://www.w3.org/TR/emotionml/emotionml.xsd> and
>                  >>
>             http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd
>             <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
>                  >>
>                  >> ** Specification clarification questions
>                  >>
>                  >> - About relative and absolute timing ?
>                  >>
>                  >>              - Is that possible to mix relative and
>             absolute
>                  timing ?
>                  >> Intuitively this would seem weird but nothing in the
>                  >>
>                  >>              specification prevents it.
>                  >>
>                  >> - About consistency of start/end/duration ?
>                  >>
>                  >>              - I think the specification does not
>             enforce the
>                  >> consistency of start, end and duration which are
>                  >>
>                  >>              possible alltogether. Hence it is
>             possible to have
>                  >> inconsistent triplets (start=0, end=5, duration=10).
>                  >>
>                  >> - About text nodes ?
>                  >>
>                  >>              - the emotion element can have text nodes
>                  children, it is
>                  >> not specified how many. Is it possible to
>             intersperse text
>                  nodes all
>                  >> over
>                  >>
>                  >>              an emotion element ? The fact that an
>             emotion
>                  element can
>                  >> have text children is not specified in its children
>             list.
>                  >>
>                  >> - About emotion children combinations ?
>                  >>
>                  >>              - the specification states "There are no
>                  constraints on
>                  >> the combinations of children that are allowed.", it
>             is maybe
>                  confusing
>                  >> since
>                  >>
>                  >>              an emotion cannot contain two
>             categories that
>                  belong to
>                  >> different category-sets or two categories with the
>             same name.
>                  >>
>                  >> - About default values ?
>                  >>
>                  >>              - some attributes have default values
>             (reference role,
>                  >> time ref anchor point, duration, etc.), is it
>             desirable to have a
>                  >> default
>                  >>
>                  >>              value also for other attributes,
>             especially for
>                  the "value"
>                  >> attribute ? For instance, how would you compare
>             <category
>                  >> name="surprise"/>
>                  >>
>                  >>              and <category name="surprise"
>             value="1.0"/> ? Are they
>                  >> semantically equivalent ? A similar question could
>             be made
>                  about the
>                  >> "confidence"
>                  >>
>                  >>              attribute, how would you compare <category
>                  >> name="surprise"/> and <category name="surprise"
>                  confidence="1.0"/> ?
>                  >>
>                  >> - About the number of <trace> ?
>                  >>
>                  >>              - the specification does not state
>             clearly if it is
>                  >> possible to have several <trace> elements inside a
>             descriptor,
>                  it is
>                  >> stated
>                  >>
>                  >>              "a <trace> element". Maybe it should be
>             stated "If
>                  >> present the following child element can occur one or
>             more time:
>                  <trace>".
>                  >>
>                  >>              The schema allows that. If this comment is
>                  accepted, the
>                  >> assertions 215, 224, 235, 245 should also be clarified.
>                  >>
>                  >> - About conformance ?
>                  >>
>                  >>              - In section 4.3, it is stated "It is the
>                  responsibility
>                  >> of an EmotionML processor to verify that the use of
>             descriptor
>                  names
>                  >> and values
>                  >>
>                  >>              is consistent with the vocabulary
>             definition",
>                  which is
>                  >> true but incomplete with regards to the assertions,
>                  >>
>                  >>              maybe it would be beneficial to specify
>             all the
>                  >> assertions that are not under the schema
>             responsability but
>                  rather the
>                  >> EmotionML processor
>                  >>
>                  >>              (see below) or at least warn that there
>             are many
>                  >> assertions not checked by the schema.
>                  >>
>                  >> ** Discrepancies between
>             schema/assertions/__specification
>                  >>
>                  >> - Assertions not tested by the schema
>                  >>
>                  >>              - I found that the following assertions
>             are not
>                  tested by
>                  >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
>             172, 210, 212,
>                  >>
>                  >>              216, 220, 222, 224, 230, 232, 236, 240,
>             242, 246,
>                  410, 417.
>                  >>
>                  >>              There are assertions that are
>             impossible to test
>                  with a
>                  >> XSD schema I think:
>                  >>
>                  >>                          114, 117, 120, 123, 161,
>             164, 167, 170 :
>                  >> vocabulary set id and type checking
>                  >>
>                  >>                          212, 222, 232, 242 :
>             vocabulary name
>                  >> membership
>                  >>
>                  >>                          417 : media type (unless
>             enumerating them)
>                  >>
>                  >>              Some may be possible with some tweaking:
>                  >>
>                  >>                          210, 220, 230, 240 :
>             vocabulary set
>                  presence
>                  >>
>                  >>                          216, 224, 236, 246 :
>             <trace> and "value"
>                  >>
>                  >>              There are two "true" errors I think:
>                  >>
>                  >>                          172 : The "version"
>             attribute of
>                  <emotion>,
>                  >> if present, MUST have the  value "1.0"
>                  >>
>                  >>                                      I think it
>             should not be
>                  >> "optional with default value 1.0" but rather
>             "optional with
>                  fixed value 1.0"
>                  >>
>                  >>                          410 : The <reference>
>             element MUST
>                  contain a
>                  >> "uri" attribute
>                  >>
>                  >>                                      the "uri"
>             attribute is
>                  optional
>                  >> by default in the schema
>                  >>
>                  >> - 2.4.1, "The end value MUST be greater than or
>             equal to the start
>                  >> value",
>                  >>
>                  >>              - the schema does not check it and
>             there is no
>                  assertion
>                  >> enforcing it
>                  >>
>                  >> - 2.1.2, "a typical use case is expected to be
>             embedding an
>                  <emotion>
>                  >> into some other markup",
>                  >>
>                  >>              - there is no assertion that describe that
>                  <emotion> may
>                  >> be embedded in another markup, does it imply we
>             could embed other
>                  >elements ?
>                  >>
>                  >>              - is a document containing a sole
>             <emotion> a valid
>                  >> document (not in the sense of <emotionml> document)
>             ? If yes,
>                  maybe an
>                  >> assertion clarifiying the use of <emotion> would be
>             useful.
>                  >>
>                  >> - assertions 105, 155, 601, 606, status "Req=N"
>                  >>
>                  >>              - the assertions mix the presence of
>             <info> and the
>                  >> number of <info> elements, while the presence is not
>                  restricted, the
>                  >> number
>                  >>
>                  >>              MUST be 0 or 1, hence the required
>             status wrt this
>                  part
>                  >> of assertions should be "Req=Y"
>                  >>
>                  >> - 2.1.2, "There are no constraints on the order in which
>                  children occur"
>                  >>
>                  >>              - the schema does actually restrict the
>             order of
>                  >> elements, <info> needs to be first, then the
>             descriptors, then the
>                  >> references
>                  >>
>                  >> ** Invalid documents
>                  >>
>                  >> (I have not systematically tested examples with
>             non-valid
>                  vocabulary
>                  >> URIs such as http://www.example.
>             <http://www.example./>...)
>                  >>
>                  >> - http://www.w3.org/TR/emotion-__voc/xml
>             <http://www.w3.org/TR/emotion-voc/xml> does not comply with
>                  assertion
>                  >> 110 (hence all examples that refer to vocabularies
>             there also fail)
>                  >>
>                  >> - 2.3.3 The <info> element
>                  >>
>                  >>              - The last example of this section does
>             not comply
>                  with
>                  >> assertion 212 since the name "neutral" does not
>             belong to every-day
>                  >> categories
>                  >>
>                  >> - 5.1.1 Annotation of Text, "Annotation of text"
>             Lewis Caroll
>                  example:
>                  >>
>                  >>              - In the <meta:doc> element, the
>             character & is found,
>                  >> which does not pass XML validation, it should be
>             &amp; (so does the
>                  >> example below)
>                  >>
>                  >>              - It also does not comply with
>             assertion 212 since
>                  >> Disgust and Anger are not part of every-day categories
>                  >>
>                  >
>                  >
>                  >--
>                  >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>                  >Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
>             <tel:%2B81%20466%2049%201170>
>
>
>         =
>
>
>
>
>     --
>     Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>     Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
>
>

--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
Tel: +81 466 49 1170

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Kazuyuki Ashimura
Hi Alexandre,

Sorry for the delay.

We've fixed the issues on the schema file and the EmotionML vocabulary
file, and would like to publish the EmotionML spec as a REC along with
the updated EmotionML Vocabulary Note.

FYI, we added the following changes to the Schema file for the
EmotionML spec:

- Replaced "sequence" with "choice" for the <emotion> element in lines
  91 and 95.

- Changed the "default" to "fixed" for "1.0" in the version attribute
  of <emotion> element in line 96.

- Added [[use="required"]] to the "uri" attribute of the <reference>
  element in line 32.

Please see attached "emotionml-fragments.xsd".

Also we added version information to the EmotionML vocabulary file.
Please see attached "xml.emotionml".

Thanks,

Kazuyuki


On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:
Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?


On 12/16/2013 06:43 PM, Alexandre Denis wrote:
Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd


The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),

OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki



best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------

    Two features not listed on the Implementation Report Plan:
    ------------------------------__----------------------------

    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------

    Implementation status of the above two features:
    ------------------------------__------------------


    Feature1: 3 implementations
    - Gerhard Fobe:
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email]__gmail.com

        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>
            <mailto:[hidden email]__telekom.de

            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>


                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>
            <mailto:[hidden email]__fr

            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>

                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email]__loria.fr

            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >
                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-

            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email]__telekom.de

            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis
            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr

            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]
            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;

                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:
                 >> https://code.google.com/p/__loria-synalp-emotionml/

            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code
                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is

                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at
                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/

            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>
            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class

            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas
                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd

            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between
            schema/assertions/__specification

                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>
                 >> - http://www.w3.org/TR/emotion-__voc/xml

            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
            <tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
    Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>



--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice

Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170



--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170


emotionml-fragments.xsd (8K) Download Attachment
xml.emotionml (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Alexandre Denis
Hello Kazuyuki,
thanks for the update. Please note that assertion 156 is not tested anymore (The <emotion> element MUST contain at least one <category> or <dimension> or <appraisal> or <action-tendency> element). I think this is because of the <choice> which now seems to accept empty emotions. This could be caused by the interaction between <choice> and children minOccurs=0, it could also be a problem with the implementation I'm using. Could you please test the new schema on the given file with your own validator ? Otherwise it's fine, previous assertions that were not tested are now tested (172, 410 and 417),
best regards,
Alexandre





On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]> wrote:
Hi Alexandre,

Sorry for the delay.

We've fixed the issues on the schema file and the EmotionML vocabulary
file, and would like to publish the EmotionML spec as a REC along with
the updated EmotionML Vocabulary Note.

FYI, we added the following changes to the Schema file for the
EmotionML spec:

- Replaced "sequence" with "choice" for the <emotion> element in lines
  91 and 95.

- Changed the "default" to "fixed" for "1.0" in the version attribute
  of <emotion> element in line 96.

- Added [[use="required"]] to the "uri" attribute of the <reference>
  element in line 32.

Please see attached "emotionml-fragments.xsd".

Also we added version information to the EmotionML vocabulary file.
Please see attached "xml.emotionml".

Thanks,

Kazuyuki


On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:
Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?


On 12/16/2013 06:43 PM, Alexandre Denis wrote:
Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd


The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),

OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki



best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------

    Two features not listed on the Implementation Report Plan:
    ------------------------------__----------------------------

    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------

    Implementation status of the above two features:
    ------------------------------__------------------


    Feature1: 3 implementations
    - Gerhard Fobe:
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html     http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html

    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>
        <mailto:[hidden email]__gmail.com

        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>
            <mailto:[hidden email]__telekom.de

            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>


                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>
            <mailto:[hidden email]__fr

            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>
            <mailto:[hidden email] <mailto:[hidden email]>>

                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email]__loria.fr

            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >
                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-

            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email]__telekom.de

            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis
            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr

            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]
            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;

                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:
                 >> https://code.google.com/p/__loria-synalp-emotionml/

            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code
                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is

                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at
                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/

            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>
            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class

            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas
                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd

            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between
            schema/assertions/__specification

                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>
                 >> - http://www.w3.org/TR/emotion-__voc/xml

            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
            <tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
    Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>



--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice

Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170



--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170



fail_156.xml (134 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

AW: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Felix.Burkhardt

Hi all

If I try to validate Alexandre’s file with the free Notepad++ editor

I get

Validation of current file using XML schema:

 

ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion': Missing child element(s). Expected is one of ( {http://www.w3.org/2009/10/emotionml}info, {http://www.w3.org/2009/10/emotionml}category, {http://www.w3.org/2009/10/emotionml}dimension, {http://www.w3.org/2009/10/emotionml}appraisal, {http://www.w3.org/2009/10/emotionml}action-tendency ).

 

Which is just what should happen.

So it seems the xsd works with this respect,

perhaps Alexandre’s implementation has really a problem here?

 

Cheers,

Felix

 

 

Von: Alexandre Denis [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 11:53
An: Kazuyuki Ashimura
Cc: Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie; Deborah Dahl; [hidden email]; Edmon Begoli; [hidden email] ([hidden email]); [hidden email]; Tim Llewellynn; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hello Kazuyuki,

thanks for the update. Please note that assertion 156 is not tested anymore (The <emotion> element MUST contain at least one <category> or <dimension> or <appraisal> or <action-tendency> element). I think this is because of the <choice> which now seems to accept empty emotions. This could be caused by the interaction between <choice> and children minOccurs=0, it could also be a problem with the implementation I'm using. Could you please test the new schema on the given file with your own validator ? Otherwise it's fine, previous assertions that were not tested are now tested (172, 410 and 417),

best regards,

Alexandre

 

 

 

 

On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

 

Sorry for the delay.

 

We've fixed the issues on the schema file and the EmotionML vocabulary

file, and would like to publish the EmotionML spec as a REC along with

the updated EmotionML Vocabulary Note.

 

FYI, we added the following changes to the Schema file for the

EmotionML spec:

 

- Replaced "sequence" with "choice" for the <emotion> element in lines

  91 and 95.

 

- Changed the "default" to "fixed" for "1.0" in the version attribute

  of <emotion> element in line 96.

 

- Added [[use="required"]] to the "uri" attribute of the <reference>

  element in line 32.

 

Please see attached "emotionml-fragments.xsd".

 

Also we added version information to the EmotionML vocabulary file.

Please see attached "xml.emotionml".

 

Thanks,

 

Kazuyuki

 

 

On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?



On 12/16/2013 06:43 PM, Alexandre Denis wrote:

Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

 

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>

[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd



The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),


OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki


best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]

<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------


    Two features not listed on the Implementation Report Plan:

    ------------------------------__----------------------------


    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------


    Implementation status of the above two features:

    ------------------------------__------------------



    Feature1: 3 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email]__gmail.com


        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>



                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__fr


            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>


                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__loria.fr


            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >

                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis

            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr


            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]

            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;


                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:

                 >> https://code.google.com/p/__loria-synalp-emotionml/


            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code

                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is


                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at

                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>

            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class


            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas

                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd


            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between

            schema/assertions/__specification


                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>

                 >> - http://www.w3.org/TR/emotion-__voc/xml


            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170">tel:%2B81%20466%2049%201170>
            <<a href="tel:%2B81%20466%2049%201170">tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice

    Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170">tel:%2B81%20466%2049%201170>


--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice


Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170



 

--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170

 

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Alexandre Denis
Hi Felix,
thanks for the feedback, please note that I used the Kazuyuki version (I'm not sure what do you refer to with "current file"). I'm actually using the validation API of Java (jdk1.7.0_51). There might be indeed something wrong with it or with my use of it. 

I cannot test with Notepad++ (I'm on Mac). However, when testing with an online validator, the fail_156.xml file passes validation with the new xsd: 

The XSD on the right merges:
- the emotionml-fragments.xsd sent by Kazuyuki

Nevertheless, when testing the same fail_156.xml with the schemas available on the EmotionML page:

It does not pass the validation as expected with the same result that you have (so that's why I'm not sure of which schema you used).
The XSD on the right merges:

Are you able to reproduce these results? Maybe I just did something wrong,
best regards,
Alex








On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]> wrote:

Hi all

If I try to validate Alexandre’s file with the free Notepad++ editor

I get

Validation of current file using XML schema:

 

ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion': Missing child element(s). Expected is one of ( {http://www.w3.org/2009/10/emotionml}info, {http://www.w3.org/2009/10/emotionml}category, {http://www.w3.org/2009/10/emotionml}dimension, {http://www.w3.org/2009/10/emotionml}appraisal, {http://www.w3.org/2009/10/emotionml}action-tendency ).

 

Which is just what should happen.

So it seems the xsd works with this respect,

perhaps Alexandre’s implementation has really a problem here?

 

Cheers,

Felix

 

 

Von: Alexandre Denis [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 11:53
An: Kazuyuki Ashimura
Cc: Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie; Deborah Dahl; [hidden email]; Edmon Begoli; [hidden email] ([hidden email]); [hidden email]; Tim Llewellynn; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hello Kazuyuki,

thanks for the update. Please note that assertion 156 is not tested anymore (The <emotion> element MUST contain at least one <category> or <dimension> or <appraisal> or <action-tendency> element). I think this is because of the <choice> which now seems to accept empty emotions. This could be caused by the interaction between <choice> and children minOccurs=0, it could also be a problem with the implementation I'm using. Could you please test the new schema on the given file with your own validator ? Otherwise it's fine, previous assertions that were not tested are now tested (172, 410 and 417),

best regards,

Alexandre

 

 

 

 

On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

 

Sorry for the delay.

 

We've fixed the issues on the schema file and the EmotionML vocabulary

file, and would like to publish the EmotionML spec as a REC along with

the updated EmotionML Vocabulary Note.

 

FYI, we added the following changes to the Schema file for the

EmotionML spec:

 

- Replaced "sequence" with "choice" for the <emotion> element in lines

  91 and 95.

 

- Changed the "default" to "fixed" for "1.0" in the version attribute

  of <emotion> element in line 96.

 

- Added [[use="required"]] to the "uri" attribute of the <reference>

  element in line 32.

 

Please see attached "emotionml-fragments.xsd".

 

Also we added version information to the EmotionML vocabulary file.

Please see attached "xml.emotionml".

 

Thanks,

 

Kazuyuki

 

 

On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?



On 12/16/2013 06:43 PM, Alexandre Denis wrote:

Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

 

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>

[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd



The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),


OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki


best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]

<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------


    Two features not listed on the Implementation Report Plan:

    ------------------------------__----------------------------


    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------


    Implementation status of the above two features:

    ------------------------------__------------------



    Feature1: 3 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email]__gmail.com


        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>



                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__fr


            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>


                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__loria.fr


            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >

                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis

            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr


            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]

            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;


                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:

                 >> https://code.google.com/p/__loria-synalp-emotionml/


            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code

                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is


                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at

                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>

            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class


            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas

                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd


            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between

            schema/assertions/__specification


                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>

                 >> - http://www.w3.org/TR/emotion-__voc/xml


            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>
            <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice

    Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice


Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170



 

--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170

 


Reply | Threaded
Open this post in threaded view
|

AW: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Felix.Burkhardt

Very sorry, Alexandre, you’re right, I mixed up the files and used the old version.

 

I did some testing and it seems you’re right again, the problem seems that , in a choice, if one element has minOccurs=0 this goes for all elements, even if minOccurs=1 is stated, a behavior I find very unexpected.

We have to find a solution if this can be stated at all in XML schema.

To state the problem once more (as I understood it):

We need to find a possibility to enforce

-          That an element has children

-          Some are optional, at most once

-          A Group of elements is required (one of them at least once)

-          The order is not restricted.

 

If we cannot state this, assertion 156 cannot be tested by automatic Schema validation.

Regards,

Felix

 

 

 

 

 

 

 

Von: Alexandre Denis [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 15:21
An: Burkhardt, Felix
Cc: Kazuyuki Ashimura; Deborah Dahl; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hi Felix,

thanks for the feedback, please note that I used the Kazuyuki version (I'm not sure what do you refer to with "current file"). I'm actually using the validation API of Java (jdk1.7.0_51). There might be indeed something wrong with it or with my use of it. 

 

I cannot test with Notepad++ (I'm on Mac). However, when testing with an online validator, the fail_156.xml file passes validation with the new xsd: 

 

The XSD on the right merges:

- the emotionml-fragments.xsd sent by Kazuyuki

 

Nevertheless, when testing the same fail_156.xml with the schemas available on the EmotionML page:

 

It does not pass the validation as expected with the same result that you have (so that's why I'm not sure of which schema you used).
The XSD on the right merges:

 

Are you able to reproduce these results? Maybe I just did something wrong,

best regards,

Alex

 

 

 

 

 

 

 

On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]> wrote:

Hi all

If I try to validate Alexandre’s file with the free Notepad++ editor

I get

Validation of current file using XML schema:

 

ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion': Missing child element(s). Expected is one of ( {http://www.w3.org/2009/10/emotionml}info, {http://www.w3.org/2009/10/emotionml}category, {http://www.w3.org/2009/10/emotionml}dimension, {http://www.w3.org/2009/10/emotionml}appraisal, {http://www.w3.org/2009/10/emotionml}action-tendency ).

 

Which is just what should happen.

So it seems the xsd works with this respect,

perhaps Alexandre’s implementation has really a problem here?

 

Cheers,

Felix

 

 

Von: Alexandre Denis [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 11:53
An: Kazuyuki Ashimura
Cc: Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie; Deborah Dahl; [hidden email]; Edmon Begoli; [hidden email] ([hidden email]); [hidden email]; Tim Llewellynn; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hello Kazuyuki,

thanks for the update. Please note that assertion 156 is not tested anymore (The <emotion> element MUST contain at least one <category> or <dimension> or <appraisal> or <action-tendency> element). I think this is because of the <choice> which now seems to accept empty emotions. This could be caused by the interaction between <choice> and children minOccurs=0, it could also be a problem with the implementation I'm using. Could you please test the new schema on the given file with your own validator ? Otherwise it's fine, previous assertions that were not tested are now tested (172, 410 and 417),

best regards,

Alexandre

 

 

 

 

On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

 

Sorry for the delay.

 

We've fixed the issues on the schema file and the EmotionML vocabulary

file, and would like to publish the EmotionML spec as a REC along with

the updated EmotionML Vocabulary Note.

 

FYI, we added the following changes to the Schema file for the

EmotionML spec:

 

- Replaced "sequence" with "choice" for the <emotion> element in lines

  91 and 95.

 

- Changed the "default" to "fixed" for "1.0" in the version attribute

  of <emotion> element in line 96.

 

- Added [[use="required"]] to the "uri" attribute of the <reference>

  element in line 32.

 

Please see attached "emotionml-fragments.xsd".

 

Also we added version information to the EmotionML vocabulary file.

Please see attached "xml.emotionml".

 

Thanks,

 

Kazuyuki

 

 

On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?



On 12/16/2013 06:43 PM, Alexandre Denis wrote:

Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

 

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>

[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd



The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),


OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki


best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]

<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------


    Two features not listed on the Implementation Report Plan:

    ------------------------------__----------------------------


    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------


    Implementation status of the above two features:

    ------------------------------__------------------



    Feature1: 3 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email]__gmail.com


        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>



                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__fr


            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>


                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__loria.fr


            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >

                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis

            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr


            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]

            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;


                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:

                 >> https://code.google.com/p/__loria-synalp-emotionml/


            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code

                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is


                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at

                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>

            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class


            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas

                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd


            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between

            schema/assertions/__specification


                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>

                 >> - http://www.w3.org/TR/emotion-__voc/xml


            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>
            <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice

    Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice


Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170



 

--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170

 

 

Reply | Threaded
Open this post in threaded view
|

RE: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Deborah Dahl

Hi Felix,

Thanks for your succinct summary of the constraints on an XML Schema based approach to describing this feature.

If there is a Schema-based approach, then of course it would be good to describe the feature in the Schema, but features of a W3C specification are required to be describable  in a Schema. The text of the specification defines the language, not the Schema. So we should not spend a huge amount of time trying to make the Schema describe this feature.

Best regards,

Debbie

 

From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, February 19, 2014 10:06 AM
To: [hidden email]
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: AW: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Very sorry, Alexandre, you’re right, I mixed up the files and used the old version.

 

I did some testing and it seems you’re right again, the problem seems that , in a choice, if one element has minOccurs=0 this goes for all elements, even if minOccurs=1 is stated, a behavior I find very unexpected.

We have to find a solution if this can be stated at all in XML schema.

To state the problem once more (as I understood it):

We need to find a possibility to enforce

-          That an element has children

-          Some are optional, at most once

-          A Group of elements is required (one of them at least once)

-          The order is not restricted.

 

If we cannot state this, assertion 156 cannot be tested by automatic Schema validation.

Regards,

Felix

 

 

 

 

 

 

 

Von: Alexandre Denis [[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 15:21
An: Burkhardt, Felix
Cc: Kazuyuki Ashimura; Deborah Dahl; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hi Felix,

thanks for the feedback, please note that I used the Kazuyuki version (I'm not sure what do you refer to with "current file"). I'm actually using the validation API of Java (jdk1.7.0_51). There might be indeed something wrong with it or with my use of it. 

 

I cannot test with Notepad++ (I'm on Mac). However, when testing with an online validator, the fail_156.xml file passes validation with the new xsd: 

 

The XSD on the right merges:

- the emotionml-fragments.xsd sent by Kazuyuki

 

Nevertheless, when testing the same fail_156.xml with the schemas available on the EmotionML page:

 

It does not pass the validation as expected with the same result that you have (so that's why I'm not sure of which schema you used).
The XSD on the right merges:

 

Are you able to reproduce these results? Maybe I just did something wrong,

best regards,

Alex

 

 

 

 

 

 

 

On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]> wrote:

Hi all

If I try to validate Alexandre’s file with the free Notepad++ editor

I get

Validation of current file using XML schema:

 

ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion': Missing child element(s). Expected is one of ( {http://www.w3.org/2009/10/emotionml}info, {http://www.w3.org/2009/10/emotionml}category, {http://www.w3.org/2009/10/emotionml}dimension, {http://www.w3.org/2009/10/emotionml}appraisal, {http://www.w3.org/2009/10/emotionml}action-tendency ).

 

Which is just what should happen.

So it seems the xsd works with this respect,

perhaps Alexandre’s implementation has really a problem here?

 

Cheers,

Felix

 

 

Von: Alexandre Denis [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Februar 2014 11:53
An: Kazuyuki Ashimura
Cc: Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie; Deborah Dahl; [hidden email]; Edmon Begoli; [hidden email] ([hidden email]); [hidden email]; Tim Llewellynn; [hidden email]
Betreff: Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

 

Hello Kazuyuki,

thanks for the update. Please note that assertion 156 is not tested anymore (The <emotion> element MUST contain at least one <category> or <dimension> or <appraisal> or <action-tendency> element). I think this is because of the <choice> which now seems to accept empty emotions. This could be caused by the interaction between <choice> and children minOccurs=0, it could also be a problem with the implementation I'm using. Could you please test the new schema on the given file with your own validator ? Otherwise it's fine, previous assertions that were not tested are now tested (172, 410 and 417),

best regards,

Alexandre

 

 

 

 

On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

 

Sorry for the delay.

 

We've fixed the issues on the schema file and the EmotionML vocabulary

file, and would like to publish the EmotionML spec as a REC along with

the updated EmotionML Vocabulary Note.

 

FYI, we added the following changes to the Schema file for the

EmotionML spec:

 

- Replaced "sequence" with "choice" for the <emotion> element in lines

  91 and 95.

 

- Changed the "default" to "fixed" for "1.0" in the version attribute

  of <emotion> element in line 96.

 

- Added [[use="required"]] to the "uri" attribute of the <reference>

  element in line 32.

 

Please see attached "emotionml-fragments.xsd".

 

Also we added version information to the EmotionML vocabulary file.

Please see attached "xml.emotionml".

 

Thanks,

 

Kazuyuki

 

 

On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]> wrote:

Hi Alexandre,

Happy New Year!  And very sorry for the big delay.
I have been travelling (business travels :) for a while.

Could you please see inline below?



On 12/16/2013 06:43 PM, Alexandre Denis wrote:

Hello all,
yes sure, but since I don't see the new specification, I can only trust
you that the (small) mistakes are corrected. As for the schemas,

 

Thanks!

[5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>

[6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml

<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd



The only difference I see with the schemas stored in our implementation
is the required status of the version attribute of the <emotionml> tag,
and it's possible I altered the schema myself because of the lack of the
version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
fix the version attribute on this document, otherwise every emotionml
document referring to these vocabularies will fail to pass validation (I
had to manually disable the corresponding assertion check in the code),


OK.  We'll see the detail of the problem and fix the issue of
version handling.

Thanks!

Kazuyuki


best regards,
Alexandre




On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]

<mailto:[hidden email]>> wrote:

    Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,

    Thank you very much for your EmotionML implementations!  And I am very
    sorry I did not respond to you earlier.  It seems my original message
    did not go out due to some trouble.

    As you know, there were the following two features which were not
    explicitly listed on the EmotionML Implementation Report Plan [a].

    ------------------------------__----------------------------


    Two features not listed on the Implementation Report Plan:

    ------------------------------__----------------------------


    Feature1:
       In Section 2.4.1 of the spec [b], there is a feature "The end value
       MUST be greater than or equal to the start value", which is not
       checked in the Implementation Report.

    Feature2:
       In Section 2.1.2 of the spec [b], there is a feature "a typical use
       case is expected to be embedding an <emotion> into some other
       markup", which is not checked in the Implementation Report.

    However, according to the responses so far, we have already
    got the following implementations for the above features.

    ------------------------------__------------------


    Implementation status of the above two features:

    ------------------------------__------------------



    Feature1: 3 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    Feature2: 4 implementations
    - Gerhard Fobe:

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html

    http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>

    As I reported in October [c], we have already fixed typos in the spec
    and added necessary clarifications to it.  Also we have fixed the
    errors in the EmotionML schema.

    So I would like to confirm that it is the time for us all to go ahead
    and publish EmotionML as a W3C Recommendation.

    Alexandre (as the original commenter), is that OK by you?

    [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
    <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
    [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
    <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
    [c]
    http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html


    <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>

    Thanks,

    Kazuyuki


    On 11/08/2013 04:52 AM, Patrick Gebhard wrote:

        Dear Felix,

        I've updated ALMA (a DFKI EmotionML implementation) last October
        in esp.
        these two features, see attachment. Maybe my email got lost.

        Anyway, Feature 1: pass, Feature 2: pass.

        Best
        Patrick

        Am 07.11.2013 um 18:16 schrieb Marc Schröder
        <[hidden email] <mailto:[hidden email]>

        <mailto:[hidden email]__gmail.com


        <mailto:[hidden email]>>>:

            Hi all,

            DFKI's implementation has not-impl for both of these (unless
            it has
            been changed since I left).

            Looking forward to seeing EmotionML become a Rec!

            Best,
            Marc


            On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>>> wrote:

                 Dear implementers of EmotionML
                 To make a long story short: Alexandre Denis of Loria did a
                 thorough review and implementation of EmotionML and
            found several
                 flaws that we managed to fix, now two issues are still
            open and we
                 need to know from you whether your implementation
            supports two
                 features, namely:
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.

                 Please respond to this mail until 25th of November and
            state for
                 both features whether it's "pass", "fail"  or "not-impl"
                 Please send the answer to the public mailing list:
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>



                 EmotionML will then soon become a real recommendation!

                 Thanks a lot,
                 Felix

                 >-----Ursprüngliche Nachricht-----
                 >Von: Kazuyuki Ashimura [mailto:[hidden email]
            <mailto:[hidden email]>
                 <mailto:[hidden email] <mailto:[hidden email]>>]
                 >Gesendet: Montag, 28. Oktober 2013 07:57
                 >An: [hidden email]
            <mailto:[hidden email]>

            <mailto:[hidden email]__fr


            <mailto:[hidden email]>>;
            [hidden email] <mailto:[hidden email]>

            <mailto:[hidden email] <mailto:[hidden email]>>


                 >Cc: Burkhardt, Felix; [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__loria.fr


            <mailto:[hidden email]>>
                 >Betreff: Re: AW: [EmotionML] implementation release
            and feedbacks
                 >
                 >Dear Alexandre and EmotionML implementers,
                 >
                 >Thank you very much for implementing EmotionML, Alexandre!
                 >Also your thorough review on the EmotionML [1]
            specification and the
                 >Implementation Report [2] is really appreciated.
                 >
                 >We are very sorry it took much longer to get consensus
            about how
                 to respond
                 >to you and wrap-up the procedure [3] to publish
            EmotionML as a W3C
                 >Recommendation.
                 >
                 >We the W3C Multimodal Interaction Working Group have
            already
                 fixed typos
                 >in the spec and added necessary clarifications to it.  In
                 addition, we have
                 >generated an updated version of the schema [5, 6].
                 >
                 >Now the remaining question is how to deal with your
            comments on the
                 >Implementation Report which wouldn't change the spec
            itself.
                 >
                 >I talked within the W3C Team about what we should have
            done from
                 the W3C
                 >Process viewpoint, and it seems we need to make sure
            that there
                 are enough
                 >implementation experience for the following two
            features which
                 were not
                 >explicitly described in the published Implementation
            Report [2].
                 >
                 >Feature1:
                 >    In Section 2.4.1 of the sepc [1], there is a
            feature "The end
                 value
                 >    MUST be greater than or equal to the start value",
            which is not
                 >    checked in the Implementation Report.
                 >
                 >Feature2:
                 >    In Section 2.1.2 of the spec [1], there is a
            feature "a
                 typical use
                 >    case is expected to be embedding an <emotion> into
            some other
                 >    markup", which is not checked in the
            Implementation Report.
                 >
                 >We have already checked with EmotionML implementers
            (including
                 you) and
                 >it seems we can get several implementations for the
            above two
                 features as
                 >well.
                 >
                 >Now we would like to ask all the EmotionML implementers to
                 respond to this
                 >message and express if the aobve features are
            implmented so that
                 we can
                 >finalize the procedure and publish EmotionML as a W3C
            Recommendation.
                 >

                 >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
                 >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
            <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
                 >[3]
            http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
            <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
                 >[4]
            http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
            <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
                 >[5]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
                 >[6]
            http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
                 >fragments.xsd
                 >
                 >Sincerely,
                 >
                 >Kazuyuki Ashimura;
                 >for the W3C Multimodal Interaction Working Group
                 >
                 >
                 >
                 >On 05/02/2013 07:00 PM, [hidden email]
            <mailto:[hidden email]>

                 <mailto:[hidden email]__telekom.de


            <mailto:[hidden email]>> wrote:
                 >> Congratulations, Alexandre
                 >>
                 >>  >Sorry to give you more work!
                 >>
                 >> Not at all, I'm indeed very happy you work with
            EmotionML and
                 grateful
                 >> you do such a thorough job in revising it!
                 >>
                 >> It's just it'll take me/us some time to react on
            this, sorry
                 about this.
                 >>
                 >> Kind regards,
                 >>
                 >> Felix
                 >>
                 >> *Von:*Alexandre Denis

            [mailto:[hidden email]__fr
            <mailto:[hidden email]>
                 <mailto:[hidden email]__fr


            <mailto:[hidden email]>>]
                 >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
                 >> *An:* [hidden email]

            <mailto:[hidden email]> <mailto:[hidden email]
            <mailto:[hidden email]>>__;


                 Samuel CRUZ-LARA
                 >> *Betreff:* [EmotionML] implementation release and
            feedbacks
                 >>
                 >> Hello all,
                 >>
                 >> I'm happy to announce that we released the very
            first version
                 of our
                 >> EmotionML Java implementation. It is hosted on
            google code and
                 >> released under the MIT license:

                 >> https://code.google.com/p/__loria-synalp-emotionml/


            <https://code.google.com/p/loria-synalp-emotionml/>
                 >>
                 >> It is still considered as an alpha version, we would
            need some
                 users
                 >> to validate its use. And there is still some work on the
                 documentation
                 >> but the core of the code is there.
                 >>
                 >> If we could be listed as an implementation in the
            next round of the
                 >> implementation report it would be nice. Here is the
            description:
                 >>
                 >> Alexandre Denis, LORIA laboratory, SYNALP team, France
                 >>
                 >> The LORIA/SYNALP implementation of EmotionML is a
            Java standalone
                 >> library developed in the context of the ITEA
            Empathic Products
                 project
                 >> by the LORIA/SYNALP team. It enables to import Java
            objects from
                 >> EmotionML XML files and export them to EmotionML as
            well. It
                 >> guarantees standard compliance by performing a two
            steps validation
                 >> after all export operations and before all import
            operations: first
                 >> the EmotionML schema is tested, then all EmotionML
            assertions are
                 >> tested. If one or the other fails, an error message
            is produced and
                 >> the document cannot be imported or exported. The
            library contains a
                 >> corpus of badly formatted EmotionML files that
            enables to
                 double check
                 >> if both the schema and the assertions manage to
            correctly
                 invalidate
                 >> them. The API is hosted on google code

                 >> (https://code.google.com/p/__loria-synalp-emotionml/
            <https://code.google.com/p/loria-synalp-emotionml/>) and is


                 released under
                 >the MIT License.
                 >>
                 >> Moreover I don't come to you with empty hands, and I
            have a
                 bunch of
                 >> remarks related to the EmotionML specification.
            Sorry to give
                 you more
                 >work!
                 >>
                 >> best regards,
                 >>
                 >> Alexandre Denis
                 >>
                 >> *** Comments about EmotionML specification
                 >>
                 >> In what follows:
                 >>
                 >> - "specification" refers to the document at

                 >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/


            <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
            of 16
                 April
                 >> 2013)
                 >>
                 >> - "assertions" refers to the list of assertions at
                 >>

            http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class


            <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
                 >>
                 >> - "schema" refers to the schemas

                 >> http://www.w3.org/TR/__emotionml/emotionml.xsd
            <http://www.w3.org/TR/emotionml/emotionml.xsd> and
                 >>
            http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd


            <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
                 >>
                 >> ** Specification clarification questions
                 >>
                 >> - About relative and absolute timing ?
                 >>
                 >>              - Is that possible to mix relative and
            absolute
                 timing ?
                 >> Intuitively this would seem weird but nothing in the
                 >>
                 >>              specification prevents it.
                 >>
                 >> - About consistency of start/end/duration ?
                 >>
                 >>              - I think the specification does not
            enforce the
                 >> consistency of start, end and duration which are
                 >>
                 >>              possible alltogether. Hence it is
            possible to have
                 >> inconsistent triplets (start=0, end=5, duration=10).
                 >>
                 >> - About text nodes ?
                 >>
                 >>              - the emotion element can have text nodes
                 children, it is
                 >> not specified how many. Is it possible to
            intersperse text
                 nodes all
                 >> over
                 >>
                 >>              an emotion element ? The fact that an
            emotion
                 element can
                 >> have text children is not specified in its children
            list.
                 >>
                 >> - About emotion children combinations ?
                 >>
                 >>              - the specification states "There are no
                 constraints on
                 >> the combinations of children that are allowed.", it
            is maybe
                 confusing
                 >> since
                 >>
                 >>              an emotion cannot contain two
            categories that
                 belong to
                 >> different category-sets or two categories with the
            same name.
                 >>
                 >> - About default values ?
                 >>
                 >>              - some attributes have default values
            (reference role,
                 >> time ref anchor point, duration, etc.), is it
            desirable to have a
                 >> default
                 >>
                 >>              value also for other attributes,
            especially for
                 the "value"
                 >> attribute ? For instance, how would you compare
            <category
                 >> name="surprise"/>
                 >>
                 >>              and <category name="surprise"
            value="1.0"/> ? Are they
                 >> semantically equivalent ? A similar question could
            be made
                 about the
                 >> "confidence"
                 >>
                 >>              attribute, how would you compare <category
                 >> name="surprise"/> and <category name="surprise"
                 confidence="1.0"/> ?
                 >>
                 >> - About the number of <trace> ?
                 >>
                 >>              - the specification does not state
            clearly if it is
                 >> possible to have several <trace> elements inside a
            descriptor,
                 it is
                 >> stated
                 >>
                 >>              "a <trace> element". Maybe it should be
            stated "If
                 >> present the following child element can occur one or
            more time:
                 <trace>".
                 >>
                 >>              The schema allows that. If this comment is
                 accepted, the
                 >> assertions 215, 224, 235, 245 should also be clarified.
                 >>
                 >> - About conformance ?
                 >>
                 >>              - In section 4.3, it is stated "It is the
                 responsibility
                 >> of an EmotionML processor to verify that the use of
            descriptor
                 names
                 >> and values
                 >>
                 >>              is consistent with the vocabulary
            definition",
                 which is
                 >> true but incomplete with regards to the assertions,
                 >>
                 >>              maybe it would be beneficial to specify
            all the
                 >> assertions that are not under the schema
            responsability but
                 rather the
                 >> EmotionML processor
                 >>
                 >>              (see below) or at least warn that there
            are many
                 >> assertions not checked by the schema.
                 >>
                 >> ** Discrepancies between

            schema/assertions/__specification


                 >>
                 >> - Assertions not tested by the schema
                 >>
                 >>              - I found that the following assertions
            are not
                 tested by
                 >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
            172, 210, 212,
                 >>
                 >>              216, 220, 222, 224, 230, 232, 236, 240,
            242, 246,
                 410, 417.
                 >>
                 >>              There are assertions that are
            impossible to test
                 with a
                 >> XSD schema I think:
                 >>
                 >>                          114, 117, 120, 123, 161,
            164, 167, 170 :
                 >> vocabulary set id and type checking
                 >>
                 >>                          212, 222, 232, 242 :
            vocabulary name
                 >> membership
                 >>
                 >>                          417 : media type (unless
            enumerating them)
                 >>
                 >>              Some may be possible with some tweaking:
                 >>
                 >>                          210, 220, 230, 240 :
            vocabulary set
                 presence
                 >>
                 >>                          216, 224, 236, 246 :
            <trace> and "value"
                 >>
                 >>              There are two "true" errors I think:
                 >>
                 >>                          172 : The "version"
            attribute of
                 <emotion>,
                 >> if present, MUST have the  value "1.0"
                 >>
                 >>                                      I think it
            should not be
                 >> "optional with default value 1.0" but rather
            "optional with
                 fixed value 1.0"
                 >>
                 >>                          410 : The <reference>
            element MUST
                 contain a
                 >> "uri" attribute
                 >>
                 >>                                      the "uri"
            attribute is
                 optional
                 >> by default in the schema
                 >>
                 >> - 2.4.1, "The end value MUST be greater than or
            equal to the start
                 >> value",
                 >>
                 >>              - the schema does not check it and
            there is no
                 assertion
                 >> enforcing it
                 >>
                 >> - 2.1.2, "a typical use case is expected to be
            embedding an
                 <emotion>
                 >> into some other markup",
                 >>
                 >>              - there is no assertion that describe that
                 <emotion> may
                 >> be embedded in another markup, does it imply we
            could embed other
                 >elements ?
                 >>
                 >>              - is a document containing a sole
            <emotion> a valid
                 >> document (not in the sense of <emotionml> document)
            ? If yes,
                 maybe an
                 >> assertion clarifiying the use of <emotion> would be
            useful.
                 >>
                 >> - assertions 105, 155, 601, 606, status "Req=N"
                 >>
                 >>              - the assertions mix the presence of
            <info> and the
                 >> number of <info> elements, while the presence is not
                 restricted, the
                 >> number
                 >>
                 >>              MUST be 0 or 1, hence the required
            status wrt this
                 part
                 >> of assertions should be "Req=Y"
                 >>
                 >> - 2.1.2, "There are no constraints on the order in which
                 children occur"
                 >>
                 >>              - the schema does actually restrict the
            order of
                 >> elements, <info> needs to be first, then the
            descriptors, then the
                 >> references
                 >>
                 >> ** Invalid documents
                 >>
                 >> (I have not systematically tested examples with
            non-valid
                 vocabulary
                 >> URIs such as http://www.example.
            <http://www.example./>...)
                 >>

                 >> - http://www.w3.org/TR/emotion-__voc/xml


            <http://www.w3.org/TR/emotion-voc/xml> does not comply with
                 assertion
                 >> 110 (hence all examples that refer to vocabularies
            there also fail)
                 >>
                 >> - 2.3.3 The <info> element
                 >>
                 >>              - The last example of this section does
            not comply
                 with
                 >> assertion 212 since the name "neutral" does not
            belong to every-day
                 >> categories
                 >>
                 >> - 5.1.1 Annotation of Text, "Annotation of text"
            Lewis Caroll
                 example:
                 >>
                 >>              - In the <meta:doc> element, the
            character & is found,
                 >> which does not pass XML validation, it should be
            &amp; (so does the
                 >> example below)
                 >>
                 >>              - It also does not comply with
            assertion 212 since
                 >> Disgust and Anger are not part of every-day categories
                 >>
                 >
                 >
                 >--
                 >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
                 >Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>
            <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


        =




    --
    Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice

    Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170 <<a href="tel:%2B81%20466%2049%201170" target="_blank">tel:%2B81%20466%2049%201170>


--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice


Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170



 

--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" target="_blank">+81 466 49 1170

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Kazuyuki Ashimura
Hi Alexandre and Felix,

I think what Debbie says here is correct.

The features of a W3C specification are described in the specification
draft itself, and Schema file is provided just to check basic syntax
errors for convenience.

Also the purpose of the Implementation Report Plan [a] is to provide
clear description of all the features of a specification so that
developers can check if their implementations work properly (and the
specification is implementable).

So if some of the EmotionML features can't be checked using Schema, we
can simply use some test EmotionML file and see whether a specific
EmotionML implementation can work with the file or not.

For example, to test if assertion 156 is implementable, we can
use a brief test156.emotionml like:
[[
<emotionml xmlns="http://www.w3.org/2009/10/emotionml"
         category-set="http://www.w3.org/TR/emotion-voc/xml#big6"
         version="1.0">

     <emotion>
         <info><origin:localization value="bavarian"/></info>
         <!-- <category name="happiness"/> --> <!-- omit category -->
     </emotion>

</emotionml>
]]
and see if the implementation generates an error.

# I think Alexandre's fail_156.xml is also fine :)

[a] http://www.w3.org/2002/mmi/2012/emotionml-irp/

Thanks,

Kazuyuki


On 02/20/2014 01:11 AM, Deborah Dahl wrote:> Hi Felix,
 >
 > Thanks for your succinct summary of the constraints on an XML Schema
 > based approach to describing this feature.
 >
 > If there is a Schema-based approach, then of course it would be good to
 > describe the feature in the Schema, but features of a W3C specification
 > are required to be describable  in a Schema. The text of the
 > specification defines the language, not the Schema. So we should not
 > spend a huge amount of time trying to make the Schema describe this
feature.
 >
 > Best regards,
 >
 > Debbie
 >
 > *From:*[hidden email] [mailto:[hidden email]]
 > *Sent:* Wednesday, February 19, 2014 10:06 AM
 > *To:* [hidden email]
 > *Cc:* [hidden email]; [hidden email];
 > [hidden email]
 > *Subject:* AW: [EmotionML] Additional implementation feedback and Rec
 > publication (was Re: [EmotionML] implementation release and feedbacks)
 >
 > Very sorry, Alexandre, you’re right, I mixed up the files and used the
 > old version.
 >
 > I did some testing and it seems you’re right again, the problem seems
 > that , in a choice, if one element has minOccurs=0 this goes for all
 > elements, even if minOccurs=1 is stated, a behavior I find very
unexpected.
 >
 > We have to find a solution if this can be stated at all in XML schema.
 >
 > To state the problem once more (as I understood it):
 >
 > We need to find a possibility to enforce
 >
 > -That an element has children
 >
 > -Some are optional, at most once
 >
 > -A Group of elements is required (one of them at least once)
 >
 > -The order is not restricted.
 >
 > If we cannot state this, assertion 156 cannot be tested by automatic
 > Schema validation.
 >
 > Regards,
 >
 > Felix
 >
 > *Von:*Alexandre Denis [mailto:[hidden email]]
 > *Gesendet:* Mittwoch, 19. Februar 2014 15:21
 > *An:* Burkhardt, Felix
 > *Cc:* Kazuyuki Ashimura; Deborah Dahl; [hidden email]
 > <mailto:[hidden email]>
 > *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec
 > publication (was Re: [EmotionML] implementation release and feedbacks)
 >
 > Hi Felix,
 >
 > thanks for the feedback, please note that I used the Kazuyuki version
 > (I'm not sure what do you refer to with "current file"). I'm actually
 > using the validation API of Java (jdk1.7.0_51). There might be indeed
 > something wrong with it or with my use of it.
 >
 > I cannot test with Notepad++ (I'm on Mac). However, when testing with an
 > online validator, the fail_156.xml file passes validation with the
new xsd:
 >
 >
http://www.utilities-online.info/xsdvalidation/?save=99b401a2-c0ba-4004-a3c8-c3fefd74d993-xsdvalidation#.UwS5cUJ5N_U
 >
 > The XSD on the right merges:
 >
 > - the root schema : http://www.w3.org/TR/emotionml/emotionml.xsd
 >
 > - the emotionml-fragments.xsd sent by Kazuyuki
 >
 > Nevertheless, when testing the same fail_156.xml with the schemas
 > available on the EmotionML page:
 >
 >
http://www.utilities-online.info/xsdvalidation/?save=f7d401df-c512-48bb-9062-f97d676b13e0-xsdvalidation#.UwS7Z0J5N_U
 >
 > It does not pass the validation as expected with the same result that
 > you have (so that's why I'm not sure of which schema you used).
 > The XSD on the right merges:
 >
 > - the root schema : http://www.w3.org/TR/emotionml/emotionml.xsd
 >
 > - the fragments : http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
 >
 > Are you able to reproduce these results? Maybe I just did something
wrong,
 >
 > best regards,
 >
 > Alex
 >
 > On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]
 > <mailto:[hidden email]>> wrote:
 >
 > Hi all
 >
 > If I try to validate Alexandre’s file with the free Notepad++ editor
 >
 > I get
 >
 > Validation of current file using XML schema:
 >
 > ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion
 > <http://www.w3.org/2009/10/emotionml%7Demotion>': Missing child
 > element(s). Expected is one of (
 > {http://www.w3.org/2009/10/emotionml}info
 > <http://www.w3.org/2009/10/emotionml%7Dinfo>,
 > {http://www.w3.org/2009/10/emotionml}category
 > <http://www.w3.org/2009/10/emotionml%7Dcategory>,
 > {http://www.w3.org/2009/10/emotionml}dimension
 > <http://www.w3.org/2009/10/emotionml%7Ddimension>,
 > {http://www.w3.org/2009/10/emotionml}appraisal
 > <http://www.w3.org/2009/10/emotionml%7Dappraisal>,
 > {http://www.w3.org/2009/10/emotionml}action-tendency
 > <http://www.w3.org/2009/10/emotionml%7Daction-tendency> ).
 >
 > Which is just what should happen.
 >
 > So it seems the xsd works with this respect,
 >
 > perhaps Alexandre’s implementation has really a problem here?
 >
 > Cheers,
 >
 > Felix
 >
 > *Von:*Alexandre Denis [mailto:[hidden email]
 > <mailto:[hidden email]>]
 > *Gesendet:* Mittwoch, 19. Februar 2014 11:53
 > *An:* Kazuyuki Ashimura
 > *Cc:* Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie;
 > Deborah Dahl; [hidden email]
 > <mailto:[hidden email]>; Edmon Begoli;
 > [hidden email] <mailto:[hidden email]>
 > ([hidden email] <mailto:[hidden email]>);
 > [hidden email] <mailto:[hidden email]>; Tim Llewellynn;
 > [hidden email] <mailto:[hidden email]>
 > *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec
 > publication (was Re: [EmotionML] implementation release and feedbacks)
 >
 > Hello Kazuyuki,
 >
 > thanks for the update. Please note that assertion 156 is not tested
 > anymore (The <emotion> element MUST contain at least one <category> or
 > <dimension> or <appraisal> or <action-tendency> element). I think this
 > is because of the <choice> which now seems to accept empty emotions.
 > This could be caused by the interaction between <choice> and children
 > minOccurs=0, it could also be a problem with the implementation I'm
 > using. Could you please test the new schema on the given file with your
 > own validator ? Otherwise it's fine, previous assertions that were not
 > tested are now tested (172, 410 and 417),
 >
 > best regards,
 >
 > Alexandre
 >
 > On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]
 > <mailto:[hidden email]>> wrote:
 >
 > Hi Alexandre,
 >
 > Sorry for the delay.
 >
 > We've fixed the issues on the schema file and the EmotionML vocabulary
 >
 > file, and would like to publish the EmotionML spec as a REC along with
 >
 > the updated EmotionML Vocabulary Note.
 >
 > FYI, we added the following changes to the Schema file for the
 >
 > EmotionML spec:
 >
 > - Replaced "sequence" with "choice" for the <emotion> element in lines
 >
 >    91 and 95.
 >
 > - Changed the "default" to "fixed" for "1.0" in the version attribute
 >
 >    of <emotion> element in line 96.
 >
 > - Added [[use="required"]] to the "uri" attribute of the <reference>
 >
 >    element in line 32.
 >
 > Please see attached "emotionml-fragments.xsd".
 >
 > Also we added version information to the EmotionML vocabulary file.
 >
 > Please see attached "xml.emotionml".
 >
 > Thanks,
 >
 > Kazuyuki
 >
 > On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]
 > <mailto:[hidden email]>> wrote:
 >
 > Hi Alexandre,
 >
 > Happy New Year!  And very sorry for the big delay.
 > I have been travelling (business travels :) for a while.
 >
 > Could you please see inline below?
 >
 >
 >
 > On 12/16/2013 06:43 PM, Alexandre Denis wrote:
 >
 > Hello all,
 > yes sure, but since I don't see the new specification, I can only trust
 > you that the (small) mistakes are corrected. As for the schemas,
 >
 > Thanks!
 >
 >     [5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
 >
 > <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
 >
 > [6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml
 >
 >
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd
 >
 >
 >
 > The only difference I see with the schemas stored in our implementation
 > is the required status of the version attribute of the <emotionml> tag,
 > and it's possible I altered the schema myself because of the lack of the
 > version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
 > fix the version attribute on this document, otherwise every emotionml
 > document referring to these vocabularies will fail to pass validation (I
 > had to manually disable the corresponding assertion check in the code),
 >
 >
 > OK.  We'll see the detail of the problem and fix the issue of
 > version handling.
 >
 > Thanks!
 >
 > Kazuyuki
 >
 >
 > best regards,
 > Alexandre
 >
 >
 >
 >
 > On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]
 > <mailto:[hidden email]>
 >
 > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
 >
 >      Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,
 >
 >      Thank you very much for your EmotionML implementations!  And I
am very
 >      sorry I did not respond to you earlier.  It seems my original
message
 >      did not go out due to some trouble.
 >
 >      As you know, there were the following two features which were not
 >      explicitly listed on the EmotionML Implementation Report Plan [a].
 >
 >      ------------------------------__----------------------------
 >
 >
 >      Two features not listed on the Implementation Report Plan:
 >
 >      ------------------------------__----------------------------
 >
 >
 >      Feature1:
 >         In Section 2.4.1 of the spec [b], there is a feature "The end
value
 >         MUST be greater than or equal to the start value", which is not
 >         checked in the Implementation Report.
 >
 >      Feature2:
 >         In Section 2.1.2 of the spec [b], there is a feature "a
typical use
 >         case is expected to be embedding an <emotion> into some other
 >         markup", which is not checked in the Implementation Report.
 >
 >      However, according to the responses so far, we have already
 >      got the following implementations for the above features.
 >
 >      ------------------------------__------------------
 >
 >
 >      Implementation status of the above two features:
 >
 >      ------------------------------__------------------
 >
 >
 >
 >      Feature1: 3 implementations
 >      - Gerhard Fobe:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
 >      - Alexandre Denis:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
 >      - Patrick Gebhard:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
 >
 >      Feature2: 4 implementations
 >      - Gerhard Fobe:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
 >      - Debbie Dahl:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html>
 >      - Alexandre Denis:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
 >      - Patrick Gebhard:
 >
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
 >
 >      As I reported in October [c], we have already fixed typos in the
spec
 >      and added necessary clarifications to it.  Also we have fixed the
 >      errors in the EmotionML schema.
 >
 >      So I would like to confirm that it is the time for us all to go
ahead
 >      and publish EmotionML as a W3C Recommendation.
 >
 >      Alexandre (as the original commenter), is that OK by you?
 >
 >      [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
 >      <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
 >      [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
 >      <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
 >      [c]
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html
 >
 >
 >
<http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>
 >
 >      Thanks,
 >
 >      Kazuyuki
 >
 >
 >      On 11/08/2013 04:52 AM, Patrick Gebhard wrote:
 >
 >          Dear Felix,
 >
 >          I've updated ALMA (a DFKI EmotionML implementation) last October
 >          in esp.
 >          these two features, see attachment. Maybe my email got lost.
 >
 >          Anyway, Feature 1: pass, Feature 2: pass.
 >
 >          Best
 >          Patrick
 >
 >          Am 07.11.2013 um 18:16 schrieb Marc Schröder
 >          <[hidden email] <mailto:[hidden email]>
 > <mailto:[hidden email] <mailto:[hidden email]>>
 >
 >          <mailto:marcschroeder108@ <mailto:marcschroeder108@>__gmail.com
 > <http://gmail.com>
 >
 >
 >          <mailto:[hidden email]
 > <mailto:[hidden email]>>>>:
 >
 >              Hi all,
 >
 >              DFKI's implementation has not-impl for both of these (unless
 >              it has
 >              been changed since I left).
 >
 >              Looking forward to seeing EmotionML become a Rec!
 >
 >              Best,
 >              Marc
 >
 >
 >              On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>
 >
 >              <mailto:Felix.Burkhardt@
 > <mailto:Felix.Burkhardt@>__telekom.de <http://telekom.de>
 >
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>>> wrote:
 >
 >                   Dear implementers of EmotionML
 >                   To make a long story short: Alexandre Denis of
Loria did a
 >                   thorough review and implementation of EmotionML and
 >              found several
 >                   flaws that we managed to fix, now two issues are still
 >              open and we
 >                   need to know from you whether your implementation
 >              supports two
 >                   features, namely:
 >                   >Feature1:
 >                   >    In Section 2.4.1 of the sepc [1], there is a
 >              feature "The end
 >                   value
 >                   >    MUST be greater than or equal to the start value",
 >              which is not
 >                   >    checked in the Implementation Report.
 >                   >
 >                   >Feature2:
 >                   >    In Section 2.1.2 of the spec [1], there is a
 >              feature "a
 >                   typical use
 >                   >    case is expected to be embedding an <emotion> into
 >              some other
 >                   >    markup", which is not checked in the
 >              Implementation Report.
 >
 >                   Please respond to this mail until 25th of November and
 >              state for
 >                   both features whether it's "pass", "fail"  or
"not-impl"
 >                   Please send the answer to the public mailing list:
 > [hidden email] <mailto:[hidden email]>
 > <mailto:[hidden email] <mailto:[hidden email]>>
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]> <mailto:[hidden email]
 > <mailto:[hidden email]>>>
 >
 >
 >
 >                   EmotionML will then soon become a real recommendation!
 >
 >                   Thanks a lot,
 >                   Felix
 >
 >                   >-----Ursprüngliche Nachricht-----
 >                   >Von: Kazuyuki Ashimura [mailto:[hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email] <mailto:[hidden email]>>
 >                   <mailto:[hidden email] <mailto:[hidden email]>
 > <mailto:[hidden email] <mailto:[hidden email]>>>]
 >                   >Gesendet: Montag, 28. Oktober 2013 07:57
 >                   >An: [hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>
 >
 >              <mailto:alexandre.denis@loria.
 > <mailto:alexandre.denis@loria.>__fr
 >
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>>;
 > [hidden email] <mailto:[hidden email]>
 > <mailto:[hidden email] <mailto:[hidden email]>>
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]> <mailto:[hidden email]
 > <mailto:[hidden email]>>>
 >
 >
 >                   >Cc: Burkhardt, Felix; [hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>
 >
 >                   <mailto:Samuel.Cruz-Lara@
 > <mailto:Samuel.Cruz-Lara@>__loria.fr <http://loria.fr>
 >
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>>
 >                   >Betreff: Re: AW: [EmotionML] implementation release
 >              and feedbacks
 >                   >
 >                   >Dear Alexandre and EmotionML implementers,
 >                   >
 >                   >Thank you very much for implementing EmotionML,
 > Alexandre!
 >                   >Also your thorough review on the EmotionML [1]
 >              specification and the
 >                   >Implementation Report [2] is really appreciated.
 >                   >
 >                   >We are very sorry it took much longer to get consensus
 >              about how
 >                   to respond
 >                   >to you and wrap-up the procedure [3] to publish
 >              EmotionML as a W3C
 >                   >Recommendation.
 >                   >
 >                   >We the W3C Multimodal Interaction Working Group have
 >              already
 >                   fixed typos
 >                   >in the spec and added necessary clarifications to
it.  In
 >                   addition, we have
 >                   >generated an updated version of the schema [5, 6].
 >                   >
 >                   >Now the remaining question is how to deal with your
 >              comments on the
 >                   >Implementation Report which wouldn't change the spec
 >              itself.
 >                   >
 >                   >I talked within the W3C Team about what we should have
 >              done from
 >                   the W3C
 >                   >Process viewpoint, and it seems we need to make sure
 >              that there
 >                   are enough
 >                   >implementation experience for the following two
 >              features which
 >                   were not
 >                   >explicitly described in the published Implementation
 >              Report [2].
 >                   >
 >                   >Feature1:
 >                   >    In Section 2.4.1 of the sepc [1], there is a
 >              feature "The end
 >                   value
 >                   >    MUST be greater than or equal to the start value",
 >              which is not
 >                   >    checked in the Implementation Report.
 >                   >
 >                   >Feature2:
 >                   >    In Section 2.1.2 of the spec [1], there is a
 >              feature "a
 >                   typical use
 >                   >    case is expected to be embedding an <emotion> into
 >              some other
 >                   >    markup", which is not checked in the
 >              Implementation Report.
 >                   >
 >                   >We have already checked with EmotionML implementers
 >              (including
 >                   you) and
 >                   >it seems we can get several implementations for the
 >              above two
 >                   features as
 >                   >well.
 >                   >
 >                   >Now we would like to ask all the EmotionML
 > implementers to
 >                   respond to this
 >                   >message and express if the aobve features are
 >              implmented so that
 >                   we can
 >                   >finalize the procedure and publish EmotionML as a W3C
 >              Recommendation.
 >                   >
 >
 >                   >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
 >              <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
 >                   >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
 >              <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
 >                   >[3]
 > http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
 >
 > <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
 >                   >[4]
 > http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
 >
 > <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
 >                   >[5]
 > http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
 >
<http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
 >                   >[6]
 > http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-
 >
 >
 >              <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
 >                   >fragments.xsd
 >                   >
 >                   >Sincerely,
 >                   >
 >                   >Kazuyuki Ashimura;
 >                   >for the W3C Multimodal Interaction Working Group
 >                   >
 >                   >
 >                   >
 >                   >On 05/02/2013 07:00 PM, [hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>
 >
 >                   <mailto:Felix.Burkhardt@
 > <mailto:Felix.Burkhardt@>__telekom.de <http://telekom.de>
 >
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>> wrote:
 >                   >> Congratulations, Alexandre
 >                   >>
 >                   >>  >Sorry to give you more work!
 >                   >>
 >                   >> Not at all, I'm indeed very happy you work with
 >              EmotionML and
 >                   grateful
 >                   >> you do such a thorough job in revising it!
 >                   >>
 >                   >> It's just it'll take me/us some time to react on
 >              this, sorry
 >                   about this.
 >                   >>
 >                   >> Kind regards,
 >                   >>
 >                   >> Felix
 >                   >>
 >                   >> *Von:*Alexandre Denis
 >
 >              [mailto:alexandre.denis@loria.
 > <mailto:alexandre.denis@loria.>__fr
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>
 >                   <mailto:alexandre.denis@loria.
 > <mailto:alexandre.denis@loria.>__fr
 >
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>>]
 >                   >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
 >                   >> *An:* [hidden email]
 > <mailto:[hidden email]>
 >
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>> <mailto:[hidden email]
 > <mailto:[hidden email]>
 >              <mailto:[hidden email]
 > <mailto:[hidden email]>>>__;
 >
 >
 >                   Samuel CRUZ-LARA
 >                   >> *Betreff:* [EmotionML] implementation release and
 >              feedbacks
 >                   >>
 >                   >> Hello all,
 >                   >>
 >                   >> I'm happy to announce that we released the very
 >              first version
 >                   of our
 >                   >> EmotionML Java implementation. It is hosted on
 >              google code and
 >                   >> released under the MIT license:
 >
 >                   >> https://code.google.com/p/__loria-synalp-emotionml/
 >
 >
 >              <https://code.google.com/p/loria-synalp-emotionml/>
 >                   >>
 >                   >> It is still considered as an alpha version, we would
 >              need some
 >                   users
 >                   >> to validate its use. And there is still some work
 > on the
 >                   documentation
 >                   >> but the core of the code is there.
 >                   >>
 >                   >> If we could be listed as an implementation in the
 >              next round of the
 >                   >> implementation report it would be nice. Here is the
 >              description:
 >                   >>
 >                   >> Alexandre Denis, LORIA laboratory, SYNALP team,
France
 >                   >>
 >                   >> The LORIA/SYNALP implementation of EmotionML is a
 >              Java standalone
 >                   >> library developed in the context of the ITEA
 >              Empathic Products
 >                   project
 >                   >> by the LORIA/SYNALP team. It enables to import Java
 >              objects from
 >                   >> EmotionML XML files and export them to EmotionML as
 >              well. It
 >                   >> guarantees standard compliance by performing a two
 >              steps validation
 >                   >> after all export operations and before all import
 >              operations: first
 >                   >> the EmotionML schema is tested, then all EmotionML
 >              assertions are
 >                   >> tested. If one or the other fails, an error message
 >              is produced and
 >                   >> the document cannot be imported or exported. The
 >              library contains a
 >                   >> corpus of badly formatted EmotionML files that
 >              enables to
 >                   double check
 >                   >> if both the schema and the assertions manage to
 >              correctly
 >                   invalidate
 >                   >> them. The API is hosted on google code
 >
 >                   >> (https://code.google.com/p/__loria-synalp-emotionml/
 >              <https://code.google.com/p/loria-synalp-emotionml/>) and is
 >
 >
 >                   released under
 >                   >the MIT License.
 >                   >>
 >                   >> Moreover I don't come to you with empty hands, and I
 >              have a
 >                   bunch of
 >                   >> remarks related to the EmotionML specification.
 >              Sorry to give
 >                   you more
 >                   >work!
 >                   >>
 >                   >> best regards,
 >                   >>
 >                   >> Alexandre Denis
 >                   >>
 >                   >> *** Comments about EmotionML specification
 >                   >>
 >                   >> In what follows:
 >                   >>
 >                   >> - "specification" refers to the document at
 >
 >                   >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/
 >
 >
 >              <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
 >              of 16
 >                   April
 >                   >> 2013)
 >                   >>
 >                   >> - "assertions" refers to the list of assertions at
 >                   >>
 >
 > http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class
 >
 >
 >              <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
 >                   >>
 >                   >> - "schema" refers to the schemas
 >
 >                   >> http://www.w3.org/TR/__emotionml/emotionml.xsd
 >              <http://www.w3.org/TR/emotionml/emotionml.xsd> and
 >                   >>
 > http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd
 >
 >
 >              <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
 >                   >>
 >                   >> ** Specification clarification questions
 >                   >>
 >                   >> - About relative and absolute timing ?
 >                   >>
 >                   >>              - Is that possible to mix relative and
 >              absolute
 >                   timing ?
 >                   >> Intuitively this would seem weird but nothing in the
 >                   >>
 >                   >>              specification prevents it.
 >                   >>
 >                   >> - About consistency of start/end/duration ?
 >                   >>
 >                   >>              - I think the specification does not
 >              enforce the
 >                   >> consistency of start, end and duration which are
 >                   >>
 >                   >>              possible alltogether. Hence it is
 >              possible to have
 >                   >> inconsistent triplets (start=0, end=5, duration=10).
 >                   >>
 >                   >> - About text nodes ?
 >                   >>
 >                   >>              - the emotion element can have text
nodes
 >                   children, it is
 >                   >> not specified how many. Is it possible to
 >              intersperse text
 >                   nodes all
 >                   >> over
 >                   >>
 >                   >>              an emotion element ? The fact that an
 >              emotion
 >                   element can
 >                   >> have text children is not specified in its children
 >              list.
 >                   >>
 >                   >> - About emotion children combinations ?
 >                   >>
 >                   >>              - the specification states "There
are no
 >                   constraints on
 >                   >> the combinations of children that are allowed.", it
 >              is maybe
 >                   confusing
 >                   >> since
 >                   >>
 >                   >>              an emotion cannot contain two
 >              categories that
 >                   belong to
 >                   >> different category-sets or two categories with the
 >              same name.
 >                   >>
 >                   >> - About default values ?
 >                   >>
 >                   >>              - some attributes have default values
 >              (reference role,
 >                   >> time ref anchor point, duration, etc.), is it
 >              desirable to have a
 >                   >> default
 >                   >>
 >                   >>              value also for other attributes,
 >              especially for
 >                   the "value"
 >                   >> attribute ? For instance, how would you compare
 >              <category
 >                   >> name="surprise"/>
 >                   >>
 >                   >>              and <category name="surprise"
 >              value="1.0"/> ? Are they
 >                   >> semantically equivalent ? A similar question could
 >              be made
 >                   about the
 >                   >> "confidence"
 >                   >>
 >                   >>              attribute, how would you compare
<category
 >                   >> name="surprise"/> and <category name="surprise"
 >                   confidence="1.0"/> ?
 >                   >>
 >                   >> - About the number of <trace> ?
 >                   >>
 >                   >>              - the specification does not state
 >              clearly if it is
 >                   >> possible to have several <trace> elements inside a
 >              descriptor,
 >                   it is
 >                   >> stated
 >                   >>
 >                   >>              "a <trace> element". Maybe it should be
 >              stated "If
 >                   >> present the following child element can occur one or
 >              more time:
 >                   <trace>".
 >                   >>
 >                   >>              The schema allows that. If this
comment is
 >                   accepted, the
 >                   >> assertions 215, 224, 235, 245 should also be
clarified.
 >                   >>
 >                   >> - About conformance ?
 >                   >>
 >                   >>              - In section 4.3, it is stated "It
is the
 >                   responsibility
 >                   >> of an EmotionML processor to verify that the use of
 >              descriptor
 >                   names
 >                   >> and values
 >                   >>
 >                   >>              is consistent with the vocabulary
 >              definition",
 >                   which is
 >                   >> true but incomplete with regards to the assertions,
 >                   >>
 >                   >>              maybe it would be beneficial to specify
 >              all the
 >                   >> assertions that are not under the schema
 >              responsability but
 >                   rather the
 >                   >> EmotionML processor
 >                   >>
 >                   >>              (see below) or at least warn that there
 >              are many
 >                   >> assertions not checked by the schema.
 >                   >>
 >                   >> ** Discrepancies between
 >
 >              schema/assertions/__specification
 >
 >
 >                   >>
 >                   >> - Assertions not tested by the schema
 >                   >>
 >                   >>              - I found that the following assertions
 >              are not
 >                   tested by
 >                   >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
 >              172, 210, 212,
 >                   >>
 >                   >>              216, 220, 222, 224, 230, 232, 236, 240,
 >              242, 246,
 >                   410, 417.
 >                   >>
 >                   >>              There are assertions that are
 >              impossible to test
 >                   with a
 >                   >> XSD schema I think:
 >                   >>
 >                   >>                          114, 117, 120, 123, 161,
 >              164, 167, 170 :
 >                   >> vocabulary set id and type checking
 >                   >>
 >                   >>                          212, 222, 232, 242 :
 >              vocabulary name
 >                   >> membership
 >                   >>
 >                   >>                          417 : media type (unless
 >              enumerating them)
 >                   >>
 >                   >>              Some may be possible with some
tweaking:
 >                   >>
 >                   >>                          210, 220, 230, 240 :
 >              vocabulary set
 >                   presence
 >                   >>
 >                   >>                          216, 224, 236, 246 :
 >              <trace> and "value"
 >                   >>
 >                   >>              There are two "true" errors I think:
 >                   >>
 >                   >>                          172 : The "version"
 >              attribute of
 >                   <emotion>,
 >                   >> if present, MUST have the  value "1.0"
 >                   >>
 >                   >>                                      I think it
 >              should not be
 >                   >> "optional with default value 1.0" but rather
 >              "optional with
 >                   fixed value 1.0"
 >                   >>
 >                   >>                          410 : The <reference>
 >              element MUST
 >                   contain a
 >                   >> "uri" attribute
 >                   >>
 >                   >>                                      the "uri"
 >              attribute is
 >                   optional
 >                   >> by default in the schema
 >                   >>
 >                   >> - 2.4.1, "The end value MUST be greater than or
 >              equal to the start
 >                   >> value",
 >                   >>
 >                   >>              - the schema does not check it and
 >              there is no
 >                   assertion
 >                   >> enforcing it
 >                   >>
 >                   >> - 2.1.2, "a typical use case is expected to be
 >              embedding an
 >                   <emotion>
 >                   >> into some other markup",
 >                   >>
 >                   >>              - there is no assertion that
describe that
 >                   <emotion> may
 >                   >> be embedded in another markup, does it imply we
 >              could embed other
 >                   >elements ?
 >                   >>
 >                   >>              - is a document containing a sole
 >              <emotion> a valid
 >                   >> document (not in the sense of <emotionml> document)
 >              ? If yes,
 >                   maybe an
 >                   >> assertion clarifiying the use of <emotion> would be
 >              useful.
 >                   >>
 >                   >> - assertions 105, 155, 601, 606, status "Req=N"
 >                   >>
 >                   >>              - the assertions mix the presence of
 >              <info> and the
 >                   >> number of <info> elements, while the presence is not
 >                   restricted, the
 >                   >> number
 >                   >>
 >                   >>              MUST be 0 or 1, hence the required
 >              status wrt this
 >                   part
 >                   >> of assertions should be "Req=Y"
 >                   >>
 >                   >> - 2.1.2, "There are no constraints on the order in
 > which
 >                   children occur"
 >                   >>
 >                   >>              - the schema does actually restrict the
 >              order of
 >                   >> elements, <info> needs to be first, then the
 >              descriptors, then the
 >                   >> references
 >                   >>
 >                   >> ** Invalid documents
 >                   >>
 >                   >> (I have not systematically tested examples with
 >              non-valid
 >                   vocabulary
 >                   >> URIs such as http://www.example.
 >              <http://www.example./>...)
 >                   >>
 >
 >                   >> - http://www.w3.org/TR/emotion-__voc/xml
 >
 >
 >              <http://www.w3.org/TR/emotion-voc/xml> does not comply with
 >                   assertion
 >                   >> 110 (hence all examples that refer to vocabularies
 >              there also fail)
 >                   >>
 >                   >> - 2.3.3 The <info> element
 >                   >>
 >                   >>              - The last example of this section does
 >              not comply
 >                   with
 >                   >> assertion 212 since the name "neutral" does not
 >              belong to every-day
 >                   >> categories
 >                   >>
 >                   >> - 5.1.1 Annotation of Text, "Annotation of text"
 >              Lewis Caroll
 >                   example:
 >                   >>
 >                   >>              - In the <meta:doc> element, the
 >              character & is found,
 >                   >> which does not pass XML validation, it should be
 >              &amp; (so does the
 >                   >> example below)
 >                   >>
 >                   >>              - It also does not comply with
 >              assertion 212 since
 >                   >> Disgust and Anger are not part of every-day
categories
 >                   >>
 >                   >
 >                   >
 >                   >--
 >                   >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI
and Voice
 >                   >Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
 > <tel:%2B81%20466%2049%201170>
 >              <tel:%2B81%20466%2049%201170>
 >
 >
 >          =
 >
 >
 >
 >
 >      --
 >      Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
 >
 >      Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
 > <tel:%2B81%20466%2049%201170>
 >
 >
 > --
 > Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
 >
 >
 > Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
 >
 >
 >
 > --
 > Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
 > Tel: +81 466 49 1170 <tel:%2B81%20466%2049%201170>
 >

--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
Tel: +81 466 49 1170


Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Alexandre Denis
Hello all,
yes sure, there are already several assertions that cannot be tested with the schema. Our implementation double checks the schema and the assertions, so for us it's not a real problem.
If you are interested in comparing assertions vs schema, here are some files that we designed to test the validation process: https://code.google.com/p/loria-synalp-emotionml/source/browse/#svn%2Ftrunk%2Ftests%2Ffail
(note: the new schema is not added yet in our repository)
best regards,
Alexandre


On Sat, Feb 22, 2014 at 5:00 PM, Kazuyuki Ashimura <[hidden email]> wrote:
Hi Alexandre and Felix,

I think what Debbie says here is correct.

The features of a W3C specification are described in the specification
draft itself, and Schema file is provided just to check basic syntax
errors for convenience.

Also the purpose of the Implementation Report Plan [a] is to provide
clear description of all the features of a specification so that
developers can check if their implementations work properly (and the
specification is implementable).

So if some of the EmotionML features can't be checked using Schema, we
can simply use some test EmotionML file and see whether a specific
EmotionML implementation can work with the file or not.

For example, to test if assertion 156 is implementable, we can
use a brief test156.emotionml like:
[[
<emotionml xmlns="http://www.w3.org/2009/10/emotionml"
        category-set="http://www.w3.org/TR/emotion-voc/xml#big6"
        version="1.0">

    <emotion>
        <info><origin:localization value="bavarian"/></info>
        <!-- <category name="happiness"/> --> <!-- omit category -->
    </emotion>

</emotionml>
]]
and see if the implementation generates an error.

# I think Alexandre's fail_156.xml is also fine :)

[a] http://www.w3.org/2002/mmi/2012/emotionml-irp/

Thanks,

Kazuyuki


On 02/20/2014 01:11 AM, Deborah Dahl wrote:> Hi Felix,

>
> Thanks for your succinct summary of the constraints on an XML Schema
> based approach to describing this feature.
>
> If there is a Schema-based approach, then of course it would be good to
> describe the feature in the Schema, but features of a W3C specification
> are required to be describable  in a Schema. The text of the
> specification defines the language, not the Schema. So we should not
> spend a huge amount of time trying to make the Schema describe this feature.
>
> Best regards,
>
> Debbie
>
> *From:*[hidden email] [mailto:[hidden email]]
> *Sent:* Wednesday, February 19, 2014 10:06 AM
> *To:* [hidden email]
> *Cc:* [hidden email]; [hidden email];
> [hidden email]
> *Subject:* AW: [EmotionML] Additional implementation feedback and Rec

> publication (was Re: [EmotionML] implementation release and feedbacks)
>
> Very sorry, Alexandre, you’re right, I mixed up the files and used the
> old version.
>
> I did some testing and it seems you’re right again, the problem seems
> that , in a choice, if one element has minOccurs=0 this goes for all
> elements, even if minOccurs=1 is stated, a behavior I find very unexpected.
>
> We have to find a solution if this can be stated at all in XML schema.
>
> To state the problem once more (as I understood it):
>
> We need to find a possibility to enforce
>
> -That an element has children
>
> -Some are optional, at most once
>
> -A Group of elements is required (one of them at least once)
>
> -The order is not restricted.

>
> If we cannot state this, assertion 156 cannot be tested by automatic
> Schema validation.
>
> Regards,
>
> Felix
>
> *Von:*Alexandre Denis [mailto:[hidden email]]
> *Gesendet:* Mittwoch, 19. Februar 2014 15:21
> *An:* Burkhardt, Felix
> *Cc:* Kazuyuki Ashimura; Deborah Dahl; [hidden email]
> <mailto:[hidden email]>
> *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec

> publication (was Re: [EmotionML] implementation release and feedbacks)
>
> Hi Felix,
>
> thanks for the feedback, please note that I used the Kazuyuki version
> (I'm not sure what do you refer to with "current file"). I'm actually
> using the validation API of Java (jdk1.7.0_51). There might be indeed
> something wrong with it or with my use of it.
>
> I cannot test with Notepad++ (I'm on Mac). However, when testing with an
> online validator, the fail_156.xml file passes validation with the new xsd:
>
> http://www.utilities-online.info/xsdvalidation/?save=99b401a2-c0ba-4004-a3c8-c3fefd74d993-xsdvalidation#.UwS5cUJ5N_U
>
> The XSD on the right merges:
>
> - the root schema : http://www.w3.org/TR/emotionml/emotionml.xsd
>
> - the emotionml-fragments.xsd sent by Kazuyuki
>
> Nevertheless, when testing the same fail_156.xml with the schemas
> available on the EmotionML page:
>
> http://www.utilities-online.info/xsdvalidation/?save=f7d401df-c512-48bb-9062-f97d676b13e0-xsdvalidation#.UwS7Z0J5N_U
>
> It does not pass the validation as expected with the same result that
> you have (so that's why I'm not sure of which schema you used).
> The XSD on the right merges:
>
> - the root schema : http://www.w3.org/TR/emotionml/emotionml.xsd
>
> - the fragments : http://www.w3.org/TR/emotionml/emotionml-fragments.xsd
>
> Are you able to reproduce these results? Maybe I just did something wrong,
>
> best regards,
>
> Alex
>
> On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi all
>
> If I try to validate Alexandre’s file with the free Notepad++ editor
>
> I get
>
> Validation of current file using XML schema:
>
> ERROR: Element '{http://www.w3.org/2009/10/emotionml}emotion
> <http://www.w3.org/2009/10/emotionml%7Demotion>': Missing child

> element(s). Expected is one of (
> {http://www.w3.org/2009/10/emotionml}info
> <http://www.w3.org/2009/10/emotionml%7Dinfo>,
> {http://www.w3.org/2009/10/emotionml}category
> <http://www.w3.org/2009/10/emotionml%7Dcategory>,
> {http://www.w3.org/2009/10/emotionml}dimension
> <http://www.w3.org/2009/10/emotionml%7Ddimension>,
> {http://www.w3.org/2009/10/emotionml}appraisal
> <http://www.w3.org/2009/10/emotionml%7Dappraisal>,
> {http://www.w3.org/2009/10/emotionml}action-tendency
> <http://www.w3.org/2009/10/emotionml%7Daction-tendency> ).

>
> Which is just what should happen.
>
> So it seems the xsd works with this respect,
>
> perhaps Alexandre’s implementation has really a problem here?
>
> Cheers,
>
> Felix
>
> *Von:*Alexandre Denis [mailto:[hidden email]
> <mailto:[hidden email]>]
> *Gesendet:* Mittwoch, 19. Februar 2014 11:53
> *An:* Kazuyuki Ashimura
> *Cc:* Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie;
> Deborah Dahl; [hidden email]
> <mailto:[hidden email]>; Edmon Begoli;
> [hidden email] <mailto:[hidden email]>
> ([hidden email] <mailto:[hidden email]>);
> [hidden email] <mailto:[hidden email]>; Tim Llewellynn;
> [hidden email] <mailto:[hidden email]>
> *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec

> publication (was Re: [EmotionML] implementation release and feedbacks)
>
> Hello Kazuyuki,
>
> thanks for the update. Please note that assertion 156 is not tested
> anymore (The <emotion> element MUST contain at least one <category> or
> <dimension> or <appraisal> or <action-tendency> element). I think this
> is because of the <choice> which now seems to accept empty emotions.
> This could be caused by the interaction between <choice> and children
> minOccurs=0, it could also be a problem with the implementation I'm
> using. Could you please test the new schema on the given file with your
> own validator ? Otherwise it's fine, previous assertions that were not
> tested are now tested (172, 410 and 417),
>
> best regards,
>
> Alexandre
>
> On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi Alexandre,
>
> Sorry for the delay.
>
> We've fixed the issues on the schema file and the EmotionML vocabulary
>
> file, and would like to publish the EmotionML spec as a REC along with
>
> the updated EmotionML Vocabulary Note.
>
> FYI, we added the following changes to the Schema file for the
>
> EmotionML spec:
>
> - Replaced "sequence" with "choice" for the <emotion> element in lines
>
>    91 and 95.
>
> - Changed the "default" to "fixed" for "1.0" in the version attribute
>
>    of <emotion> element in line 96.
>
> - Added [[use="required"]] to the "uri" attribute of the <reference>
>
>    element in line 32.
>
> Please see attached "emotionml-fragments.xsd".
>
> Also we added version information to the EmotionML vocabulary file.
>
> Please see attached "xml.emotionml".
>
> Thanks,
>
> Kazuyuki
>
> On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi Alexandre,
>
> Happy New Year!  And very sorry for the big delay.
> I have been travelling (business travels :) for a while.
>
> Could you please see inline below?
>
>
>
> On 12/16/2013 06:43 PM, Alexandre Denis wrote:
>
> Hello all,
> yes sure, but since I don't see the new specification, I can only trust
> you that the (small) mistakes are corrected. As for the schemas,
>
> Thanks!
>
>     [5]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
>
> <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
>
> [6]http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml
>
> <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->-fragments.xsd
>
>
>
> The only difference I see with the schemas stored in our implementation
> is the required status of the version attribute of the <emotionml> tag,
> and it's possible I altered the schema myself because of the lack of the
> version in http://www.w3.org/TR/emotion-voc/xml. It is also important to
> fix the version attribute on this document, otherwise every emotionml
> document referring to these vocabularies will fail to pass validation (I
> had to manually disable the corresponding assertion check in the code),
>
>
> OK.  We'll see the detail of the problem and fix the issue of
> version handling.
>
> Thanks!
>
> Kazuyuki
>
>
> best regards,
> Alexandre
>
>
>
>
> On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <[hidden email]
> <mailto:[hidden email]>
>
> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>
>      Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy and all,
>
>      Thank you very much for your EmotionML implementations!  And I am very
>      sorry I did not respond to you earlier.  It seems my original message
>      did not go out due to some trouble.
>
>      As you know, there were the following two features which were not
>      explicitly listed on the EmotionML Implementation Report Plan [a].
>
>      ------------------------------__----------------------------
>
>
>      Two features not listed on the Implementation Report Plan:
>
>      ------------------------------__----------------------------
>
>
>      Feature1:
>         In Section 2.4.1 of the spec [b], there is a feature "The end value
>         MUST be greater than or equal to the start value", which is not
>         checked in the Implementation Report.
>
>      Feature2:
>         In Section 2.1.2 of the spec [b], there is a feature "a typical use
>         case is expected to be embedding an <emotion> into some other
>         markup", which is not checked in the Implementation Report.
>
>      However, according to the responses so far, we have already
>      got the following implementations for the above features.
>
>      ------------------------------__------------------
>
>
>      Implementation status of the above two features:
>
>      ------------------------------__------------------
>
>
>
>      Feature1: 3 implementations
>      - Gerhard Fobe:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
>      - Alexandre Denis:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
>      - Patrick Gebhard:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
>
>      Feature2: 4 implementations
>      - Gerhard Fobe:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>
>      - Debbie Dahl:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html>
>      - Alexandre Denis:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>
>      - Patrick Gebhard:
>
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>
>
>      As I reported in October [c], we have already fixed typos in the spec
>      and added necessary clarifications to it.  Also we have fixed the
>      errors in the EmotionML schema.
>
>      So I would like to confirm that it is the time for us all to go ahead
>      and publish EmotionML as a W3C Recommendation.
>
>      Alexandre (as the original commenter), is that OK by you?
>
>      [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
>      <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
>      [b] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>      <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
>      [c]
> http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html
>
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013Oct/0010.html>
>
>      Thanks,
>
>      Kazuyuki
>
>
>      On 11/08/2013 04:52 AM, Patrick Gebhard wrote:
>
>          Dear Felix,
>
>          I've updated ALMA (a DFKI EmotionML implementation) last October
>          in esp.
>          these two features, see attachment. Maybe my email got lost.
>
>          Anyway, Feature 1: pass, Feature 2: pass.
>
>          Best
>          Patrick
>
>          Am 07.11.2013 um 18:16 schrieb Marc Schröder
>          <[hidden email] <mailto:[hidden email]>
> <mailto:[hidden email] <mailto:[hidden email]>>
>
>          <mailto:[hidden email] <mailto:[hidden email]>__gmail.com
> <http://gmail.com>
>
>
>          <mailto:[hidden email]

> <mailto:[hidden email]>>>>:
>
>              Hi all,
>
>              DFKI's implementation has not-impl for both of these (unless
>              it has
>              been changed since I left).
>
>              Looking forward to seeing EmotionML become a Rec!
>
>              Best,
>              Marc
>
>
>              On Thu, Nov 7, 2013 at 3:50 AM, <[hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email]
> <mailto:[hidden email]>>
>
>              <mailto:[hidden email]
> <mailto:[hidden email]>__telekom.de <http://telekom.de>
>
>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>>> wrote:
>
>                   Dear implementers of EmotionML
>                   To make a long story short: Alexandre Denis of Loria did a
>                   thorough review and implementation of EmotionML and
>              found several
>                   flaws that we managed to fix, now two issues are still
>              open and we
>                   need to know from you whether your implementation
>              supports two
>                   features, namely:
>                   >Feature1:
>                   >    In Section 2.4.1 of the sepc [1], there is a
>              feature "The end
>                   value
>                   >    MUST be greater than or equal to the start value",
>              which is not
>                   >    checked in the Implementation Report.
>                   >
>                   >Feature2:
>                   >    In Section 2.1.2 of the spec [1], there is a
>              feature "a
>                   typical use
>                   >    case is expected to be embedding an <emotion> into
>              some other
>                   >    markup", which is not checked in the
>              Implementation Report.
>
>                   Please respond to this mail until 25th of November and
>              state for
>                   both features whether it's "pass", "fail"  or "not-impl"
>                   Please send the answer to the public mailing list:
> [hidden email] <mailto:[hidden email]>
> <mailto:[hidden email] <mailto:[hidden email]>>
>
>              <mailto:[hidden email]
> <mailto:[hidden email]> <mailto:[hidden email]
> <mailto:[hidden email]>>>
>
>
>
>                   EmotionML will then soon become a real recommendation!
>
>                   Thanks a lot,
>                   Felix
>
>                   >-----Ursprüngliche Nachricht-----
>                   >Von: Kazuyuki Ashimura [mailto:[hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email] <mailto:[hidden email]>>
>                   <mailto:[hidden email] <mailto:[hidden email]>
> <mailto:[hidden email] <mailto:[hidden email]>>>]
>                   >Gesendet: Montag, 28. Oktober 2013 07:57
>                   >An: [hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email]
> <mailto:[hidden email]>>
>
>              <mailto:[hidden email].
> <mailto:[hidden email].>__fr
>
>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>>;
> [hidden email] <mailto:[hidden email]>
> <mailto:[hidden email] <mailto:[hidden email]>>
>
>              <mailto:[hidden email]
> <mailto:[hidden email]> <mailto:[hidden email]
> <mailto:[hidden email]>>>
>
>
>                   >Cc: Burkhardt, Felix; [hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email]
> <mailto:[hidden email]>>
>
>                   <mailto:[hidden email]
> <mailto:[hidden email]>__loria.fr <http://loria.fr>
>
>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>>
>                   >Betreff: Re: AW: [EmotionML] implementation release
>              and feedbacks
>                   >
>                   >Dear Alexandre and EmotionML implementers,
>                   >
>                   >Thank you very much for implementing EmotionML,
> Alexandre!
>                   >Also your thorough review on the EmotionML [1]
>              specification and the
>                   >Implementation Report [2] is really appreciated.
>                   >
>                   >We are very sorry it took much longer to get consensus
>              about how
>                   to respond
>                   >to you and wrap-up the procedure [3] to publish
>              EmotionML as a W3C
>                   >Recommendation.
>                   >
>                   >We the W3C Multimodal Interaction Working Group have
>              already
>                   fixed typos
>                   >in the spec and added necessary clarifications to it.  In
>                   addition, we have
>                   >generated an updated version of the schema [5, 6].
>                   >
>                   >Now the remaining question is how to deal with your
>              comments on the
>                   >Implementation Report which wouldn't change the spec
>              itself.
>                   >
>                   >I talked within the W3C Team about what we should have
>              done from
>                   the W3C
>                   >Process viewpoint, and it seems we need to make sure
>              that there
>                   are enough
>                   >implementation experience for the following two
>              features which
>                   were not
>                   >explicitly described in the published Implementation
>              Report [2].
>                   >
>                   >Feature1:
>                   >    In Section 2.4.1 of the sepc [1], there is a
>              feature "The end
>                   value
>                   >    MUST be greater than or equal to the start value",
>              which is not
>                   >    checked in the Implementation Report.
>                   >
>                   >Feature2:
>                   >    In Section 2.1.2 of the spec [1], there is a
>              feature "a
>                   typical use
>                   >    case is expected to be embedding an <emotion> into
>              some other
>                   >    markup", which is not checked in the
>              Implementation Report.
>                   >
>                   >We have already checked with EmotionML implementers
>              (including
>                   you) and
>                   >it seems we can get several implementations for the
>              above two
>                   features as
>                   >well.
>                   >
>                   >Now we would like to ask all the EmotionML
> implementers to
>                   respond to this
>                   >message and express if the aobve features are
>              implmented so that
>                   we can
>                   >finalize the procedure and publish EmotionML as a W3C
>              Recommendation.
>                   >
>
>                   >[1] http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>              <http://www.w3.org/TR/2013/PR-emotionml-20130416/>
>                   >[2] http://www.w3.org/2002/mmi/__2013/emotionml-ir/
>              <http://www.w3.org/2002/mmi/2013/emotionml-ir/>
>                   >[3]
> http://www.w3.org/2004/02/__Process-20040205/tr.html#__maturity-levels
>
> <http://www.w3.org/2004/02/Process-20040205/tr.html#maturity-levels>
>                   >[4]
> http://lists.w3.org/Archives/__Public/www-multimodal/2013May/__0000.html
>
> <http://lists.w3.org/Archives/Public/www-multimodal/2013May/0000.html>
>                   >[5]
> http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
> <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>
>                   >[6]
> http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-
>
>
>              <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->
>                   >fragments.xsd
>                   >
>                   >Sincerely,
>                   >
>                   >Kazuyuki Ashimura;
>                   >for the W3C Multimodal Interaction Working Group
>                   >
>                   >
>                   >
>                   >On 05/02/2013 07:00 PM, [hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email]
> <mailto:[hidden email]>>
>
>                   <mailto:[hidden email]
> <mailto:[hidden email]>__telekom.de <http://telekom.de>
>
>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>> wrote:
>                   >> Congratulations, Alexandre
>                   >>
>                   >>  >Sorry to give you more work!
>                   >>
>                   >> Not at all, I'm indeed very happy you work with
>              EmotionML and
>                   grateful
>                   >> you do such a thorough job in revising it!
>                   >>
>                   >> It's just it'll take me/us some time to react on
>              this, sorry
>                   about this.
>                   >>
>                   >> Kind regards,
>                   >>
>                   >> Felix
>                   >>
>                   >> *Von:*Alexandre Denis
>
>              [mailto:[hidden email].
> <mailto:[hidden email].>__fr
>              <mailto:[hidden email]
> <mailto:[hidden email]>>
>                   <mailto:[hidden email].
> <mailto:[hidden email].>__fr
>
>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>>]
>                   >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
>                   >> *An:* [hidden email]
> <mailto:[hidden email]>
>
>              <mailto:[hidden email]
> <mailto:[hidden email]>> <mailto:[hidden email]
> <mailto:[hidden email]>
>              <mailto:[hidden email]

> <mailto:[hidden email]>>>__;
>
>
>                   Samuel CRUZ-LARA
>                   >> *Betreff:* [EmotionML] implementation release and
>              feedbacks
>                   >>
>                   >> Hello all,
>                   >>
>                   >> I'm happy to announce that we released the very
>              first version
>                   of our
>                   >> EmotionML Java implementation. It is hosted on
>              google code and
>                   >> released under the MIT license:
>
>                   >> https://code.google.com/p/__loria-synalp-emotionml/
>
>
>              <https://code.google.com/p/loria-synalp-emotionml/>
>                   >>
>                   >> It is still considered as an alpha version, we would
>              need some
>                   users
>                   >> to validate its use. And there is still some work
> on the
>                   documentation
>                   >> but the core of the code is there.
>                   >>
>                   >> If we could be listed as an implementation in the
>              next round of the
>                   >> implementation report it would be nice. Here is the
>              description:
>                   >>
>                   >> Alexandre Denis, LORIA laboratory, SYNALP team, France
>                   >>
>                   >> The LORIA/SYNALP implementation of EmotionML is a
>              Java standalone
>                   >> library developed in the context of the ITEA
>              Empathic Products
>                   project
>                   >> by the LORIA/SYNALP team. It enables to import Java
>              objects from
>                   >> EmotionML XML files and export them to EmotionML as
>              well. It
>                   >> guarantees standard compliance by performing a two
>              steps validation
>                   >> after all export operations and before all import
>              operations: first
>                   >> the EmotionML schema is tested, then all EmotionML
>              assertions are
>                   >> tested. If one or the other fails, an error message
>              is produced and
>                   >> the document cannot be imported or exported. The
>              library contains a
>                   >> corpus of badly formatted EmotionML files that
>              enables to
>                   double check
>                   >> if both the schema and the assertions manage to
>              correctly
>                   invalidate
>                   >> them. The API is hosted on google code
>
>                   >> (https://code.google.com/p/__loria-synalp-emotionml/
>              <https://code.google.com/p/loria-synalp-emotionml/>) and is
>
>
>                   released under
>                   >the MIT License.
>                   >>
>                   >> Moreover I don't come to you with empty hands, and I
>              have a
>                   bunch of
>                   >> remarks related to the EmotionML specification.
>              Sorry to give
>                   you more
>                   >work!
>                   >>
>                   >> best regards,
>                   >>
>                   >> Alexandre Denis
>                   >>
>                   >> *** Comments about EmotionML specification
>                   >>
>                   >> In what follows:
>                   >>
>                   >> - "specification" refers to the document at
>
>                   >> http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>
>
>              <http://www.w3.org/TR/2013/PR-emotionml-20130416/> (version
>              of 16
>                   April
>                   >> 2013)
>                   >>
>                   >> - "assertions" refers to the list of assertions at
>                   >>
>
> http://www.w3.org/2002/mmi/__2013/emotionml-ir/#test_class
>
>
>              <http://www.w3.org/2002/mmi/2013/emotionml-ir/#test_class>
>                   >>
>                   >> - "schema" refers to the schemas
>
>                   >> http://www.w3.org/TR/__emotionml/emotionml.xsd
>              <http://www.w3.org/TR/emotionml/emotionml.xsd> and
>                   >>
> http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd
>
>
>              <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
>                   >>
>                   >> ** Specification clarification questions
>                   >>
>                   >> - About relative and absolute timing ?
>                   >>
>                   >>              - Is that possible to mix relative and
>              absolute
>                   timing ?
>                   >> Intuitively this would seem weird but nothing in the
>                   >>
>                   >>              specification prevents it.
>                   >>
>                   >> - About consistency of start/end/duration ?
>                   >>
>                   >>              - I think the specification does not
>              enforce the
>                   >> consistency of start, end and duration which are
>                   >>
>                   >>              possible alltogether. Hence it is
>              possible to have
>                   >> inconsistent triplets (start=0, end=5, duration=10).
>                   >>
>                   >> - About text nodes ?
>                   >>
>                   >>              - the emotion element can have text nodes
>                   children, it is
>                   >> not specified how many. Is it possible to
>              intersperse text
>                   nodes all
>                   >> over
>                   >>
>                   >>              an emotion element ? The fact that an
>              emotion
>                   element can
>                   >> have text children is not specified in its children
>              list.
>                   >>
>                   >> - About emotion children combinations ?
>                   >>
>                   >>              - the specification states "There are no
>                   constraints on
>                   >> the combinations of children that are allowed.", it
>              is maybe
>                   confusing
>                   >> since
>                   >>
>                   >>              an emotion cannot contain two
>              categories that
>                   belong to
>                   >> different category-sets or two categories with the
>              same name.
>                   >>
>                   >> - About default values ?
>                   >>
>                   >>              - some attributes have default values
>              (reference role,
>                   >> time ref anchor point, duration, etc.), is it
>              desirable to have a
>                   >> default
>                   >>
>                   >>              value also for other attributes,
>              especially for
>                   the "value"
>                   >> attribute ? For instance, how would you compare
>              <category
>                   >> name="surprise"/>
>                   >>
>                   >>              and <category name="surprise"
>              value="1.0"/> ? Are they
>                   >> semantically equivalent ? A similar question could
>              be made
>                   about the
>                   >> "confidence"
>                   >>
>                   >>              attribute, how would you compare <category
>                   >> name="surprise"/> and <category name="surprise"
>                   confidence="1.0"/> ?
>                   >>
>                   >> - About the number of <trace> ?
>                   >>
>                   >>              - the specification does not state
>              clearly if it is
>                   >> possible to have several <trace> elements inside a
>              descriptor,
>                   it is
>                   >> stated
>                   >>
>                   >>              "a <trace> element". Maybe it should be
>              stated "If
>                   >> present the following child element can occur one or
>              more time:
>                   <trace>".
>                   >>
>                   >>              The schema allows that. If this comment is
>                   accepted, the
>                   >> assertions 215, 224, 235, 245 should also be clarified.
>                   >>
>                   >> - About conformance ?
>                   >>
>                   >>              - In section 4.3, it is stated "It is the
>                   responsibility
>                   >> of an EmotionML processor to verify that the use of
>              descriptor
>                   names
>                   >> and values
>                   >>
>                   >>              is consistent with the vocabulary
>              definition",
>                   which is
>                   >> true but incomplete with regards to the assertions,
>                   >>
>                   >>              maybe it would be beneficial to specify
>              all the
>                   >> assertions that are not under the schema
>              responsability but
>                   rather the
>                   >> EmotionML processor
>                   >>
>                   >>              (see below) or at least warn that there
>              are many
>                   >> assertions not checked by the schema.
>                   >>
>                   >> ** Discrepancies between
>
>              schema/assertions/__specification
>
>
>                   >>
>                   >> - Assertions not tested by the schema
>                   >>
>                   >>              - I found that the following assertions
>              are not
>                   tested by
>                   >> the schema : 114, 117, 120, 123, 161, 164, 167, 170,
>              172, 210, 212,
>                   >>
>                   >>              216, 220, 222, 224, 230, 232, 236, 240,
>              242, 246,
>                   410, 417.
>                   >>
>                   >>              There are assertions that are
>              impossible to test
>                   with a
>                   >> XSD schema I think:
>                   >>
>                   >>                          114, 117, 120, 123, 161,
>              164, 167, 170 :
>                   >> vocabulary set id and type checking
>                   >>
>                   >>                          212, 222, 232, 242 :
>              vocabulary name
>                   >> membership
>                   >>
>                   >>                          417 : media type (unless
>              enumerating them)
>                   >>
>                   >>              Some may be possible with some tweaking:
>                   >>
>                   >>                          210, 220, 230, 240 :
>              vocabulary set
>                   presence
>                   >>
>                   >>                          216, 224, 236, 246 :
>              <trace> and "value"
>                   >>
>                   >>              There are two "true" errors I think:
>                   >>
>                   >>                          172 : The "version"
>              attribute of
>                   <emotion>,
>                   >> if present, MUST have the  value "1.0"
>                   >>
>                   >>                                      I think it
>              should not be
>                   >> "optional with default value 1.0" but rather
>              "optional with
>                   fixed value 1.0"
>                   >>
>                   >>                          410 : The <reference>
>              element MUST
>                   contain a
>                   >> "uri" attribute
>                   >>
>                   >>                                      the "uri"
>              attribute is
>                   optional
>                   >> by default in the schema
>                   >>
>                   >> - 2.4.1, "The end value MUST be greater than or
>              equal to the start
>                   >> value",
>                   >>
>                   >>              - the schema does not check it and
>              there is no
>                   assertion
>                   >> enforcing it
>                   >>
>                   >> - 2.1.2, "a typical use case is expected to be
>              embedding an
>                   <emotion>
>                   >> into some other markup",
>                   >>
>                   >>              - there is no assertion that describe that
>                   <emotion> may
>                   >> be embedded in another markup, does it imply we
>              could embed other
>                   >elements ?
>                   >>
>                   >>              - is a document containing a sole
>              <emotion> a valid
>                   >> document (not in the sense of <emotionml> document)
>              ? If yes,
>                   maybe an
>                   >> assertion clarifiying the use of <emotion> would be
>              useful.
>                   >>
>                   >> - assertions 105, 155, 601, 606, status "Req=N"
>                   >>
>                   >>              - the assertions mix the presence of
>              <info> and the
>                   >> number of <info> elements, while the presence is not
>                   restricted, the
>                   >> number
>                   >>
>                   >>              MUST be 0 or 1, hence the required
>              status wrt this
>                   part
>                   >> of assertions should be "Req=Y"
>                   >>
>                   >> - 2.1.2, "There are no constraints on the order in
> which
>                   children occur"
>                   >>
>                   >>              - the schema does actually restrict the
>              order of
>                   >> elements, <info> needs to be first, then the
>              descriptors, then the
>                   >> references
>                   >>
>                   >> ** Invalid documents
>                   >>
>                   >> (I have not systematically tested examples with
>              non-valid
>                   vocabulary
>                   >> URIs such as http://www.example.
>              <http://www.example./>...)
>                   >>
>
>                   >> - http://www.w3.org/TR/emotion-__voc/xml
>
>
>              <http://www.w3.org/TR/emotion-voc/xml> does not comply with
>                   assertion
>                   >> 110 (hence all examples that refer to vocabularies
>              there also fail)
>                   >>
>                   >> - 2.3.3 The <info> element
>                   >>
>                   >>              - The last example of this section does
>              not comply
>                   with
>                   >> assertion 212 since the name "neutral" does not
>              belong to every-day
>                   >> categories
>                   >>
>                   >> - 5.1.1 Annotation of Text, "Annotation of text"
>              Lewis Caroll
>                   example:
>                   >>
>                   >>              - In the <meta:doc> element, the
>              character & is found,
>                   >> which does not pass XML validation, it should be
>              &amp; (so does the
>                   >> example below)
>                   >>
>                   >>              - It also does not comply with
>              assertion 212 since
>                   >> Disgust and Anger are not part of every-day categories
>                   >>
>                   >
>                   >
>                   >--
>                   >Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>                   >Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
> <tel:%2B81%20466%2049%201170>
>              <tel:%2B81%20466%2049%201170>
>
>
>          =
>
>
>
>
>      --
>      Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
>
>      Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
> <tel:%2B81%20466%2049%201170>
>
>
> --
> Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
>
>
> Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
>
>
>
> --
> Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
> Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170 <tel:%2B81%20466%2049%201170>
>

--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
Tel: <a href="tel:%2B81%20466%2049%201170" value="+81466491170" target="_blank">+81 466 49 1170


Reply | Threaded
Open this post in threaded view
|

Re: [EmotionML] Additional implementation feedback and Rec publication (was Re: [EmotionML] implementation release and feedbacks)

Kazuyuki Ashimura
On 02/24/2014 05:14 PM, Alexandre Denis wrote:
> Hello all,
> yes sure, there are already several assertions that cannot be tested
> with the schema. Our implementation double checks the schema and the
> assertions, so for us it's not a real problem.

Thanks a lot for your understanding, Alexadre!

We've solved all the existing issues, and I believe it's the time
to publish EmotionML as a W3C Recommendation :)

> If you are interested in comparing assertions vs schema, here are some
> files that we designed to test the validation process:
> https://code.google.com/p/loria-synalp-emotionml/source/browse/#svn%2Ftrunk%2Ftests%2Ffail
> (note: the new schema is not added yet in our repository)

Also thank you very much for your great contribution!

Thanks,

Kazuyuki


> best regards,
> Alexandre
>
>
> On Sat, Feb 22, 2014 at 5:00 PM, Kazuyuki Ashimura <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Alexandre and Felix,
>
>     I think what Debbie says here is correct.
>
>     The features of a W3C specification are described in the specification
>     draft itself, and Schema file is provided just to check basic syntax
>     errors for convenience.
>
>     Also the purpose of the Implementation Report Plan [a] is to provide
>     clear description of all the features of a specification so that
>     developers can check if their implementations work properly (and the
>     specification is implementable).
>
>     So if some of the EmotionML features can't be checked using Schema, we
>     can simply use some test EmotionML file and see whether a specific
>     EmotionML implementation can work with the file or not.
>
>     For example, to test if assertion 156 is implementable, we can
>     use a brief test156.emotionml like:
>     [[
>     <emotionml xmlns="http://www.w3.org/2009/__10/emotionml
>     <http://www.w3.org/2009/10/emotionml>"
>              category-set="http://www.w3.__org/TR/emotion-voc/xml#big6
>     <http://www.w3.org/TR/emotion-voc/xml#big6>"
>              version="1.0">
>
>          <emotion>
>              <info><origin:localization value="bavarian"/></info>
>              <!-- <category name="happiness"/> --> <!-- omit category -->
>          </emotion>
>
>     </emotionml>
>     ]]
>     and see if the implementation generates an error.
>
>     # I think Alexandre's fail_156.xml is also fine :)
>
>     [a] http://www.w3.org/2002/mmi/__2012/emotionml-irp/
>     <http://www.w3.org/2002/mmi/2012/emotionml-irp/>
>
>     Thanks,
>
>     Kazuyuki
>
>
>     On 02/20/2014 01:11 AM, Deborah Dahl wrote:> Hi Felix,
>
>      >
>      > Thanks for your succinct summary of the constraints on an XML Schema
>      > based approach to describing this feature.
>      >
>      > If there is a Schema-based approach, then of course it would be
>     good to
>      > describe the feature in the Schema, but features of a W3C
>     specification
>      > are required to be describable  in a Schema. The text of the
>      > specification defines the language, not the Schema. So we should not
>      > spend a huge amount of time trying to make the Schema describe
>     this feature.
>      >
>      > Best regards,
>      >
>      > Debbie
>      >
>      > *From:*[hidden email]
>     <mailto:[hidden email]>
>     [mailto:[hidden email]
>     <mailto:[hidden email]>]
>      > *Sent:* Wednesday, February 19, 2014 10:06 AM
>      > *To:* [hidden email] <mailto:[hidden email]>
>      > *Cc:* [hidden email] <mailto:[hidden email]>;
>     [hidden email]
>     <mailto:[hidden email]>;
>      > [hidden email] <mailto:[hidden email]>
>      > *Subject:* AW: [EmotionML] Additional implementation feedback and Rec
>
>      > publication (was Re: [EmotionML] implementation release and
>     feedbacks)
>      >
>      > Very sorry, Alexandre, you’re right, I mixed up the files and
>     used the
>      > old version.
>      >
>      > I did some testing and it seems you’re right again, the problem seems
>      > that , in a choice, if one element has minOccurs=0 this goes for all
>      > elements, even if minOccurs=1 is stated, a behavior I find very
>     unexpected.
>      >
>      > We have to find a solution if this can be stated at all in XML
>     schema.
>      >
>      > To state the problem once more (as I understood it):
>      >
>      > We need to find a possibility to enforce
>      >
>      > -That an element has children
>      >
>      > -Some are optional, at most once
>      >
>      > -A Group of elements is required (one of them at least once)
>      >
>      > -The order is not restricted.
>
>      >
>      > If we cannot state this, assertion 156 cannot be tested by automatic
>      > Schema validation.
>      >
>      > Regards,
>      >
>      > Felix
>      >
>      > *Von:*Alexandre Denis [mailto:alexandre.denis@loria.__fr
>     <mailto:[hidden email]>]
>      > *Gesendet:* Mittwoch, 19. Februar 2014 15:21
>      > *An:* Burkhardt, Felix
>      > *Cc:* Kazuyuki Ashimura; Deborah Dahl; [hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>
>      > *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec
>
>      > publication (was Re: [EmotionML] implementation release and
>     feedbacks)
>      >
>      > Hi Felix,
>      >
>      > thanks for the feedback, please note that I used the Kazuyuki version
>      > (I'm not sure what do you refer to with "current file"). I'm actually
>      > using the validation API of Java (jdk1.7.0_51). There might be indeed
>      > something wrong with it or with my use of it.
>      >
>      > I cannot test with Notepad++ (I'm on Mac). However, when testing
>     with an
>      > online validator, the fail_156.xml file passes validation with
>     the new xsd:
>      >
>      >
>     http://www.utilities-online.__info/xsdvalidation/?save=__99b401a2-c0ba-4004-a3c8-__c3fefd74d993-xsdvalidation#.__UwS5cUJ5N_U
>     <http://www.utilities-online.info/xsdvalidation/?save=99b401a2-c0ba-4004-a3c8-c3fefd74d993-xsdvalidation#.UwS5cUJ5N_U>
>      >
>      > The XSD on the right merges:
>      >
>      > - the root schema :
>     http://www.w3.org/TR/__emotionml/emotionml.xsd
>     <http://www.w3.org/TR/emotionml/emotionml.xsd>
>      >
>      > - the emotionml-fragments.xsd sent by Kazuyuki
>      >
>      > Nevertheless, when testing the same fail_156.xml with the schemas
>      > available on the EmotionML page:
>      >
>      >
>     http://www.utilities-online.__info/xsdvalidation/?save=__f7d401df-c512-48bb-9062-__f97d676b13e0-xsdvalidation#.__UwS7Z0J5N_U
>     <http://www.utilities-online.info/xsdvalidation/?save=f7d401df-c512-48bb-9062-f97d676b13e0-xsdvalidation#.UwS7Z0J5N_U>
>      >
>      > It does not pass the validation as expected with the same result that
>      > you have (so that's why I'm not sure of which schema you used).
>      > The XSD on the right merges:
>      >
>      > - the root schema :
>     http://www.w3.org/TR/__emotionml/emotionml.xsd
>     <http://www.w3.org/TR/emotionml/emotionml.xsd>
>      >
>      > - the fragments :
>     http://www.w3.org/TR/__emotionml/emotionml-fragments.__xsd
>     <http://www.w3.org/TR/emotionml/emotionml-fragments.xsd>
>      >
>      > Are you able to reproduce these results? Maybe I just did
>     something wrong,
>      >
>      > best regards,
>      >
>      > Alex
>      >
>      > On Wed, Feb 19, 2014 at 2:49 PM, <[hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email]
>     <mailto:[hidden email]>>> wrote:
>      >
>      > Hi all
>      >
>      > If I try to validate Alexandre’s file with the free Notepad++ editor
>      >
>      > I get
>      >
>      > Validation of current file using XML schema:
>      >
>      > ERROR: Element '{http://www.w3.org/2009/10/__emotionml}emotion
>     <http://www.w3.org/2009/10/emotionml%7Demotion>
>      > <http://www.w3.org/2009/10/__emotionml%7Demotion
>     <http://www.w3.org/2009/10/emotionml%7Demotion>>': Missing child
>
>      > element(s). Expected is one of (
>      > {http://www.w3.org/2009/10/__emotionml}info
>     <http://www.w3.org/2009/10/emotionml%7Dinfo>
>      > <http://www.w3.org/2009/10/__emotionml%7Dinfo
>     <http://www.w3.org/2009/10/emotionml%7Dinfo>>,
>      > {http://www.w3.org/2009/10/__emotionml}category
>     <http://www.w3.org/2009/10/emotionml%7Dcategory>
>      > <http://www.w3.org/2009/10/__emotionml%7Dcategory
>     <http://www.w3.org/2009/10/emotionml%7Dcategory>>,
>      > {http://www.w3.org/2009/10/__emotionml}dimension
>     <http://www.w3.org/2009/10/emotionml%7Ddimension>
>      > <http://www.w3.org/2009/10/__emotionml%7Ddimension
>     <http://www.w3.org/2009/10/emotionml%7Ddimension>>,
>      > {http://www.w3.org/2009/10/__emotionml}appraisal
>     <http://www.w3.org/2009/10/emotionml%7Dappraisal>
>      > <http://www.w3.org/2009/10/__emotionml%7Dappraisal
>     <http://www.w3.org/2009/10/emotionml%7Dappraisal>>,
>      > {http://www.w3.org/2009/10/__emotionml}action-tendency
>     <http://www.w3.org/2009/10/emotionml%7Daction-tendency>
>      > <http://www.w3.org/2009/10/__emotionml%7Daction-tendency
>     <http://www.w3.org/2009/10/emotionml%7Daction-tendency>> ).
>
>      >
>      > Which is just what should happen.
>      >
>      > So it seems the xsd works with this respect,
>      >
>      > perhaps Alexandre’s implementation has really a problem here?
>      >
>      > Cheers,
>      >
>      > Felix
>      >
>      > *Von:*Alexandre Denis [mailto:alexandre.denis@loria.__fr
>     <mailto:[hidden email]>
>      > <mailto:alexandre.denis@loria.__fr
>     <mailto:[hidden email]>>]
>      > *Gesendet:* Mittwoch, 19. Februar 2014 11:53
>      > *An:* Kazuyuki Ashimura
>      > *Cc:* Patrick Gebhard; Burkhardt, Felix; Marc Schröder; Roddy Cowie;
>      > Deborah Dahl; [hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email]
>     <mailto:[hidden email]>>; Edmon Begoli;
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>      > ([hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>);
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>; Tim Llewellynn;
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>      > *Betreff:* Re: [EmotionML] Additional implementation feedback and Rec
>
>      > publication (was Re: [EmotionML] implementation release and
>     feedbacks)
>      >
>      > Hello Kazuyuki,
>      >
>      > thanks for the update. Please note that assertion 156 is not tested
>      > anymore (The <emotion> element MUST contain at least one
>     <category> or
>      > <dimension> or <appraisal> or <action-tendency> element). I think
>     this
>      > is because of the <choice> which now seems to accept empty emotions.
>      > This could be caused by the interaction between <choice> and children
>      > minOccurs=0, it could also be a problem with the implementation I'm
>      > using. Could you please test the new schema on the given file
>     with your
>      > own validator ? Otherwise it's fine, previous assertions that
>     were not
>      > tested are now tested (172, 410 and 417),
>      >
>      > best regards,
>      >
>      > Alexandre
>      >
>      > On Tue, Feb 18, 2014 at 11:37 AM, Kazuyuki Ashimura
>     <[hidden email] <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      > Hi Alexandre,
>      >
>      > Sorry for the delay.
>      >
>      > We've fixed the issues on the schema file and the EmotionML
>     vocabulary
>      >
>      > file, and would like to publish the EmotionML spec as a REC along
>     with
>      >
>      > the updated EmotionML Vocabulary Note.
>      >
>      > FYI, we added the following changes to the Schema file for the
>      >
>      > EmotionML spec:
>      >
>      > - Replaced "sequence" with "choice" for the <emotion> element in
>     lines
>      >
>      >    91 and 95.
>      >
>      > - Changed the "default" to "fixed" for "1.0" in the version attribute
>      >
>      >    of <emotion> element in line 96.
>      >
>      > - Added [[use="required"]] to the "uri" attribute of the <reference>
>      >
>      >    element in line 32.
>      >
>      > Please see attached "emotionml-fragments.xsd".
>      >
>      > Also we added version information to the EmotionML vocabulary file.
>      >
>      > Please see attached "xml.emotionml".
>      >
>      > Thanks,
>      >
>      > Kazuyuki
>      >
>      > On Sat, Jan 18, 2014 at 3:21 AM, Kazuyuki Ashimura
>     <[hidden email] <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      > Hi Alexandre,
>      >
>      > Happy New Year!  And very sorry for the big delay.
>      > I have been travelling (business travels :) for a while.
>      >
>      > Could you please see inline below?
>      >
>      >
>      >
>      > On 12/16/2013 06:43 PM, Alexandre Denis wrote:
>      >
>      > Hello all,
>      > yes sure, but since I don't see the new specification, I can only
>     trust
>      > you that the (small) mistakes are corrected. As for the schemas,
>      >
>      > Thanks!
>      >
>      >
>     [5]http://www.w3.org/TR/2013/__PR-__emotionml-20130416/__emotionml.__xsd
>     <http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd>
>      >
>      >
>     <http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml.__xsd
>     <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml.xsd>>
>      >
>      >
>     [6]http://www.w3.org/TR/2013/__PR-__emotionml-20130416/__emotionml
>     <http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml>
>      >
>      > <http://www.w3.org/TR/2013/PR-__emotionml-20130416/emotionml-
>     <http://www.w3.org/TR/2013/PR-emotionml-20130416/emotionml->>__-fragments.xsd
>      >
>      >
>      >
>      > The only difference I see with the schemas stored in our
>     implementation
>      > is the required status of the version attribute of the
>     <emotionml> tag,
>      > and it's possible I altered the schema myself because of the lack
>     of the
>      > version in http://www.w3.org/TR/emotion-__voc/xml
>     <http://www.w3.org/TR/emotion-voc/xml>. It is also important to
>      > fix the version attribute on this document, otherwise every emotionml
>      > document referring to these vocabularies will fail to pass
>     validation (I
>      > had to manually disable the corresponding assertion check in the
>     code),
>      >
>      >
>      > OK.  We'll see the detail of the problem and fix the issue of
>      > version handling.
>      >
>      > Thanks!
>      >
>      > Kazuyuki
>      >
>      >
>      > best regards,
>      > Alexandre
>      >
>      >
>      >
>      >
>      > On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura
>     <[hidden email] <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>
>      >
>      > <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>> wrote:
>      >
>      >      Hi Alexandre, Debbie, Felix, Gerhard, Patrick, Marc, Roddy
>     and all,
>      >
>      >      Thank you very much for your EmotionML implementations!  And
>     I am very
>      >      sorry I did not respond to you earlier.  It seems my
>     original message
>      >      did not go out due to some trouble.
>      >
>      >      As you know, there were the following two features which
>     were not
>      >      explicitly listed on the EmotionML Implementation Report
>     Plan [a].
>      >
>      >      ------------------------------____----------------------------
>      >
>      >
>      >      Two features not listed on the Implementation Report Plan:
>      >
>      >      ------------------------------____----------------------------
>      >
>      >
>      >      Feature1:
>      >         In Section 2.4.1 of the spec [b], there is a feature "The
>     end value
>      >         MUST be greater than or equal to the start value", which
>     is not
>      >         checked in the Implementation Report.
>      >
>      >      Feature2:
>      >         In Section 2.1.2 of the spec [b], there is a feature "a
>     typical use
>      >         case is expected to be embedding an <emotion> into some other
>      >         markup", which is not checked in the Implementation Report.
>      >
>      >      However, according to the responses so far, we have already
>      >      got the following implementations for the above features.
>      >
>      >      ------------------------------____------------------
>      >
>      >
>      >      Implementation status of the above two features:
>      >
>      >      ------------------------------____------------------
>      >
>      >
>      >
>      >      Feature1: 3 implementations
>      >      - Gerhard Fobe:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0000.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>>
>      >      - Alexandre Denis:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0005.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>>
>      >      - Patrick Gebhard:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0006.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>>
>      >
>      >      Feature2: 4 implementations
>      >      - Gerhard Fobe:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0000.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0000.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0000.html>>
>      >      - Debbie Dahl:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0003.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0003.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0003.html>>
>      >      - Alexandre Denis:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0005.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0005.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0005.html>>
>      >      - Patrick Gebhard:
>      >
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Nov/__0006.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Nov/__0006.html
>     <http://lists.w3.org/Archives/Public/www-multimodal/2013Nov/0006.html>>
>      >
>      >      As I reported in October [c], we have already fixed typos in
>     the spec
>      >      and added necessary clarifications to it.  Also we have
>     fixed the
>      >      errors in the EmotionML schema.
>      >
>      >      So I would like to confirm that it is the time for us all to
>     go ahead
>      >      and publish EmotionML as a W3C Recommendation.
>      >
>      >      Alexandre (as the original commenter), is that OK by you?
>      >
>      >      [a] http://www.w3.org/2002/mmi/____2012/emotionml-irp/
>     <http://www.w3.org/2002/mmi/__2012/emotionml-irp/>
>      >      <http://www.w3.org/2002/mmi/__2012/emotionml-irp/
>     <http://www.w3.org/2002/mmi/2012/emotionml-irp/>>
>      >      [b] http://www.w3.org/TR/2013/PR-____emotionml-20130416/
>     <http://www.w3.org/TR/2013/PR-__emotionml-20130416/>
>      >      <http://www.w3.org/TR/2013/PR-__emotionml-20130416/
>     <http://www.w3.org/TR/2013/PR-emotionml-20130416/>>
>      >      [c]
>      >
>     http://lists.w3.org/Archives/____Public/www-multimodal/__2013Oct/__0010.html
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html>
>      >
>      >
>      >
>     <http://lists.w3.org/Archives/__Public/www-multimodal/2013Oct/__0010.html
>     <http://lists.w3.org/Archives/Public/www-mu