Web Services: I18N

fizzlargeSecurity

Nov 3, 2013 (3 years and 7 months ago)

151 views

Web Services: I18N

A progress report, or, are we done yet?

32
nd

Internationalization and Unicode Conference

Presenter


Addison Phillips

Globalization Architect

Lab126


Chair


W3C Internationalization Core WG

Agenda


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 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
Activity


W3C WSTF


Web
Services Internationalization Usage Scenarios


Web Services Internationalization
Requirements


W3C Internationalization Core WG


WS
-
I18N (Note track)

Web 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
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 Services

WS
-
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?


Four Patterns:


Locale Neutral


Service Determined


Client Influenced


Data/Resource Driven

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

Invocation


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 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 Capabilities


Internationalization model describes
capabilities:


Policy? Runtime locale? Etc.


Internationalization model describe constraints:


Available locales


Available resources


Available language content


Runtime restrictions


WS
-
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?)

Issues


“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/

Examples


WS
-
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)

(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.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)

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>


Schedule


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 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 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
-
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 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_Yor
k

8:00
(DST)

7:00

America/Santiago

8:00

9:00
(DST)

America/Guyana

8:00

8:00

Building 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 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 Service


Summary


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!