Re: [EmotionML] implementation release and feedbacks

Hello all,

LORIA/Synalp EmotionML:
Feature1: pass
Feature2: pass

best,
Alexandre



On Thu, Nov 7, 2013 at 12:50 PM, <Felix.Burkhardt@telekom.de> 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:
> www-multimodal@w3.org
>
> EmotionML will then soon become a real recommendation!
>
> Thanks a lot,
> Felix
>
> >-----Ursprüngliche Nachricht-----
> >Von: Kazuyuki Ashimura [mailto:ashimura@w3.org]
> >Gesendet: Montag, 28. Oktober 2013 07:57
> >An: alexandre.denis@loria.fr; www-multimodal@w3.org
> >Cc: Burkhardt, Felix; Samuel.Cruz-Lara@loria.fr
> >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, Felix.Burkhardt@telekom.de 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]
> >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43
> >> *An:* www-multimodal@w3.org; 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
>
>