RE: Members of the I18n WSTF

At 13:29 04/08/30 -0700, Addison Phillips [wM] wrote:

>Comments follow...
>
>One of them is a new i18n concern based on close reading of the document.
>
>Addison
>
>Addison P. Phillips
>Director, Globalization Architecture
>webMethods | Delivering Global Business Visibility
>http://www.webMethods.com
>Chair, W3C Internationalization (I18N) Working Group
>Chair, W3C-I18N-WG, Web Services Task Force
>http://www.w3.org/International
>
>Internationalization is an architecture.
>It is not a feature.
>
> > -----Original Message-----
>
> >
> > -------- Original Message --------
> > Subject: PLEASE REVIEW: Comments on SOAP Resource Rep Header doc
> > Resent-Date: Fri, 27 Aug 2004 00:07:15 +0000
> > Resent-From: public-i18n-ws@w3.org
> > Date: Thu, 26 Aug 2004 17:17:33 -0700
> > From: A. Vine <andrea.vine@Sun.COM>
> > To: I18n WSTF <public-i18n-ws@w3.org>
> >
> >
> >
> > {note to self: When this is ready to go, it should be sent to
> > xmlp-comments@w3.org, copied to wstf, and say that all responses should
> > copy wstf}
> > {We were looking at the last call version, but we think this applies to
> > the CR version.}
> >
> > The Internationalization Web Service Task Force (I18n WSTF) of the
> > Internationalization Working Group (I18n WG) have reviewed the SOAP
>
>Task Force *has*
>
> > Resource Representation Header document and have the following questions
> > and comments.
>
>I think we should have some text to indicate the fact that we know they've
>transitioned to CR before leaping in.
> >
> > 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.
> >
> > 1. In what scenarios would this header be used?  In other words, what
> > prompted the creation of this document?
>
>Let's remove this set of questions. Instead we should make a positive
>statement about what we think the document deals with. For example:
>
>--
>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:
>--
> >
> > 2a. What happens when the resource is textual data in the form of type
> > text/* or application/*+xml?  The charset handling should be discussed
> > here (unless text/*, application/*+xml and other text types are
> > explicitly forbidden).
>
>I think we need to spell out what we're talking about here explicitly. Say:
>
>"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?"
> >
> > 2b. If text types are allowed, what does it mean to have and not have a
> > charset attribute?
> >
> > 2c. 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?
>
>Add to the end: "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."
>
>
>Hmm... I just thought of another i18n concern. The point of the header is to
>transmit the resource to the Web service so that the Web service doesn't
>have to retrieve it over the Web at processing time. If the resource is
>available in multiple langauges and language negotiation is done by the
>resource host, how is that indicated to the receiving service?
>
>Shouldn't there be the possibility of xml:lang on the resource?
>
>Can there be two of the same resource in different languages?
>
> >
> > 3. {Need to change} Related to the above question, we recommend
> > that either:
> >       a. text transport should be forbidden, or
> >       b. a recommendation against text transport this way should
> > be included, or
> >       c. the base64 requirement should be relaxed.
>
>I thought we agreed to dump #3 altogether?
> >
> > 4. URI is not defined in this document.  We recommend that the reference
> >   be IRI, and be defined as {fill in the definition - Martin?}.
>
>I would maybe say:
>
>"The spec refers to URIs in several places. We take this to mean the same
>thing as the XMLSchema type anyURI.

It is defined in the XMLSchema to be of type anyURI, so we take...

>This type is actually more like an IRI
>and we think it might be advisable to reference IRI somewhere." ??

And to make sure there are 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>



> > 5. How are the URIs matched?  For example, are they case-sensitive?
>
>Is this really a problem?

Yes, it is. If you take the two URIs/IRIs in the example above
(Representation-resource and img-src), then do these match
(in the sense that 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?


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

One more comment: The system of adding all previous members of
the WG at the end doesn't scale. Many of the people listed there
may actually never have heard of this document.

Regards,    Martin.


> >
> > 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 06:13:07 UTC