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

Comments on SOAP Resource Representation Header document

From: A. Vine <andrea.vine@sun.com>
Date: Thu, 02 Sep 2004 16:52:37 -0700
To: xmlp-comments@w3.org
Cc: I18n WSTF <public-i18n-ws@w3.org>
Message-id: <4137B245.9020707@sun.com>

** All responses should copy the I18n WSTF **

Dear XML Protocol Working Group,

The Internationalization Web Service Task Force (I18n WSTF) of the
Internationalization Working Group (I18n WG) has reviewed the SOAP
Resource Representation Header document and has the following questions
and comments.

Note that we have only reviewed this document, and not yet XOP nor MTOM,
and some of the things discussed here may apply to them.  Note also that
we were looking at the last call version, and are aware that these
documents have transitioned to CR.  We think that our comments are 
significant, and can be addressed in the CR (implementation/testing) phase.

In reviewing this document, our assumption was that the primary purpose
of the Resource Representation header is the transmission of binary
objects, such as images, within the body of a SOAP request, as an
alternative to retrieving the resource over the Web. The point here
would be to transmit data that would be useful to the receiving service
or provider without the overhead of an attachment. The main
internationalization concerns related to this are:

1. What happens when the resource in the rep:Data element has an
xmlmime:contentType attribute for a textual type, such as text/* or
application/*+xml?  The charset handling should be discussed
here (unless text/*, application/*+xml and other text types are
explicitly forbidden).

2. If text types are allowed, what does it mean to have and not have a
charset attribute?

3. If text types are allowed, is base64 still a requirement?  What
happens when you have the SOAP document in one charset and the SOAP RRH
with a text document in another charset?  While we understand that
requiring the base64 type simplifies processing and avoids unnecessary
character encoding processing, it does introduce some additional
opportunity for encoding mismatches to occur.

4. What heppens when the resource in question is available in multiple
languages?  If the language negotiation is done by the resource host,
how is that indicated to the receiving service?  There should be the
possibility of xml:lang on the resource.

5. The spec refers to URIs in several places. It is defined in the
XMLSchema to be of type anyURI, so we take this to mean the same thing
as the XMLSchema type anyURI. This type is actually more like an IRI and
we think it might be advisable to reference IRI somewhere.  There should
also be test cases for IRIs.  For example (assuming the actual document
is encoded in UTF-8), the following should be legal:

<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope'
     <rep:Representation resource='http://example.org/写真.png'>
       <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
     <x:MyData xmlns:x='http://example.org/mystuff'>
       <x:name>John Q. Public</x:name>
       <x:img src='http://example.org/写真.png'/>

Also, the following should be legal:

<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope'
     <rep:Representation resource='http://例.org/me.png'>
       <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
     <x:MyData xmlns:x='http://example.org/mystuff'>
       <x:name>John Q. Public</x:name>
       <x:img src='http://例.org/me.png'/>

6. How are the URIs matched?  For example, are they case-sensitive?  If
you take the two URIs/IRIs in the example above, Representation-resource
and img-src, then do the following pairs match? (here the image data is 
actually taken from the data in the header, rather than reported as 'not 

1) http://example.org/me.png         http://example.org/me.png
2) http://example.org/me.png         HTTP://example.org/me.png
3) http://example.org/me.png         http://Example.org/me.png
4) http://example.org/me.png         http://example.org:80/me.png
5) http://example.org/~me.png        http://example.org/%7Eme.png
6) http://example.org/%7Eme.png      http://example.org/%7eme.png

These are only some of the simpler examples that are not clear at all.
Namespaces say that only 1) matches. RDF does the same. When actually
resolving, all of these will go to the same place on the same server.
So what happens in the case of this spec?

7. To avoid requiring that all SOAP senders understand the HTTP caching
mechanism, we recommend that all the data required by a processor that
wants to act as a local cache needs to be carried along with the
message. This includes the complete request/reply as well as the time
the original HTTP request has been sent and the time the HTTP response
has been received.

8. How are error conditions handled?  For example, what to do in the
case of an HTTP 404?

Below are some basic edits:

2.1 Introduction

occurences => occurrences (2 places)
several representation => several representations

2.2.1 rep:Representation element

"One or more attribute information items amongst its [attributes]
property as follows:"
"One or more attribute information items amongst its [attributes]
properties as follows:"
(not clear as written, is it an "attributes property"?  If so, it can't
be "amongst" a single thing.  Same comment for section 2.2.4)

"One or more element information items in its [children] property in
order as follows:"
"One or more element information items in its [children] properties in
order as follows:"
(not clear as written, is it a "children property"?)

"with a [namespace name] different than"
"with a [namespace name] different from"

2.2.4 rep:Data element
(Same comments as in 2.2.1)

2.3 Extensibility of the Representation header block
"several possible usage" => "several possible usages"

2.3.3 HTTP headers
"... all SOAP senders understand HTTP caching mechanism"

Andrea Vine
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 Thursday, 2 September 2004 23:42:16 UTC

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