Re: Updated comments on SOAP RRH doc

Hello Andrea,

This looks great. I'd suggest to start with something like
"Dear XML Protocol Working Group" or so. Some very small
comments below, and please send the doc off soon.

Regards,    Martin.

[please use your original and not this mail to send the stuff;
here the Kanji got garbled, because my mailer doesn't deal with
UTF-8 :-(]

At 12:23 04/09/01 -0700, A. Vine wrote:

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

I'd reword the last sentence and say something like:

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'
>                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/$BifRiX!(B.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/$BifRiX!(B.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://$Bh@5(Borg/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://$Bh@5(Borg/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

matches -> match


>(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 Thursday, 2 September 2004 00:42:21 UTC