I18N Comments on: Assigning Media Types to Binary Data in XML

Dear XMLP/WSD WGs,

The Internationalization Core Working Group has a few comments on your recent Last Call document "Assigning Media Types to Binary Data in XML". We apologize for the lateness of the comments and hope that you will find them useful.

1. section 2.2, "expectedMediaType attribute": is set up much as if it were an "Accept" header, complete with q (quality) values. Accept-extensions are explicitly not permitted, nor are additional content selection attributes provided. 

We think that it might be important that the remainder of the Accept-* set of content negotiation headers be provided for here. Of particular interest to I18N are the equivalents to HTTP's Accept-Language and Accept-Charset headers. These values may be important in describing in a Web service the preferences or capabilities of the service provisioned at the end point.

For example: a Web service that performs spell checks might only support content in a specific language. Or a particular device (such as a mobile phone) might support only a limited range of encodings. The ability to provide meta data about the character of the content that can be sent (either informatively to the end user or because content not matching the value will be rejected) seems like an important capability to consider.

Also it is possible to imagine services that will use this information to perform HTTP requests on behalf of the service provider.

That is, consider the difference between:

    <xs:complexType name="PurchaseOrderType" 
            type="xs:base64Binary"
            xmime:expectedMediaType="application/xml"/>

And:

    <xs:complexType name="PurchaseOrderType" 
            type="xs:base64Binary"
            xmime:expectedMediaType="application/xml"
            xmime:acceptLang="ja"
            xmime:acceptCharset="utf-8, *"/>

2. section 3. "Declaring media type for binary data": there are two examples in-line in the text (one is image/png and the other is text/xml;charset=utf-16). The XML example is good, in that it uses a charset parameter. However, we note:

  a. There should be mention that the charset parameter for textual types is STRONGLY RECOMMENDED similar to that in the other binary XML documents. Cf. [1], which says: 

    <q> If the media type identified by the value of an xmime:contentType  attribute information item is a text based media type then the value of the xmime:contentType  attribute information item SHOULD include a charset parameter.</q>

  b. There should probably be an example of the charset parameter in use. The examples (quite properly) use a binary image as an example, but it is entirely probable that this mechanism will be used to send content such as HTML or XML documents too.

3. We note that the document uses the namespace prefix 'xmlmime'. Isn't this prefix illegal per XML Namespaces (http://www.w3.org/TR/REC-xml-names/#xmlReserved)? Perhaps another prefix should be used, such as 'xmime' as in the quote from [1] above.

Best Regards (for the I18N Core WG),

Addison

[1] http://www.w3.org/TR/2005/REC-soap12-rep-20050125/



Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com


Chair, Internationalization Core Working Group
http://www.w3.org/International


Internationalization is not a feature.
It is an architecture.

Received on Wednesday, 23 February 2005 04:58:28 UTC