Web Services: I18N

Web Services: I18NWeb Services: I18NA progress report, or, are we done

yet?

32nd Internationalization and Unicode Conference

PresenterPresenter

• Addison PhillipsGlobalization ArchitectLab126

Chair – W3C Internationalization Core WG

AgendaAgenda

• Web services vs. Internationalization• Where are we? How did we get here?

• W3C WS-I18N • SOAP, WS-Policy, and all that

• REST, AJAX, and that “Web 2.0 thing”• The “other” Web services

About This PresentationAbout This Presentation

• Web service constraints and capabilities: Internationalization makes a good use case.• The classic internationalization model• Applying the internationalization model to

Web services• Why constraints? Why capabilities?

W3C Internationalization ActivityW3C Internationalization Activity

• W3C WSTF• Web Services Internationalization Usage Scenarios• Web Services Internationalization Requirements

• W3C Internationalization Core WG• WS-I18N (Note track)

Web Services and InternationalizationWeb Services and Internationalization

So Web Services are internationalized, right?• Locale-neutral representation (XML Schema)• No user interface (machine-to-machine)• Inherits XML’s rich support for Unicode, language

tags, and so forth• “Internationalization is the problem of the service

author, not the provider.”

Programming ParadigmsProgramming Paradigms

• Desktop• Locales in the environment

• Web Application• Locale-related APIs and state mechanisms

• Web Service???• Uh…

the classic I18N model

““Classic” SOAP-RPC Web ServicesClassic” SOAP-RPC Web Services

WS-PolicyWS-Policy

• Define service capabilities and constraints via policy assertions.• Use different features together to get different

results.• Services advertise policies; consumers specify

requirements

What sort of policies for I18N?What sort of policies for I18N?

• Four Patterns:• Locale Neutral• Service Determined• Client Influenced• Data/Resource Driven

What does that service do?What does that service do?

• Services generally run in the host locale• May not be the same as the service provider• May not give the results the user expects• No way for the user to control it

• Developers must program services to provide international capabilities• Provide the locale model—provide for inputs that

indicate the locale in some (usually proprietary) manner• E.g. Define multiple endpoints for different locales

• Provide for localization where appropriate—determine the language to use for the interaction

• “Providers” do nothing for you.

Web Service DescriptionsWeb Service Descriptions

• Exchange a locale that is explicitly in the service signature.• No standards exist for doing this• Strong platform and programming language dependency

• Exchange a locale that is implied in the service’s operation.• Web service descriptions don’t convey this information.

• Describe how a particular endpoint will work.• There may be multiple endpoints in multiple

geographies.

InvocationInvocation

• Language negotiation• Services still need human readable messages.• Faults (exceptions, errors) need human readable

messages.• Service may retrieve, process, store, or

otherwise access text.• Locale negotiation

• Making the service do what the user wants.• Collation, calendar, text processing, currency,

routing, addressing, formatting, business rules, tax authority, legal requirements, etc.

Basic ConclusionsBasic Conclusions

• Web services need “international preferences”• Personally: these are “locales”

• Web service descriptions need to describe “policies”• “This service runs in the fr-FR locale.”• “The requester can tell me what locale to use.”• “If you request a locale I don’t support, I return a Fault

message.”• Locale identifiers are needed.

• You can tell me what locale to run in… if we can agree on what the identifier means.

• Web service discovery needs more internationalization.

Constraints and CapabilitiesConstraints and Capabilities

• Internationalization model describes capabilities:• Policy? Runtime locale? Etc.

• Internationalization model describe constraints:• Available locales• Available resources• Available language content• Runtime restrictions

WS-I18NWS-I18N

• Currently a W3C draft; eventual status: Working Group Note

• Provides for basic internationalization properties• Service locale (via IETF BCP 47 language tags)• Time zone (via Olsen identifiers)

• Can provide additional, service-specific preferences• Currently via LDML (best choice?)

IssuesIssues

• “I wrote it in a day”• Language/locale should be in terms of BCP 47

language priority lists• Language/locale negotiation needs to be provided

for• Separate language from locale?• Use LDML?

• http://www.w3.org/TR/ws-i18n/

ExamplesExamples

WS-I18N in SOAP MessageWS-I18N in SOAP Message

(1) <i18n:international ... S:actor="..."> (2) <i18n:locale> locale identifier

</i18n:locale> (3) <i18n:timezone> time zone value

</i18n:timezone>(4) <i18n:preferences ...> (5) LDML-based or other locale preferences(6) </i18n:preferences> (7) </i18n:international>

locale identifier == LDML (BCP47) | “$neutral” | “$default”time zone value == RFC 822 offset | Olson id

(continued)(continued)

(1) <i18n:international>(2) <i18n:locale>en-US</i18n:locale>(3) <i18n:preferences> (4) <ldml:collation> (5) <ldml:alias source="de-DE" type="phonebook"/> (6) </ldml:collation> (7) </i18n:preferences> (8) </i18n:international>

WS-I18N in WSDL 2.0WS-I18N in WSDL 2.0

• 1 <wsdl:description 2 targetNamespace="http://tns.example.com/" 3 xmlns:tns="http://tns.example.com/" 4 xmlns:wsdl="http://www.w3.org/ns/wsdl" 5 xmlns:wsp="http://www.w3.org/ns/ws-policy" 6 xmlns:i18np="http://www.w3.org/2008/04/ws-i18np"> 7 <wsp:Policy xml:id="MyPolicy" > 8 <i18np:i18n/> 9 <!-- omitted assertions --> 10 </wsp:Policy> 11 <!-- omitted elements --> 12 <wsdl:binding name="MyBinding" type="tns:MyInterface" > 13 <wsp:PolicyReference 14 URI="#MyPolicy" 15 wsdl:required="true" /> 16 <!-- omitted elements --> 17 </wsdl:binding> 18 </wsdl:description>

(continued)(continued)

7 <wsp:Policy xml:id="MyPolicy" >8 <i18np:i18n/>9 <!-- omitted assertions -->10 </wsp:Policy>

(1) <i18n:international>(2) <i18n:locale>en-US</i18n:locale>(3) <i18n:preferences> (4) <ldml:collation> (5) <ldml:alias source="de-DE"

type="phonebook"/> (6) </ldml:collation> (7) </i18n:preferences> (8) </i18n:international>

(1) <i18n:international>(2) <i18n:locale>en-US,fr,zh-cmn-Hant-CN

</i18n:locale>(3) <i18n:preferences> (4) <ldml:collation> (5) <ldml:alias source="de-DE"

type="phonebook"/> (6) </ldml:collation> (7) </i18n:preferences> (8) </i18n:international>

ScheduleSchedule

• If you can call it a schedule!• Likely to be published this year, if we can get

help completing the document.

REST: the “other” Web servicesREST: the “other” Web services

• “Resource oriented” rather than RPC• Nouns, not verbs

• Light-weight; simple; path-oriented• Search-engine friendly

• Often: technology behind AJAX and Web2.0• XmlHttpRequest

RESTafarians

REST and I18NREST and I18N

• Alas, the same problem—maybe more acutely• AJAX often used to directly update the screen

(so needs to be preformatted, in proper language)

• JavaScript has no locale object or locale model (can’t control how it does formatting)

• “Static” user interface determined by a Web server, not by local configuration

(so might get multiple languages on one page)

• No standards whatsoever!

HTTP Accept-LanguageHTTP Accept-Language

• A “poor-man’s” locale negotiation tool

Accept-Language:en-US;q=1.0,cmn-Hant-CN;q=0.8,fr-CA;q=0.6

BCP 47 (RFC 4647) Lookup Algorithm

en

de-1996

cmn-Hant

fr

available content

en

Time and Time ZoneTime and Time Zone

• Most services are not time zone affected.• See http://www.w3.org/TR/2005/NOTE-timezone-20051013/• Update pending for this document

• Avoidance usually preferable to using zone data… but sometimes you need a zone offset… and sometimes you really need a time zone

2008-07-16T08:00:30.45-05:00

Not a time zone!

Zone Noon GMT, 16 July Noon GMT, 16 Dec

America/New_York

8:00 (DST) 7:00

America/Santiago

8:00 9:00 (DST)

America/Guyana

8:00 8:00

Building an internationalized REST serviceBuilding an internationalized REST service

• Use ‘Accept-Language’ and BCP 47 Lookup to negotiate language/locale

• Define custom headers when necessary. Document these well.

The REST URI Path dilemmaThe REST URI Path dilemma

How to find stuff in a REST environment:

• example.org: host (server)• /users/: path (taxonomy)• addison: resource (e.g. user id)

http://example.org/users/addison

http://example.org/sports/football/Monarcas_Morelia/players/Luis_Ángel_Landín

http://例子 . 测试 /sports/football/Monarcas_Morelia/players/Luis_Ángel_Landín

An Example Amazon S3 ServiceAn Example Amazon S3 Service

SummarySummary

• WS-I18N• A work in progress you can contribute to.• Uses WS-Policy to enable SOAP-based Web

services with locale and other international preferences.

• REST• Needs “Best Practices”; better if everyone

identifies locale, language, and “international preferences” in the same way.

• Needs LTLI?

Join This!!

Questions? and Comments!