RE: Issue 501 closed

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