Transcript Web Services: I18N - Inter

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_York
8:00 (DST)
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!