Web Services: I18N

1. Web Services: I18N A progress report, or, are we done yet? 32nd Internationalization and Unicode Conference

2. Addison PhillipsGlobalization ArchitectLab126Chair – W3C Internationalization Core WG Presenter

3. 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 Agenda

4. 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? About This Presentation

5. W3C WSTF • Web Services Internationalization Usage Scenarios • Web Services Internationalization Requirements • W3C Internationalization Core WG • WS-I18N (Note track) W3C Internationalization Activity

6. 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.” Web Services and Internationalization

7. Desktop • Locales in the environment • Web Application • Locale-related APIs and state mechanisms • Web Service??? • Uh… Programming Paradigms the classic I18N model

8. “Classic” SOAP-RPC Web Services

9. Define service capabilities and constraints via policy assertions. • Use different features together to get different results. • Services advertise policies; consumers specify requirements WS-Policy

10. Four Patterns: • Locale Neutral • Service Determined • Client Influenced • Data/Resource Driven What sort of policies for I18N?

11. 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. What does that service do?

12. 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. Web Service Descriptions

13. 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. Invocation

14. 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. Basic Conclusions

15. Internationalization model describes capabilities: • Policy? Runtime locale? Etc. • Internationalization model describe constraints: • Available locales • Available resources • Available language content • Runtime restrictions Constraints and Capabilities

16. 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?) WS-I18N

17. “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/ Issues

18. Examples

19. <i18n:international ... S:actor="..."> • <i18n:locale> locale identifier </i18n:locale> • <i18n:timezone> time zone value </i18n:timezone> • <i18n:preferences ...> • LDML-based or other locale preferences • </i18n:preferences> • </i18n:international> locale identifier == LDML (BCP47) | “$neutral” | “$default” time zone value == RFC 822 offset | Olson id WS-I18N in SOAP Message

20. <i18n:international> • <i18n:locale>en-US</i18n:locale> • <i18n:preferences> • <ldml:collation> • <ldml:alias source="de-DE" type="phonebook"/> • </ldml:collation> • </i18n:preferences> • </i18n:international> (continued)

21. 1 <wsdl:description2 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:Policyxml: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> WS-I18N in WSDL 2.0

22. 7 <wsp:Policy xml:id="MyPolicy" > 8 <i18np:i18n/> 9 <!-- omitted assertions --> 10 </wsp:Policy> • <i18n:international> • <i18n:locale>en-US</i18n:locale> • <i18n:preferences> • <ldml:collation> • <ldml:alias source="de-DE" type="phonebook"/> • </ldml:collation> • </i18n:preferences> • </i18n:international> • <i18n:international> • <i18n:locale>en-US,fr,zh-cmn-Hant-CN </i18n:locale> • <i18n:preferences> • <ldml:collation> • <ldml:alias source="de-DE" type="phonebook"/> • </ldml:collation> • </i18n:preferences> • </i18n:international> (continued)

23. If you can call it a schedule! • Likely to be published this year, if we can get help completing the document. Schedule

24. “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: the “other” Web services

25. 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! REST and I18N

26. 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 en BCP 47 (RFC 4647) Lookup Algorithm cmn-Hant en available content fr de-1996 HTTP Accept-Language

27. 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! Time and Time Zone

28. Use ‘Accept-Language’ and BCP 47 Lookup to negotiate language/locale • Define custom headers when necessary. Document these well. Building an internationalized REST service

29. 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 The REST URI Path dilemma

30. An Example Amazon S3 Service

31. 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!! Summary

32. Questions? and Comments!