RE: Members of the I18n WSTF

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. This type is actually more like an IRI
and we think it might be advisable to reference IRI somewhere." ??

>
> 5. How are the URIs matched?  For example, are they case-sensitive?

Is this really a problem?
>
> 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
>
>
> 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 Monday, 30 August 2004 20:33:05 UTC