RE: mgm Comments on I18n Usage Scenarios, 4.0 - 4.1.3.3

See notes below. Some elision for clarity.

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

AP> 4.1.1 locale neutral was changed as noted


"Time of day, although it is presented with different formats around the
world, is measured the same way everywhere and a standardized single frame
of reference is available to be used."
       maybe change to:
Time of day, although it is presented with different formats and perhaps
different calendars around the world, if using a standardized method is
measured the same way everywhere and a single frame of reference is
available to be used.

AP> See new edits, which are pretty close to this.

"... including shifting the time into the local time zone."
       maybe change to
"... including shifting the time into the local time zone or even a local
calendar, e.g., Arabic or a Japanese imperial calendar.

AP> The example explicitly references only time-of-day. Are there any cases
where calendar would play into this?

AP> I can think of one thing additional thing (not added), which is that we
might reference the use of 24hour vs. am/pm.

4.1.1.2

... does not require extra locale information ...

AP> Changed to "The Web service description does not need to include extra
locale information..."

4.1.1.3

No additional locale attributes or information are required for this pattern
a locale neutral service.

AP> Changed to "No additional locale attributes or information are required
for the locale neutral pattern."


4.1.2
-----

"This may be due to how the service's code is written, how the provider is
configured ..." => awk, how about
"This may be due to the way the service's code is written, the provider's
configuration ...", or,
"This may be due to the way the service's code is written, the way the
provider is configured ..."
4.1.2

... the service provides a specific localized set of behaviors ...  => how
about
... the service provides a set of specific localized behaviors ...

AP> See new text...


4.1.2.1
-------
This is not really that huge of an example.  But we could simplify it -
order processing in local language only, one and only one service/wsdl
provided per locale due to locale processing limitations.

AP> How about something altogether simpler: list the names of the days of
the week. Sort this list of strings.... We should discuss this block of
stuff.

Add "GetProductInventory" as a name for the service.  See notes to 4.1.3.1

AP> Changed as follows:

<head>Example: 'GetProductInventory' Service Returns List of Products in
Stock</head>
<p>A company is in 3 markets: the United States, Japan, and Germany.
Each market is supported by a local warehouse.
A Web service, 'GetProductInventory', is provided to indicate the
availability of parts.
For a given part number, the following information is returned:
part number, quantity, language, description, size, and list price.</p>


// removal of Andrea's remarks about use of booze in example
I've got a good example I use: "wrench".  Tools (and vegetables) are great
because they really are different between almost every locale. Here are a
few translations:

AP> ... to be discussed...

Are there still systems with 7-bit ASCII (answer: Cobol is still alive :-( )

AP> Not sure that we want to deal with this here. We have scenarios later??


// removed Andrea's comments not commented upon

4.1.2.2

It is unclear from the introduction to this section that you have one and
only one service/wsdl per supported locale.  Perhaps we should make a simple
statement to that fact.

AP> Might not be true. Can have several bindings in one WSDL, each with a
different locale on its endpoint... Maybe should say both??

4.1.3

"... locale preferences specified by the user ... user's ...."  maybe change
to "... locale preferences specified by the client. ... client's ..."  The
client my be human, or it may be another application or service.
Ultimately, there is a human somewhere at the end-point,  but I prefer
"client" for these descriptions.

"The service should therefore provide a way for the user's client's locale
preferences to be communicated to the service and, if there is a response,
the actual locale values used to perform the processing should be returned
to the client."

AP> How about (for symmetry with Service Determined):
--
"In the Client Influenced pattern, the service provides a specific set of
localized behaviors which which are tailored according to the locale
preferences in the request. The service therefore requires a way for the
requester to communicate the preferences and, if there is a response, the
actual value used to perform the processing."
--

// more removal

"GetProductInventory" does not appear anywhere else in the doc.  It looks
like it is refering to the example in 4.1.2.1.  Therefore, we should add
"GetProductInventory" to 4.1.2.1 example.

AP> Added ref as noted above.

Same comment on "user" vs. "client"

AP> ... vs. requester. Need to tighten this language.



"Really this is something the provider should provide, ..." need to clarify
why this is so, even if it's a reference to another section in the doc.
(nit) I would remove "Really"

AP> Done.



--
Michael McKenna
Globalisation Architect
mgm@globalisation.org

California Digital Library
University of California Office of the President
michael.mckenna@ucop.edu
http://www.cdlib.org

Received on Tuesday, 27 January 2004 17:16:53 UTC