RE: [I18N-WSTF] Teleconference Notes...

There are fundamental problems in getting agreement on what a locale actually is.

Personally, I fall most closely into camp #1 on your list. Although I acknowledge the other items there are completely valid, I think there is some value for this group in taking a narrow view of what a locale is. My version of #1 is:

"A locale is a collection of settings related to regional or cultural preferences. As a collection, it is an abstraction of a specific "cultural preferences" or "regional settings" for use by computer systems, not meant as a perfect model of an individual's preferences. Locales provide software developers with the means of writing software that expresses itself in the most appropriate way for a given set of users."

Thus my preference for talking about "locale tags" or "i18n context identifiers" instead of "locales". Once we start down the path of closely defining a locale, we end up having to deal with the different locale models extant, the differing implementation details, dissatisfaction with the assumptions behind locales such as their lack of personalization, etc. Is this necessary to create internationalized Web services? I don't believe it is. 

In fact, it might be counter-productive.

Among the models for Web services platforms is the "pure WS environment", in which developers directly author Web services for the purpose of being a Web service. It might be possible create and describe an "Internet locale model" that takes the full range of issues into account in this case.

Another model is the "wrapper" model, in which Web service provider products wrap existing business logic in Web services. In this case I think it would be best that they way you author a "Web service" be analogous if not identical to how you write "regular" logic. Or, another way: your regular logic will work as designed when you turn it into a WS.

Thus, by ignoring what the "locale container" actually "contains", I think we could create platform neutral "locale and i18n preferences" to enable multi-locale support. More importantly, I think we could sell the result to WS standardizers and implementers who don't care what a locale is (or isn't) and have a vested interest in their existing systems (and locales).

~Addison

NB> The foregoing is a personal view, not one currently endorsed by the WSTF.

> -----Original Message-----
> From: Mark Davis [mailto:mark.davis@jtcsv.com]
> Sent: Friday, January 31, 2003 10:03 AM
> To: Addison Phillips [wM]
> Cc: public-i18n-ws@w3.org
> Subject: Re: [I18N-WSTF] Teleconference Notes...
> 
> 
> >Basically, the discussion revolved around the problem of passing locales
> ...
> >What we're talking about here aren't locales, though, but locale tags or
> 
> By the bare word "locale", people can mean *many* different things, as you
> did so in your two recent messages. I think part of the problem is that we
> have to be a bit more precise in our language (myself included).
> 
> Someone could mean by "locale" any of the following:
> 
> 1. "locale conventions" - a set of conventions for doing something (scope*
> unclear, but usually includes sorting order; breaks ("character", word,
> line, sentence); formatting dates, times, numbers, currency; etc.)
> *open issue: how far does this go? religious preference, aisle vs window,
> kosher vs vegetarian??
> http://oss.software.ibm.com/cvs/icu/~checkout~/locale/locale_data_
> markup.htm
> l
> 
> 2. "locale domain" - set of people that commonly (though not always*) use
> the same locale conventions
> *example: I use mostly US conventions, but use 2003-02-21 date 
> format on my
> computer
> 
> 3. "locale data" - a set of data supporting operations in #2
> (e.g. "January")
> 
> 4. "application locale data" - a set of data used to support localized
> versions of a program.
> (e.g. "Put the candle back")
> 
> 5. "locale ID" - a short tag used for identifying a locale (one or more of
> the above)
> ...
> and perhaps more.
> 
> The names above are just off the top of my head. But spending a 
> little time
> to come up with good, unambiguous terms for what we are 
> discussing would be
> time well spent!
> 
> Back to the other topic:
> 
> > If you are making a WS out of an existing method or function call, it
> > shouldn't be necessary to pass said method a locale unless the design of
> > the method (e.g. the parameter list) really calls for it.
> 
> This I agree with; an example would make it clear. That is, a WS that
> computed standard deviations would not expect to be passed a locale. A WS
> that spell-checked or sorted, would.
> 
> Mark
> ________
> mark.davis@jtcsv.com
> IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
> (408) 256-3148
> fax: (408) 256-0799
> 
> ----- Original Message -----
> From: "Addison Phillips [wM]" <aphillips@webmethods.com>
> To: "Mark Davis" <mark.davis@jtcsv.com>
> Cc: <public-i18n-ws@w3.org>
> Sent: Thursday, January 30, 2003 20:53
> Subject: Re: [I18N-WSTF] Teleconference Notes...
> 
> 
> >
> > Hi Mark,
> >
> > There is a certain amount of elision in the notes, I'm afraid.
> >
> > Basically, the discussion revolved around the problem of passing locales
> > to a WS: when should the WS designer need to deal with it (by specifying
> > the locale in the parameter list of the actual service or in the Message
> > definition in the WSDL) and when not.
> >
> > Passing a locale explicitly is, as you note, a good idea when the locale
> > has a natural or reasonable place in the "service contract". But it is a
> > poor choice when the service isn't necessarily locale affected ("add two
> > integer values"). Many if not most services fall into this latter
> > category, IMO.
> >
> > That isn't to say that there are no cases for passing a locale.
> >
> > If one does a careful job of designing the data structures and service
> > contract, generally one does not want a locale. You may need explicit
> > facets of a locale (a language for natural language processing, a
> > currency, a country code, etc. etc.), but not that many data structures
> >   need an explicit locale, even as an override value.
> >
> > There are lots of counter examples.
> >
> > So that note should say something more like:
> >
> > If you are making a WS out of an existing method or function call, it
> > shouldn't be necessary to pass said method a locale unless the design of
> > the method (e.g. the parameter list) really calls for it.
> >
> > A lot more discussion (much of it off list, alas) goes with that, all of
> > which fell under the rubric of "agreed about the nature of 
> passing etc..."
> >
> > Sorry the notes make this difficult to follow.
> >
> > Addison
> >
> > Mark Davis wrote:
> > >>o General agreement: passing locale explicitly is a poor choice for
> > >
> > > designing a WS. We agreed about the nature of passing locale and
> programming
> > > model.
> > >
> > > I am a bit uneasy about this. There are times when it is ok 
> to depend on
> a
> > > 'global' locale. But it is subject to many of the general problems of
> global
> > > variables. What we chose to do in Java was to have both a 'global'
> setting,
> > > and to be able to explicitly pass in locales wherever necessary. (The
> > > architecture predated thread-locale storage in Java, otherwise storing
> on a
> > > thread basis would have been better that global to the entire address
> space.
> > > But notice that having explicit locales available makes it 
> possible for
> > > people to write cover methods that do use thread-locale storage.)
> > >
> > > Mark
> > > ________
> > > mark.davis@jtcsv.com
> > > IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
> > > (408) 256-3148
> > > fax: (408) 256-0799
> > >
> > > ----- Original Message -----
> > > From: "Addison Phillips [wM]" <aphillips@webmethods.com>
> > > To: "Addison Phillips [wM]" <aphillips@webmethods.com>;
> > > <public-i18n-ws@w3.org>
> > > Sent: Wednesday, January 22, 2003 18:05
> > > Subject: RE: [I18N-WSTF] Teleconference Notes...
> > >
> > >
> > >
> > >>Attending: Kentaroh, Deb, Martin, Tex, Addison [chair, scribe]
> > >>Regrets: Mike, Takao
> > >>
> > >>Actions:
> > >>
> > >> o Deb: to follow up with Noji following this call
> > >> o Martin, Addison: Find out who WS-Transactionality is. Possibly
> consider
> > >
> > > liasion.
> > >
> > >> o Addison: Explore charter modification with Richard
> > >> o Tex: create use case(s) for "must match requested locale"
> > >> o Addison: create requirements document skeleton from 
> ULocale document.
> > >> o Deb/Addison: looking at new WS docs from other W3C WGs to ensure
> we're
> > >
> > > not missing anything
> > >
> > >>General discussion:
> > >>
> > >>Martin at WS meeting in Arizona. Any specific input would be helpful.
> > >
> > > Martin has 30 minutes tomorrow in joint session.
> > >
> > >>Martin: Appreciated Deb's note on "context" keyword. Discussion of
> context
> > >
> > > mechanism for WSDL. Deb thinks this will be defined (competing
> proposals
> > > exist). Exchange of contexts will be defined in WSDL and 
> elsewhere. Need
> to
> > > fit our proposals into this mechanism as it matures.
> > >
> > >>Note: WS-Choreography WG was started.
> > >>
> > >>--- no additional actions --- so we proceeded to discussion of
> > >
> > > locale/language negotiation:
> > >
> > >>o "context" definition across WS, not just for i18n.
> > >>o "what" instead of "how" should be the starting part. IOW> we should
> work
> > >
> > > on "tags", not the exchange mechanism because we think that the
> "context"
> > > idea will be standardized elsewhere.
> > >
> > >>o General agreement that locale should not be explicit most 
> of the time.
> > >>o General agreement: passing locale explicitly is a poor choice for
> > >
> > > designing a WS. We agreed about the nature of passing locale and
> programming
> > > model.
> > >
> > >>o General agreement: locale interpretation is a problem due 
> to disparate
> > >
> > > implementations (see Kentaroh's list)
> > >
> > >>    --how much alignment/precision is desirable?
> > >>    --"tags" might take several forms:
> > >>          i) tag
> > >>         ii) structure/data
> > >>        iii) urn (as a pointer to a) datafile
> > >>
> > >>
> > >>Discussed what forms a good usage scenario: collation is a good
> example..
> > >
> > > business rules a good example.. SQL statements with implicit ordering
> also
> > > important. Example: "select all foo < ñ" (that's U+00F1, n-tilde)
> > >
> > >>Discussed reasons why "charset" might be useful or not. General
> agreement
> > >
> > > that we want to use Unicode everywhere and that charset is an XPG4
> legacy
> > > value that might not have a place in WS locale negotiation.
> > >
> > >>   counter examples: WS container invokes XPG4 program in new
> > >
> > > thread-of-execution; JCA connection to XPG4 resource
> > >
> > >>Tex: wants to eliminate ambiguity of existing locale system. 
> Specifying
> a
> > >
> > > locale and using fallbacks may be problematic in some circumstances.
> Need
> > > something like a "must match" with default of false. Tex to create use
> case
> > > for this.
> > >
> > >>Discussed why fallbacks are prone to failure, some are "sometimes
> wrong",
> > >
> > > and sometimes best practices can work.
> > >
> > >>Deb: suppose that no one does anything. We should compare scenarios in
> > >
> > > this area. Also: consider J2EE example of server-enforced locale.
> > >
> > >>Ultimately, we agreed on a "Goldilock's approach":
> > >>   "As closely defined as we can make the locale tags, but as open as
> > >
> > > possible."
> > >
> > >>Agreed that our next steps are to find agreement on the 
> requirements so
> > >
> > > that we can pursue standardization of a tagging scheme.
> > >
> > >>In particular we need to write requirements and *also* usage 
> scenarios.
> > >
> > > What is the general case? What is the usage case?
> > >
> > >>Group: Considered if we should modify our charter now to allow us to
> > >
> > > create this as a W3C Recommendation. Discussion ensued. Planned to
> create
> > > requirements in the next two weeks. We think that this document will
> give us
> > > enough guidance to decide whether to pursue a specific charter mod or
> > > whether to put this item to I18N-WG-Core or to WS-Arch.
> > >
> > >>Discussed idea of having FTF in Feb/Mar timeframe separate 
> from IUC and
> in
> > >
> > > Boston area.
> > >
> > >>thanks,
> > >>
> > >>Addison
> > >>
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: public-i18n-ws-request@w3.org
> > >>>[mailto:public-i18n-ws-request@w3.org]On Behalf Of Addison Phillips
> [wM]
> > >>>Sent: Monday, January 20, 2003 3:04 PM
> > >>>To: public-i18n-ws@w3.org
> > >>>Subject: [I18N-WSTF] [REMINDER] Teleconference Tomorrow
> > >>>
> > >>>
> > >>>
> > >>>W3C-I18N-WG Web Services TF teleconference [WSTF]
> > >>>------------------------------------------------------------------
> > >>>-----------
> > >>>Bridge   : +1-617-761-6200 (Zakim) with conference code 4186
> > >>>(spells "I18N")
> > >>>Duration : 60 minutes
> > >>>------------------------------------------------------------------
> > >>>-----------
> > >>>Day      : Tuesday
> > >>>Dates    : 14, 28 January
> > >>>Start    : 23:00 GMT, 18:00 Eastern, 15:00 Pacific, 08:00 Tokyo
> > >>>(next day!)
> > >>>------------------------------------------------------------------
> > >>>-----------
> > >>>Zakim information    : http://www.w3.org/2002/01/UsingZakim
> > >>>Zakim bridge monitor : http://www.w3.org/1998/12/bridge/Zakim.html
> > >>>Zakim IRC bot        : http://www.w3.org/2001/12/zakim-irc-bot.html
> > >>>------------------------------------------------------------------
> > >>>-----------
> > >>>
> > >>>REMINDER: the next scheduled teleconference for the WSTF is
> > >>>tomorrow. If you have not used the W3C teleconference bridge
> > >>>previously, please review the links above for instructions (it's
> > >>>very easy).
> > >>>
> > >>>SUMMARY: This is an important meeting. We'll be reviewing
> > >>>activities related to people's positions regarding locales and
> > >>>language negotiation. Deb and I have both sent positions to the
> > >>>list. Please review these, as they'll be the main topic. If you
> > >>>intend to send something for consideration, you should do it quickly.
> > >>>
> > >>>I have reserved 9 total slots on the bridge. Since we've picked
> > >>>up in attendence, I'm keeping the number steady for now.
> > >>>
> > >>>Agenda
> > >>>=============================
> > >>>           o Discuss Agenda.
> > >>>           o Discuss Action Items.
> > >>>           o Discuss next FTF meeting. Tentatively at IUC23 
> in Prague.
> > >>>           o Activity to take on locales and languages.
> > >>>
> > >>>Pending Action Items
> > >>>====================
> > >>>1. Martin: will follow up with Russ Rolfe in case MS has any
> > >>>space in Prague for an FTF. This is a low priority item.
> > >>>2. Team: write up and send to list a "position" on the locale
> > >>>problem (See notes below for what that means). Due prior to next
> > >>
> > > meeting.
> > >
> > >>>3. Deb: send specific comments on WSUS to list.
> > >>>4. Addison: post tentative calendar of activities for year.
> > >>>
> > >>>Usage Scenarios Working Draft
> > >>>=============================
> > >>>Can be reviewed here:
> > >>>http://www.w3.org/International/ws/ws-i18n-scenarios-edit
> > >>>
> > >>>
> > >>>Talk to you then!
> > >>>
> > >>>Best Regards,
> > >>>
> > >>>Addison
> > >>>
> > >>>Addison P. Phillips
> > >>>Director, Globalization Architecture
> > >>>webMethods, Inc.
> > >>>
> > >>>+1 408.962.5487  mailto:aphillips@webmethods.com
> > >>>-------------------------------------------
> > >>>Internationalization is an architecture. It is not a feature.
> > >>>
> > >>>Chair, W3C I18N WG Web Services Task Force
> > >>>http://www.w3.org/International/ws
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
> > --
> > Addison P. Phillips
> > Director, Globalization Architecture
> > webMethods, Inc.
> >
> > +1 408.962.5487  mailto:aphillips@webmethods.com
> > -------------------------------------------
> > Internationalization is an architecture. It is not a feature.
> >
> > Chair, W3C I18N WG Web Services Task Force
> > http://www.w3.org/International/ws
> >
> >
> >
>

Received on Friday, 31 January 2003 15:45:48 UTC