Re: Comments from the i18n core wg on EMMA

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:30 UTC