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

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

From: Addison Phillips <addison.phillips@quest.com>
Date: Thu, 24 Feb 2005 14:33:12 -0800
Message-ID: <634978A7DF025A40BFEF33EB191E13BC0A5584C4@irvmbxw01.quest.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>
Cc: <public-i18n-core@w3.org>

Thanks! Please let us know if you need any additional information from us on these issues.

Best Regards,

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. 

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: 2005?2?24? 14:25
> To: Addison Phillips; Yalcinalp, Umit; Anish Karmarkar
> Subject: RE: I18N Comments on: Assigning Media Types to Binary Data in XML
> 
> I added these to the issues list at
> http://www.w3.org/2002/ws/desc/2/06/issues.html.
> 
> I expect these to be closed quickly next week as a mix of editorial and
> duplicative of decisions already taken.
> 
> > -----Original Message-----
> > From: public-ws-media-types-request@w3.org [mailto:public-ws-media-
> > types-request@w3.org] On Behalf Of Addison Phillips
> > Sent: Tuesday, February 22, 2005 4:46 PM
> > To: public-ws-media-types@w3.org
> > Cc: public-i18n-core@w3.org
> > Subject: 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 Thursday, 24 February 2005 22:33:58 GMT

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