RE: Comments on I18n Usage Scenarios, 4.0 - 4.1.3.3

Hi Andrea,

Thanks for the comments. I made changes as noted below... some of the
changes were more extensive than your suggestions. These are as noted. New
version online.

> 4.1.1
> ------
> Switching back and forth from "locale neutral" to "language neutral" is
> confusing and will make people think that they are
> interchangeable.  If we want
> to take on both cases, we should talk about them both and explain
> the the terms.

This was sloppy. Original:

<quot>A language neutral service generally is one that executes in the same
way regardless of the current runtime locale or user preferences regarding
language. This implies that all or most strings embedded in the service are
not human readable. This is, by far, the most common pattern. In a language
or locale neutral service, external factors do not alter the way the service
performs. An example of this would be a service that adds two integers
together: 2+2 = 4 in most every locale.

Language neutral services, being the default, do not generally announce
themselves in their service contracts, although (other scenarios apply
here).
</quot>

I would propose this as a replacement:

<quot>
<p>A locale neutral service is one that executes in the same
way regardless of the locale applied to the service. An example of this
would be a service that adds two integers together: 2+2 = 4 in every
locale.</p>

<p>This suggests that strings embedded in the service are not human readable
and that data processed by the service is not being handled in a culturally
sensitive way. </p>

<p>Locale neutral services, being the default, do not generally need to
announce
their locale  in their service contracts, although information about the
locale
or language preference of the requester may still be useful in a variety of
cases.</p>
</quot>


>
> 4.1.1.1
> -------
> We should clarify that this example implies there are no returned
> error messages or responses with any verbiage.

I think we can leave out error messages, since these are dealt with
elsewhere. I modified the example to make the "no text" point clear, as
follows:

<p>For example, the service response would contain a single value
'currentTime' using the current
UTC (Coordinated Universal Time) time in the ISO 8601 format: hh:mm:ss.sss,
mandated by the
<xspecref href="...">time</xspecref> datatype in  XML Schema
Part 2: Datatypes <bibref ref="XMLS-2"/>.</p>

This makes it clear that the response in the example does not have a text
field. (Okay, it doesn't say "no text", but it is an example of a service
which has no text... is that good enough?)

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

Agreed. Changed these paragraphs as follows:

<p>In the Service Determined pattern, the service provides a specific
localized set of behavior determined prior to the request.</p>

<p>That is, the service does something in a culturally sensitive or
locale affected way. The locale used in this processing is inherent
in how the service is implemented or configured. For example, it
might be the default locale of the system where the service is running. </p>

<p>It may also be a configuration option of the service, provider,
or provider agent. One example of this would be a service that provides
several
bindings, each with a separate locale.</p>

<p>The preferences of the requester do not influence how the service
executes and may not influence aspects of the service such as the
language of messages returned and so forth.</p>
>
> 4.1.2.1
> -------
> Note:  Alcohol is a risky example, due to cultural attitudes to
> alcohol in some
> parts of the world.  I suggest something less controversial, say, office
> objects, or vegetarian food items, or simple household objects.
> How about
> noodles?  The US item could be "egg noodles", the German one
> "Spätzle", and the
> Japanese one "udon". (Can you tell I'm hungry?)

This is an awful example: it is too large for the purpose it has been given.
Before I SAR beers with noodles, we should discuss replacing it altogether
with a smaller example.

>
> "... part number, quantity, language, description, size, list price."
>                                                          ^and

Done.

> "If all of the information was maintained ..." =>
> "If all of the information is maintained ..." or, less preferable,
> "If all of the information were maintained ..." (yes, English has a
> subjunctive/conditional tense)

Done.
>
> "budweiser" => "Budweiser" (but again I strongly advise against
> alcohol in any
> example)
> "kirin" => "Kirin"

Done.
>
> " ... it's capabilities are limited ..." => "its"

Done.
>
> " ... the service could still not offer product from ... "
>                                                 ^s

Done.
>
> 4.1.3.1
> -------
>
> " ... with Japanese language description."
>                                          ^s

Done.
>
> "web" => "Web" (throughout doc)

Done. SAR found four such.
>
> 4.1.3.2
> -------
> "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.

There is already a note to that effect here.
>

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