Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Web Services: I18N A progress report, or, are we done yet? 32nd Internationalization and Unicode Conference • Addison Phillips Globalization Architect Lab126 Chair – W3C Internationalization Core WG Presenter • 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 • 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 • W3C WSTF • Web Services Internationalization Usage Scenarios • Web Services Internationalization Requirements • W3C Internationalization Core WG • WS-I18N (Note track) W3C Internationalization Activity 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 • Desktop • Locales in the environment • Web Application • Locale-related APIs and state mechanisms • Web Service??? • Uh… Programming Paradigms the classic I18N model “Classic” SOAP-RPC Web Services • Define service capabilities and constraints via policy assertions. • Use different features together to get different results. • Services advertise policies; consumers specify requirements WS-Policy • Four Patterns: • • • • Locale Neutral Service Determined Client Influenced Data/Resource Driven What sort of policies for I18N? • 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? • 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 • 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 • 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 • Internationalization model describes capabilities: • Policy? Runtime locale? Etc. • Internationalization model describe constraints: • • • • Available locales Available resources Available language content Runtime restrictions Constraints and Capabilities • 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 • “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 Examples (1) (2) (3) (4) (5) (6) (7) <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 (1) (2) (3) (4) (5) (6) (7) (8) <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) • 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> WS-I18N in WSDL 2.0 7 <wsp:Policy xml:id="MyPolicy" > 8 <i18np:i18n/> 9 <!-- omitted assertions --> 10 </wsp:Policy> (1) (2) (3) (4) (5) (6) (7) (8) (1) <i18n:international> (2) <i18n:locale>en-US</i18n:locale> <i18n:international> (3) <i18n:preferences> <i18n:locale>en-US,fr,zh-cmn-Hant-CN (4) <ldml:collation> </i18n:locale> (5) <ldml:alias source="de-DE" <i18n:preferences> type="phonebook"/> <ldml:collation> (6) </ldml:collation> <ldml:alias source="de-DE" (7) </i18n:preferences> type="phonebook"/> (8) </i18n:international> </ldml:collation> </i18n:preferences> </i18n:international> (continued) • If you can call it a schedule! • Likely to be published this year, if we can get help completing the document. Schedule • “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 • 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 • 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 available content cmn-Hant de-1996 en en fr HTTP Accept-Language • 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_Yor 8:00 (DST) k 7:00 America/Santiago 8:00 9:00 (DST) America/Guyana 8:00 8:00 Time and Time Zone Use ‘Accept-Language’ and BCP 47 Lookup to negotiate language/locale • Define custom headers when necessary. Document these well. • Building an internationalized REST service How to find stuff in a REST environment: http://example.org/users/addison • example.org: host (server) • /users/: path (taxonomy) • addison: resource (e.g. user id) 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 An Example Amazon S3 Service • 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 Questions? and Comments!