W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2005

Review Notes: Assigning Media Types to Binary Data in XML

From: Addison Phillips <addison.phillips@quest.com>
Date: Tue, 22 Feb 2005 11:23:50 -0800
Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A55766E@irvmbxw01.quest.com>
To: <public-i18n-core@w3.org>
My notes:

Doc purpose. The purpose of this document is to support including binary data in Web services documents. There are two things that can be declared: a media type for an element that contains binary data (which is base64 or hex encoded) and an "expected" media type for use in applications such as WSDL that need to describe the range of valid media types for a particular use of the element in question (for example, saying that the expected media type is an image/*).

1. section 2.2, "expectedMediaType attribute": is set up to describe an "Accept" header, complete with q (quality) values. Accept-extensions are explicitly not permitted. This has important meaning for us: it means no charset parameter is permitted. Of course, there is the question of whether it makes sense for the expected media type to be constraining the encoding, but it is something that bears consideration.

2. section 3. "Declaring media type for binary data": there are two examples (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.

  a. There should be mention that the charset parameter for text/* types is REQUIRED similar to that in the other binary XML documents.

  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. General observation: this document provides a way to indicate a specific preference for a media type using the expectedMediaType attribute, but doesn't specify other interesting Accept-* meta information. For example, there is no way to specify a specific language (accept-language) or encoding (accept-charset) for that same content. It might be wise to include that information in this specification and not require users to invent their own mechanisms for these items.

That is, consider the difference between:

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

And:

    <xs:complexType name="PurchaseOrderType" 
            type="xs:base64Binary"
            xmlmime:expectedMediaType="application/xml"
            xmlmime:lang="ja"
            xmlmime:charset="utf-8, *"/>



---
Addison

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 Tuesday, 22 February 2005 19:24:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:49 GMT