Locale dependency in locale independent data. Guessing the nature of
handling legacy data is not in the scope of our TF.

3 locales: Sender's locale, Receiver's locale, and locale to describe
where the event happens. For instance, Sender sends Airplane departure
time to receive, and in this case, the location of the airport would
likely be what's associated with the departure time, but not sender's or
receiver's locale.

Do we need use case for sender's precision about data format on
receiver's side (i.e. decimal places)?

Formatting, Unit of data, what to do with the unit. Process is what to
do with its relationship

Problem in the past: Server locale was allowed to influence the
data.

Best practice vs. requirements. (i.e. Data structuring, price field
with no currency. don't think we can prohibit. This is an example of best
practice which is very nice to do, but we cannot force.)

Discussions about Activity proposals

We could spend more time on use case

Layout of upcoming activities

Define how to develop i18n web services, and possibly make it
standards

Come up with use cases and may publish "Best practices guide" document,
possibly make it Recommendation.

Reviewing existing web services

SOAP doc review

WDSL requirements review

Petitioning our work items maybe needed to work in parallel?

Define what not to do, but still needs to be done in the future.

Categorize use cases, coming up with models/generalized categorization.
When to implement? Not likely be working on it before the end of this
year, but in the following one.

Extensibility, length measurement

Two different targets: Creating new web services and Dealing with
existing web services

Do we need XML code in the usage scenarios? They are being used to
demonstrate the locale dependencies. Some may be too suggestive, some
could be helped with graphics/pictures. Any one of them we want to
eliminate? To be reviewed later.

IUC: Common XML locale format, an open source repository for locale
data. Does it make sense to change formats in Unix, Windows, etc.?

Do we need more use cases with these scenarios? Data should be passed
with locale neutral schema.

Long term: What is supposed to happen to locale model, which is
different in various systems

Help people express locale neutral general model, resulting predictable
format. Human readable messages: sender sends data, and receiver returns
error message in the sender's data locale (doc locale). Problem comes
when the receiver cannot recognize the data locale, or when there is
none. Error message may be returned in the receiver's language, and the
sender may not understand it.

This TF needs to define what to cover, and what not to cover. To be
narrowed down. Our main forcus is on Web Services area. We are not going
to go looking for outside of Web Services area. For instance, we will
review SOAP, but we might or might not review XML Schema V2.

The needs for header

Use case requirements

Existing systems that are exchanging proprietary data to use Web
Services.

Some kind of generalized identifier. Need a standardized way to
exchange locale preferences. Most cases data are locale neutral, and
there should be not much needs for exchanging locale preferences.

There is some justification to personalize data. If all services can be
expressed in neutral way, the receiver can decide the format or
personalize it.

Shoe size is an example that to consider different data type. Locale
provides a hint to indicate the size (i.e. if you walk into a shoe store
in Japan, they would go with centimeter system. Online would be an
example that requires data type definition)

Headers, Why needed, what problems are being solved. Declaring too much
in header may be waste as many of them may not be used at all.

Continue to collect use cases

Categorize the each of those.

What qualifies use case?

Requirement for submitting use cases.

Detection, format, scenario definition, description, which often
includes examples.

Type of use cases that we accept. Grouping scenarios.

Boundary cases.

Number of scenarios

What to do to current doc before we can use it as use case examples.

Needs to become in XML format

Title may need to be changed.

Kentatoh to be the primary editor. Martin to talk to him further to
define editing responsibilities between him and Martin.

Still have chance to publish the first WD before the end of
November.

Categorize currently available use case.

Coming up with good name for each scenario

Adding table of contents.

Plan to manage submitted use cases

How submitted use cases need to be triaged.

Following up on the status (not reviewed, reviewed, accepted,
rejected, investigating) of each case

Not over-organize

Schedule

Announce for call, use case submission

Scenarios. Tex: Do we want to create matrix to make sure we are not
missing anything?

Putting pointers to each other.

Review XML protocol, which might give us additional requirements.

Kentaroh's feedback.

What docs to review.

By the first conf-call, that's is being scheduled in 2 weeks, we will
clean up the use case doc, and publish for call.

Addison to reply to the mail with his notes, and ask for any other
comments

Martin to send out comments as official response from our TF.

Part of issues discussed (Addison and Martin took notes for our
reply to them)

Issue 257: Solution Accepted

Issue 259: Problem is that EN-US docs usually don't have EN-US
tag.

SOAP Accept-language header

Define feature so that each of binding people do (HTTP binding,
SMTP binding), it's concerned at that binding level. Is this the
right solution?

Issue 263: Unbounded list. There is no way to indicate the
preference. Argument is that almost none of the protocols specify the
automatic mechanism to tied into requester's requirement
necessarily.

Should SOAP be the lowest common denominator?

Issue 261: Not happy with the resolution. It should explicitly
specify the encoding.

Issue 264: should request some test cases. Needs to add these use
cases

Receiver expects more than one locale, but not necessarily use both all
the time. Many locale simultaneous uses

We need language negotiation somewhere

Accept language of whom? Current user, administrator?

The chair of the Internationalization Working Group is Misha Wolf
(Reuters). The chair of the Web Services Task Force is Addison Phillips
(webMethods, Inc.). The staff contact of the Internationalization Working
Group and the Web Services Task Force is Martin Dürst (duerst@w3.org). The chair and staff contact
of the the GEO Task Force is Richard Ishida (ishida@w3.org).