- From: Michael Johnston <johnston@research.att.com>
- Date: Fri, 04 Aug 2006 14:03:19 -0400
- To: public-i18n-core@w3.org
- Cc: www-multimodal@w3.org
Dear Internationalization Working Group, The Multimodal Interaction working group have considered your comments on the EMMA last call working draft in some detail. Your comments proved to be extremely useful and led to a whole series of revisions and clarifications in the current editor draft of the specification. Responses to the individual comments are detailed below. Many thanks for all of your comments. We look forward to any further discussion. Best regards, Michael Johnston (editor-in-chief for EMMA specification, Multimodal Interaction working group) RESPONSE TO FEEDBACK ON EMMA FROM i18n INTERNATIONALIZATION =========================================================== Feedback: http://www.w3.org/International/2005/10/emma-review.html on draft: http://www.w3.org/TR/2005/WD-emma-20050916/ 1. General and sec. 4.2.5: Reference to RFC 1738 ------------------------------------------------------------------------- RFC 1738 is obsoleted by RFC 3986 (URI Generic Syntax). It would be good if you could refer to RFC 3986 instead of 1738. The best thing would be if you could add a normative reference to RFC 3987 (Internationalized Resource Identifiers (IRIs). Response: ACCEPT Agreed, document has been revised as suggested. 2. General: Reference to RFC1766 -------------------------------------------------- RFC 1766 is obsoleted by 3066 (Tags for the Identification of Languages). What is essential here is the reference to a BCP (best common practice), which is for language identification BCP 47. Currently bcp 47 is represented by RFC 3066, so could you change the reference to "IETF BCP 47, currently represented by RFC 3066"? Response: ACCEPT Agreed, document has been revised as suggested. 3. General and sec. 2.4.1: References to XML and XMLNS ------------------------------------------------------------------------------------- As for XML, you reference version 1.0. As for XMLNS, you reference version 1.1. Is there a reason for the mismatch of the versions? Response: ACCEPT Thank you for pointing this out. We have updated the specification to reference XML 1.1 and XMLNS 1.1. 4. Sec. 1.2, definition of "URI: Uniform Resource Identifier" ------------------------------------------------------------------------------------ Here you refer to XML Schema for URIs. It would be good if you could also refer to the underlying RFCs (see comment 1). Response: ACCEPT Agreed, document has been revised as suggested. 5. Sec. 2.2 or sec. 4.1.5 and other places --------------------------------------------------------------- On terminology: Please reference standards like XForms RELAX-NG, SIP, TCP, SOAP, HTTP, SMTP, MRCP etc. if you mention them. Response: ACCEPT Agreed, although in most cases these would be informative references rather than normative ones. 6. Sec 2.2 --------------- Your list of data models is a little bit confusing. A proposal: List the DOM, the infoset and the XPath 2.0 data model. Response: NEED MORE INFORMATION Section 2.2 is about the use of constraints on the structure and content of EMMA documents. Your comment seems to be more related to the data model exposed to EMMA processors. 7. Sec 2.3 --------------- On terminology: "An EMMA attribute is prefixed ..." should be "An EMMA attribute is prefixed (qualified) ...". Also: "An EMMA attribute is not prefixed ..." should be "An EMMA attribute is not prefixed (unqualified) ..." Response: ACCEPT Thanks for pointing this out. We have investigated the use of these terms in recent specifications and revised the EMMA specification 2.3 as follows to clarify the terminology: "An EMMA attribute is qualified with the EMMA namespace prefix if the attribute can also be used as an in-line annotation on elements in the application's namespace. Most of the EMMA annotation attributes in Section 4.2 are in this category. An EMMA attribute is not qualified with the EMMA namespace prefix if the attribute only appears on an EMMA element. This rule ensures consistent usage of the attributes across all examples." 8. General: expressing requirement levels ------------------------------------------------------------- Have you thought of using RFC 2119 to indicate requirements levels (e.g. with "must", "should", "must not" etc.)? Response: ACCEPT Agreed, in response we have conducted an extensive review of the document revising language as needed and adding in capitalization in accordance with RFC 2119. Also added of a small paragraph near the beginning of the document indicating this. 9. Sec. 4.2.15 on references to a grammar -------------------------------------------------------------- You identify a grammar by an URI. It might also be useful to be able to say "just a french grammar", without specifying which one. That is, to have a mechanism to specify the relations like general vs specific between grammars. Response: REJECT We do not see any important use cases addressed by this potential feature. Specifically, we don't believe that specifying 'just a french grammar' would provide sufficient additional information over and above the information provided by the 'emma:lang' attribute to make it worth adding. This is due to the fact that it is only through successful processing using a language-specific grammar that the processor can identify the language used by the speaker in the first place. 10. Reference to RFC 3023 (MIME media types), e.g. in appendix B.1 ----------------------------------------------------------------------------------------------------- Work is undertaken for a successor of RFC 3023. To be able to take its changes into account, it would be good if you could change the reference to RFC 3023 to "RFC 3023 or its successor." Please have a look at How to Register an Internet Media Type for a W3C Specification. Response: ACCEPT Agreed, document has been revised as suggested. 11. Reference to RFC 3023 in appendix B.1, on security considerations ------------------------------------------------------------------------------------------------------- Please refer to the security considerations mentioned in RFC 3987. Response: ACCEPT Agreed, document has been revised as suggested. 12. General ------------------------------------------------------------------------- It would be good if you could make a clearer difference between normative and non-normative parts of the specification. Response: ACCEPT Agreed, we have reviewed and reorganized the document so that normative vs informative sections are clearly marked. 13. Sec. 4.2.1 on tokens ---------------------------------------------------------------- Is it possible to apply the emma:lang annotation also to tokens? Response: REJECT There is no language associated with the contents of emma:tokens. In many cases, this attribute value will not be meaningful to the casual reader. For instance, it may describe the phonemes or phonetic units for speech recognition. Proper nouns or shared words such as 'no' in English and Spanish may appear in the grammars for several languages, though the meaning may be identical and the system may not care which language applied. It is proper to say that emma:tokens and emma:lang provide information about the user's input but not that emma:lang describes the language of the contents of emma:tokens.
Received on Friday, 4 August 2006 18:03:32 UTC