RE: Members of the I18n WSTF

Reviewing it's on my list of things to do today. I'd be happy to send over
my signature if you prefer.

Others...?

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-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of A. Vine
> Sent: Monday, August 30, 2004 11:01 AM
> To: I18n WSTF
> Subject: Members of the I18n WSTF
>
>
>
> All,
> If you don't provide me any feedback, I will not send this note.  I have
> received none.  Not one.  There are a couple of holes that need to be
> filled in.  Most of the opinions expressed in this document are not
> mine, and I don't feel IN THE LEAST bit comfortable sending anything
> like this with out SOME KIND OF FEEDBACK.
> If someone else wants to send and sign their name to it, my feedback is
> already written in.
> Andrea
>
> -------- 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
> Resource Representation Header document and have 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.
>
> 1. In what scenarios would this header be used?  In other words, what
> prompted the creation of this document?
>
> 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).
>
> 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?
>
> 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.
>
> 4. URI is not defined in this document.  We recommend that the reference
>   be IRI, and be defined as {fill in the definition - Martin?}.
>
> 5. How are the URIs matched?  For example, are they case-sensitive?
>
> 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 18:01:15 UTC