W3C home > Mailing lists > Public > xmlp-comments@w3.org > September 2004

Re: Issue 501 closed

From: Martin Duerst <duerst@w3.org>
Date: Fri, 24 Sep 2004 17:04:21 +0900
Message-Id: <>
To: "Martin Gudgin" <mgudgin@microsoft.com>, <andrea.vine@sun.com>, <public-i18n-ws@w3.org>
Cc: <xmlp-comments@w3.org>

Hello Martin,

This is just a personal reply, an official reply from our group is

First, I wanted to point out that there seems to be a serious
transcription error at
Virtually all of the IRI examples is gone. Please go back to
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.

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.
>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 08:04:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:00 UTC