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

RE: Issue 501 closed

From: Martin Duerst <duerst@w3.org>
Date: Tue, 28 Sep 2004 09:23:56 +0900
Message-Id: <4.2.0.58.J.20040928091616.03155ea0@localhost>
To: "Martin Gudgin" <mgudgin@microsoft.com>, <andrea.vine@sun.com>, <public-i18n-ws@w3.org>
Cc: <xmlp-comments@w3.org>

At 03:39 04/09/24 -0700, Martin Gudgin wrote:

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

Please don't tell me to look at issue 502 when I'm trying
to tell you that something is wrong in issue 502.
Fortunately, for whatever reason, 502 is fixed. Thanks.


>Other comments in-line.

Same here.


>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.

Any pointers?


>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.

The main point from our side is that it's a very bad idea to garble
text as base64 when it can be sent directly.
A second point is that however simple some rules may be (and in this
case, they aren't simple), additional combinations most often lead
to additional unclarities, bugs, or whatever.


Regards,   Martin.

>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 Tuesday, 28 September 2004 03:13:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:28 GMT