Re: Comments from the i18n core wg on EMMA

Dear Michael, all,

Thank you very much for your replies. Personally, I am satisfied with
them. I have only one comment, see below. If you don't hear from the
i18n core WG in the next weeks, please regards
the group as satisfied. Please only bear in mind that in August many
from the WG are in vacation and might want to reply in early September.

Regards, Felix.

Michael Johnston wrote:
> 
> 
> 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.

I decided to withdraw my comment.

> 
> 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.
> 
>