Updated comments on SOAP RRH doc

I incorporated Addison's & Martin's comments.

{note to self: When this is ready to go, it should be sent to
xmlp-comments@w3.org, copied to wstf}

** All responses should copy the I18n WSTF **

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 feel that our comments are 
significant and need consideration, regardless of the change in status.

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'
                xmlns:rep='http://www.w3.org/2004/08/representation'
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
   <soap:Header>
     <rep:Representation resource='http://example.org/写真.png'>
       <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
     </rep:Representation>
   </soap:Header>
   <soap:Body>
     <x:MyData xmlns:x='http://example.org/mystuff'>
       <x:name>John Q. Public</x:name>
       <x:img src='http://example.org/写真.png'/>
     </x:MyData>
   </soap:Body>
</soap:Envelope>

Also, the following should be legal:

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

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 these matches (here the image data is actually 
taken from the data in the header, rather than reported as 'not found'):

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"
                                 ^the


Regards,
Andrea Vine
W3C I18n WSTF
-- 
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, 1 September 2004 19:43:05 UTC