RE: Issue 501 closed

Martin,

Please see issue 502[1] which contains the IRI comments, the XMLP WG
just split the e-mail into more manageable chunks. Other comments
in-line.

Gudge

[1] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x502

> -----Original Message-----
> From: Martin Duerst [mailto:duerst@w3.org] 
> Sent: 24 September 2004 09:04
> To: Martin Gudgin; andrea.vine@sun.com; public-i18n-ws@w3.org
> Cc: xmlp-comments@w3.org
> Subject: Re: Issue 501 closed
> 
> Hello Martin,
> 
> This is just a personal reply, an official reply from our 
> group is forthcomming.
> 
> First, I wanted to point out that there seems to be a serious 
> transcription error at 
> http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x502.
> Virtually all of the IRI examples is gone. Please go back to 
> http://lists.w3.org/Archives/Public/xmlp-comments/2004Sep/0000.html
> and copy the full examples into your issues list.
> 
> At 08:31 04/09/22 -0700, 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.
> 
> Do you have any tests in your test suite? Given that, as we 
> both know, there are that many way to indicate the character 
> encoding, there are even more ways to get this wrong. That's 
> why I think that disallowing including text as base64 is the 
> cleanest solution, and absent that we really need a bunch of 
> tests to make sure that this doesn't produce a big mess. 
> Overall, it's difficult to see why we need to re-encode text 
> as base64 and start again with all the encoding problems when 
> XML already solves these issues.

We don't *need* to encode text based media types as base64. But people
are not disallowed from doing so. We don't have any specific tests for
this although I would observe that some of the MTOM test messages do
contain 'textual' binary parts and they were processed correctly by the
various parties. I expect that some of the messages in the Resource Rep
tests will be similar and I expect similar successfuly results.

The main point is, it is no *more* difficult to figuring out the
encoding of a resource with a text or XML based media type that you
retrieved directly over HTTP.

Gudge

> 
> Regards,    Martin.
> 
> 
> 
> >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]
> >
> >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
> 
>

Received on Friday, 24 September 2004 10:39:32 UTC