- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Wed, 29 Sep 2004 05:26:12 -0700
- To: <andrea.vine@Sun.COM>
- Cc: <public-i18n-ws@w3.org>
I have some comments... > We also believe that forcing base64 encoding on readable text is a > mistake which will introduce a number of problems, not the least of > which is masking the fact that the inline data needs to be tagged. We > feel it should be strongly discouraged, if not disallowed. I don't agree with this. There is nothing wrong with base64 encoding a text attachment, provided that the content-type and encoding are preserved. Martin's example of determining the encoding only applies to XML and not to other content types, including HTML, and we should point that out: XMLP is making an egregious mistake in implying that charset can be inferred from the content absent the charset parameter in the C-T. Addison Addison P. Phillips Director, Globalization Architecture webMethods | Delivering Global Business Visibility http://www.webMethods.com Chair, W3C Internationalization (I18N) Working Group Chair, W3C-I18N-WG, Web Services Task Force http://www.w3.org/International Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: public-i18n-ws-request@w3.org > [mailto:public-i18n-ws-request@w3.org]On Behalf Of A. Vine > Sent: 2004年9月28日 18:46 > To: Martin Gudgin > Cc: public-i18n-ws@w3.org; xmlp-comments@w3.org > Subject: Re: Issue 501 closed > > > > Dear Martin G. and the XMLPWG, > > The I18n WSTF has discussed your comments and have the following > response (inline): > > Martin Gudgin wrote: > > > Dear Andrea and I18WSTF, > > > > You raised an issue, 501[1] regarding the SOAP Resource Representation > > Header specification[2]. Please note that this issue covers the first 4 > > points in your e-mail[3]. The XMLP working group considered your points > > and has the following response: > > > > Points 1-3: Yes, when using the resource representation header base64 is > > always a requirement, even for textual types. The SOAP envelope itself > > will always be in a single character encoding. The octet stream > > resulting from decoding some base64 text may well be in a different > > character encoding. This is not an issue. The character encoding in use > > for such data may be determined in a number of ways, including, but not > > limited to; specifying the charset as part of the xmime:contentType > > attribute (e.g. text/xml; charset=iso-8859-1 ), examining the XML > > declaration for XML based types (e.g. <?xml version='1.0' > > encoding='iso-8859-1' ?>, using the algorithm defined in Appendix F of > > the XML 1.0 Recommendation for XML based types, assuming a default > > character encoding defined by the specification of the media type. > > While we who work in i18n every day are well aware of the ways of > declaring charset, most people are not. If it is not mentioned in the > standard, the likelihood of it being done is very slim. Since we > believe there is a minimal amount of information necessary to process > data, and that information is, for text, charset and in some cases > language, we feel that this needs to be described in this context. > > We also believe that forcing base64 encoding on readable text is a > mistake which will introduce a number of problems, not the least of > which is masking the fact that the inline data needs to be tagged. We > feel it should be strongly discouraged, if not disallowed. > > The benefit of making this very basic information a standard is to allow > ease of interoperability, which is the goal of standards in general. > Text is the most basic of data exchanged, and without proper tagging > it's not reliably processed. > > We believe that for the reasons stated above, this should be covered in > the test suite. > > > > > Point 4: xml:lang is not appropriate for use on the rep:Data element as > > base64 is not human-readable text. A SOAP message can carry multiple > > instances of the resource representation header and many such headers > > may carry representations of the same resource. Thus a given SOAP > > message could carry multiple representations of a given resource, each > > one in a different human readable language. The resource representation > > header has an extensibility mechanism that allows additional attributes > > to be specified. Such an attribute could be defined to indicate the > > human readable language of a text based resource. We note that there is > > an example of how to use this extensibility mechanism in Section > > 4.4.3[5] of the CR version of the Resource Representation SOAP Header > > Block specification[4] > > We believe that at a minimum precedence rules need to be specified for > determining the language of included data. For example, do the MIME > headers take precedence over the HTTP headers? > > Again, mention of this issue and firm recommendations for how to handle > it would enhance interoperability significantly. > > Andrea Vine > Sun Microsystems > For the I18n WSTF > > > > > The working group does not expect to change the Resprentation header > > specification as a result of closing this issue. > > > > Regards > > > > Martin Gudgin > > Microsoft Corp. > > For the XML Protocol Working Group > > > > [1] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x501 > > [2] http://www.w3.org/TR/2004/WD-soap12-rep-20040608/ > > [3] http://lists.w3.org/Archives/Public/xmlp-comments/2004Sep/0000.html > > [4] http://www.w3.org/TR/2004/CR-soap12-rep-20040826/ > > [5] http://www.w3.org/TR/2004/CR-soap12-rep-20040826/#rep-http-headers > > > > -- > The trouble with the world is that the stupid are cocksure and the > intelligent are full of doubt. -Bertrand Russell, philosopher, > mathematician, author (1872-1970) > [...shouldn't that end with "or maybe not?"]
Received on Wednesday, 29 September 2004 12:23:57 UTC