last call comments from I18N WG on CCXML

Dear Voice Browser WG,

Below please receive the I18N review of CCXML from the
I18N WG. We are sorry that this review is late.
Please send all replies not only to myself, but to the
I18N IG mailing list (w3c-i18n-ig@w3.org).

[1] In all places where the spec uses URIs, IRIs should be used.
     The Schema should already define this by the use of the anyURI type,
     but this has to be pointed out in the text.

[2] There are some provisions for creating a log. In what character
     encoding will this log be written? We suggest to specify an Unicode-
     based encoding such as UTF-8 to avoid encoding propblems.
     (CCXML could log any character, but if an encoding such as
      iso-8859-1 is used, some characters cannot be written out,
      assuming the log file doesn't have an escaping syntax)

[3] How is the language of error messages (reason) determined?
     for example in 6.3.3, 6.3.6, and other places. Different
     languages may be required for communication with the user
     (that could be defined as using the value of xml:lang
      inherited at this point in the document) and for writing
     to a log (that might desirably be in a single language
     even if the server serves users in many different languages).

[4] The xml:lang attribute has to be available on any element
     that can (directly or indirectly) contain natural language
     text. [It should also be made clear that this language info
     doesn't apply to documents pointed to from a CCXML document.]

[5] Section 6.2.2: <meta>
     This section should very clearly state that for CCXML, the
     'encoding' pseudo-attribute in the XML declaration is the
     only way to indicated the character encoding of a document
     in the document itself, and that something like
         <meta http-equiv='Content-Type'
             content='application/ccxml+xml;charset=foo' />
     is prohibited and to be ignored by the client.
     This also applies to http-equiv='Content-Language'.

[6] Section 6.2.6.2 <createccxml> [this comment applies to all
     other cases of URI construction]
     The 'namelist' indicates a list of variables that is sent
     as name/value pairs to the server. How exactly is this done?
     For example, what is the separation character between
     name/value pairs (it should be ';', not '&').
     More specifically, how are variable names that contain non-ASCII
     characters transferred to the server? How are variable values
     that contain non-ASCII characters tranferred to the server?
     We very strongly suggest that the spec make the use of UTF-8
     (plus %-encoding for URIs) mandatory, independent of the encoding
     of the document, otherwise, this will be a mess.
     The other details of the encoding of name/value pairs into URIs
     should also be specified carefully and in full detail.

[7] 6.2.7.2 (and maybe other occasions): Avoid colloquial expressions
     such as 'oops!', which make the spec potentially difficult to
     understand for people not of English mother tongue, and difficult
     to translate. (potential other examples: file name 'gimee').

[8] section 8.2.2: <script>
     after the example using a CDATA marked section, please make clear
     that other means of escaping, if necessary at all, are also
     possible. (in the example, the two occurrences of '<' could be
     replaced by &lt; ???? is it necessary to also replace '>' by
     &gt;????). Or better even, change the example to use these escapes.

[9] Section 8.2.2.2, charset attribute:
     It should be made clear that any charset attribute given in the
     HTTP header, or more generally, any external charset information,
     and after that any charset information in the retrieved document,
     if the document is able to contain and contains such information,
     has priority.

[10] 9.2.3.2, data attribute:
      Why is this limited to US-ASCII? We think that this may be
      an unappropriate restriction.

[11] section 11: there should be examples that show the international
      capabilities of XML and CCXML

[12] vm.vxml: 'voice mail hell' might not be appropriate in some
      cultural contexts


Regards,    Martin.

Received on Wednesday, 21 July 2004 02:15:07 UTC