- From: Alexandre Denis <alexandre.denis@loria.fr>
- Date: Mon, 16 Dec 2013 10:43:26 +0100
- To: ashimura@w3.org
- Cc: Patrick Gebhard <patrick.gebhard@dfki.de>, Felix Burkhardt <Felix.Burkhardt@telekom.de>, Marc Schröder <marcschroeder108@gmail.com>, Roddy Cowie <r.cowie@qub.ac.uk>, Deborah Dahl <dahl@conversational-technologies.com>, gerhard.fobe@s2009.tu-chemnitz.de, Edmon Begoli <ebegoli@gmail.com>, "christian@becker-asano.de (christian@becker-asano.de)" <christian@becker-asano.de>, kazemzad@usc.edu, Tim Llewellynn <tim.llewellynn@nviso.ch>, "www-multimodal@w3.org" <www-multimodal@w3.org>
- Message-ID: <CAPYqdFfJ9Dd9fEZty564597-dokRPZCfCSeHF=chhzYTGP0spQ@mail.gmail.com>
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, >[5] 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), best regards, Alexandre On Mon, Dec 16, 2013 at 6:36 AM, Kazuyuki Ashimura <ashimura@w3.org> 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 <marcschroeder108@gmail.com >> <mailto:marcschroeder108@gmail.com>>: >> >> 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, <Felix.Burkhardt@telekom.de >>> <mailto: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 <mailto: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 >>> <mailto:ashimura@w3.org>] >>> >Gesendet: Montag, 28. Oktober 2013 07:57 >>> >An: alexandre.denis@loria.fr <mailto:alexandre.denis@loria.fr>; >>> www-multimodal@w3.org <mailto:www-multimodal@w3.org> >>> >Cc: Burkhardt, Felix; Samuel.Cruz-Lara@loria.fr >>> <mailto: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 >>> <mailto: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 >>> <mailto:alexandre.denis@loria.fr>] >>> >> *Gesendet:* Donnerstag, 2. Mai 2013 11:43 >>> >> *An:* www-multimodal@w3.org <mailto: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.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 & (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 >
Received on Monday, 16 December 2013 09:44:01 UTC