- From: Addison Phillips <aphillips@webmethods.com>
- Date: Wed, 12 Mar 2003 13:37:28 -0800
- To: Debasish Banerjee <debasish@us.ibm.com>
- CC: public-i18n-ws@w3.org
Hi Deb,
Thanks for writing this. My stream-of-conciousness comments embedded
below up to about S080. More detailed comments will come anon. This is
really great as a jumping off point for more action on Usage Scenarios!
Generally I think it would be very useful to prepare usage scenarios for
the items you cite at length and also to try and associate our existing
scenarios with the WSArch document (the links may be 1::many). I like
most of your comments. My main criticism, which you can see below, is
that we need to separate "application specific" behaviors ("best
practices") from things that WS standard can directly address. Many of
these problems are astoundingly familiar from my work at webMethods. I
could tell you how *we* addressed each in our proprietary platform. That
wouldn't mean that you could or even would want to specify those designs
in Web Services standards.
In addition, I think it is important to create as realistic a
demonstration or set of criticisms as possible. For example, several
times below you cite currency concerns, but a well designed data
structure and application won't have that particular problem as an i18n
problem. It's only an i18n problem if you're ignoring multicurrency and
using a naked number or a string to move the value. This is poor data
analysis, not necessarily an i18n issue. Locale says nothing about what
currency a particular value is in.
Addison
Debasish Banerjee wrote:
>
>
>
>Hi,
>
>Following contains some rough ideas and thoughts about the use of
>internationalization contexts (i18nContext = a chain of locales + a time
>zone) and their management policies (RunAsCaller, RunAsServer, and
>RunAsSpecified) in the contexts of "Web Services Architecture Usage
>Scenarios" and "Web Services Internationalization Usage Scenarios"
>documents.
>
>I would like to receive your detailed comments. We can discuss and refine
>some of the items over our next teleconference sessions. Maybe we can come
>up with some more use cases.
>
>Thanks,
>
>Deb
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>A. Web Services Architecture Usage Scenarios Document dated July 30, 2002
>(http://www.w3.org/TR/ws-arch-scenarios/)
>------------------------------------------------------------------------------------------------
>
>A.1 S001 In this so called 'Fire-and-forget Single Receiver' scenario,
>the sender can conceivably send localized messages to the receiver under
>certain circumstances. In fact, some may consider the stock quote currency
>can be a localized entity. The example presented in the document does not
>mention whether the price of the stock is 34.5$ or 34.5 DM.
>
AP> The stock price is an example of poorly internationalized data
structure. The stock price ideally would not be a simple number, because
that is not consistent with a currency value and especially one as
transient and fungible as a stock price. A correct data structure is not
lcoale affected. It might look something like this:
<stockquote>
<symbol>SYY</symbol>
<amount>1234.5</amount> # this is xsd:float or xsd:double
<currency>USD</currency> # this is an ISO4217
<time>2003-03-11T13:45:00GMT-5:00</time> # this is xsd:date
</stockquote>
The receiver's system can format that price to be what it wants within
the constraints of the data. A naive French program might display it as
"1 234,50$", a less naive program might choose "1 234,50 USD" or even
"US$1 234,50".
We can't guard against poorly internationalized code in the world, other
than to point at it and say "no, that is not a good example." I'm shy of
getting into discussing examples that proceed from false assumptions.
If the example returned a human-readable string it would be a better
candiate for the comments that follow:
<confirmation>
<msg lang="en-US">This message is to confirm your purchase of {0,
number, integer} shares of SYY on {1, datetime, medium} for {2, number,
currency}.</msg>
</confirmation>
>
>
>Unless the sender is aware of the receiver's locale preference, the sender
>will transmit all the messages either in its default or some pre-configured
>locale.
>
>Question: Can the sender be aware of the receiver's locale preferences
>through some sort of subscription metadata?
>
AP> Not with current WS protocols. It requires a higher-level
application-specific subscription.
>To receive a fire-and-forget
>message, a receiver may have to subscribe to a fire-and-forget sender's
>service. If the subscription information contains, receiver's i18n
>preferences, the sender can use that information to localize the
>transmitted message in appropriate locale and time zone if necessary.
>
>
>A.2 S002 An extension of scenario S001. If 'multicast distribution
>technology' is used, the same message (probably localized in sender's
>default locale) will be received by all the receivers. However, if the
>sender uses a distribution list to 'generate and push' messages to all the
>subscribed recipients, the proposed internationalization scheme mentioned
>in A.1 can probably be used: individual receiver may receive
>fire-and-forget messages localized according to its preferences. The sender
>may apply some local caching strategy for optimization: it may generate a
>message only once for each locale.
>
Agreed that multicasting implies some sort of subscription list. But
again this is an application specific problem. We need to document a
best practices use case for this, because it is a very real problem.
>
>
>A.3 S003 An ideal case for utilizing i18nContext to maintain
>remote-local transparency. The response message can be a 'fault' too. The
>response message must not alter the execution environment of the sender: no
>'container breach' on reply/fault reception.
>
Agreed.
>
>
>A.4 S004 Same as A.3 when we focus only on internationalization.
>
>A.5 S006 All the faults (Reasons) should be localized using i18nContext.
>
Localize once with a default or fallback message, possibly the latter
would be in the language of the server where the failure occured? It
might make sense to suggest to SOAP that they include a default message
(with NO xml:lang tag)...
>
>
>A.6 S007 All the partial responses should be localized under the
>i18nContext established during the initial request.
>
><toDO> For a multi-threaded receiver processing many SOAP requests at the
>same time, this use case needs careful investigation regarding the possible
>storage and restoration of i18nContext (and other contexts as well) for
>incremental asynchronous response generation. </toDO>
>
AP> This is an implementation problem, I think.
>
>
>A.7 S010 Usually positive acknowledgements are locale insensitive in
>nature, though some may think that the time zone element of the i18nContext
>can be used for time stamping the acknowledgement. Of course, if UTC time
>is mandated by the application semantics, the provider side may not have to
>use the time zone information of the i18nContext.
>
>Negative acknowledgements can contain some sort of 'Reasons' consisting of
>text messages. Any text message in an acknowledgement should be localized
>according to the i18nContext.
>
AP> You should consider how to introduce the concept of both nesting
("stack trace") and structure here....
>
>
>A.8 S030 The scenario can be an interesting application of i18nContext.
>The third party intermediary contains business logic which are usually
>locale neutral in nature. However, in theory, some business logic may be
>locale (and time zone) sensitive in nature: string comparisons, price
>comparison (must be done in the same currency), etc. To be safe, the
>'intermediary' and all the 'sellers' should be deployed as RunAsCaller.
>
AP> I disagree. Data structres are locale neutral. Business logic *may*
be locale neutral, but isn't required to be. If the intermediary defines
data structures that capture the data in a locale neutral way, then the
implementation of the business logic can generally be made to perform in
a locale-neutral manner... but not always.
Consider a B2B transaction. Matching supplier and buyer may introduce
different locale- or at least location-sensitive variables into the
equation. For example, I don't want to purchase froma supplier who's
warehouse is in China just because the product price is cheapest---the
transport costs and delivery latency may outweigh the price as a factor.
Or if I buy something on the internet the taxation rules may vary
disadvantageously. I don't see how this kind of application logic can be
dealt with except as an implementation decision in application.
i18ncontext only informs the lower-level aspects of this (such as string
comparison).
As noted previously, I would steer clear of currency as an example.
Correct data structures remove the basic I18N problem (they may
substitute the problem of calculating an up-to-the-moment conversion
factor, for example, but this is a higher-order application problem).
>
>
>A.9 S031 The presented use case may not need any internationalization
>consideration.
>
AP> Audit logging may resolve the log message to a specific locale or
language. Ideally the reconstructed routing log would be in the
requestors language preference (if possible).
>
>
>A.10 S032 This caching can lead to extremely interesting applications of
>i18nContext for cached results which are locale and/or time zone sensitive
>in nature.
>
>(a) A simple but general strategy will be to deploy both the caching
>intermediary and the service provider as RunAsCaller. For the very first
>time, the response corresponding a locale is computed at the service
>provider, and later cached at the intermediary. The caching store can
>maintain a table of locale-vs.-result, which continues to grow over time.
>On a subsequent request the intermediary first looks at the caching store
>before forwarding the request to the service provider. If the caching store
>contains the desired localized form of the result, the request does not
>travel to the ultimate receiver.
>
... if the service's outputs or processing are locale affected at all.
It might be useful to define that a business process or interaction
runsAsNeutral......
>
>
>Alternatively, under certain circumstances where localization can be
>performed at the caching intermediary the following approach can also be
>adopted.
>
>(b) The ultimate receiver (service provider) on receiving the initial SOAP
>request may provide a structured locale-neutral object to the caching
>intermediary. The caching intermediary stores the structured object in the
>'caching store'. The intermediary deployed as RunAsCaller can now create
>the concrete response by invoking proper operations on the cached
>structured object using the propagated i18nContext. The intermediary can
>continue to cache localized results in its local store and use them for
>subsequent responses. For example, assume the first request is associated
>with Japanese locale. The caching intermediary (1) receives and stores the
>locale-neutral object from the ultimate receiver, (2) computes the response
>in Japanese locale, stores a representation of it in its local store, and
>(3) finally sends the SOAP response back to the initial sender (requester).
>If a second request arrives with Korean locale, the caching intermediary
>first performs step (2) in Korean locale before embarking on step (3). Now
>if a subsequent request is associated again Japanese locale, the
>intermediary skips step (2); it simply retrieves the result of Japanese
>computation before completing step (3).
>
>
>A.11 S035 Probably i18nContext has no bearing in this case.
>
>A.12 S036 If the time stamps values are in UTC (which will probably be
>the case), there is no need to access i18nContext.
>
If timestamps are xsd:date then they will be UTC or have a TZindicator.
>
>
>A.13 S037 Same as S032. The intermediary must check the expiration
>criterion.
>
>A.14 S040 Probably the most complex usage scenario regarding
>internationalization. Need detailed investigation especially regarding
>compensation spheres and compensating transactions. Interesting
>localization may have to performed during compensation.
>
AP> But the pattern is also quite arbitrary. It may be possible to
consider only the individual discrete transactions without having to
think about the larger meta-context, excepting the fact that one desires
the process to be consistent and not subject to occuring in multiple
contexts. This speaks to Tex's concern about "don't run if you can't
satisfy my requirements". This pattern suggest that the first
transaction should fail if ANY of the subsequent transactions doesn't
support the contextual requirements ??
>
>
><toDo> Need to study the BPEL4WS spec. in detail and produce a few use
>cases especially regarding 'container breach', context storage, context
>retrieval, context switching, and of course compensation. </toDo>
>
>A.15 S061 Internationalization is not an issue here.
>
>A.16 S062 Internationalization is not an issue here.
>
>A.17 S0621 Internationalization is not an issue here.
>
>A.18 S063 Internationalization is not an issue here.
>
>A.19 S064 Internationalization is not an issue here.
>
>A.20 S065 Internationalization is not an issue here.
>
>A.21 S070 Another ideal scenario for i18nContext. The case is similar
>A.3.
>
Yes, but it's just a special case of request-response.
>
>
>A.22 S071 Internationalization is not an issue here.
>
>A.23 S080 Internationalization and transaction are orthogonal to each
>other. See A.14 for long running transactions.
>
>A.24 S090 Should i18nContext be used to interpret non-XML attachments?
>
AP> Not necessarily. The example of ebXML is a good one. The payload can
be anything. It might be a bytestream that contains alternate character
encoded text or it could be binary. The interpretation is application
specific. The header in the SOAP document must provide enough
information for the application to successfully interpret the data, but
that "negotiation" may take the form of "prior agreement".....
>
>
>A.25 S091 Similar to A.3 in principle. For consistent semantics and
>simpler programming model the inbound i18nContext must remain the same in
>all inbound message fragments. Should the SOAP receiver raise a fault in
>case it detects a change in inbound i18nContext during incremental
>reception and processing?
>
>A.26 S092 Probably internationalization is not an issue here.
>
>A.27 S200 If the event subscription process includes receivers
>internationalization preferences, the case is similar to that of A.2.
>
>A.28 S201 Internationalization is not an issue here.
>
>A.29 S300 Internationalization is not an issue here.
>
>A.30 S500 See A.32.
>
>A.31 S501 See A.32.
>
>A.32 S502 Service/operation level attributes/metadata should include the
>internationalization context management policies (RunAsCaller, etc.). The
>policies should be available in UDDI (or similar registries). A Web service
>requester should be able to inspect the i18nContext management policies
>before choosing a Web service provider. The default internationalization
>policy, if explicitly stated, determining the invocation
>internationalization context in the absence of an inbound i18nContext, may
>also appear in UDDI.
>
><toDo> We need to precisely formulate the i18nContext management policies
>(and other related stuff) and their accessors in the domain of UDDI (and
>WSDL?). </toDo>
>
>A.33 S503 Internationalization is not an issue here.
>
>A.34 S504 Internationalization is not an issue here.
>
>A.35 S505 The description of the use case is rather vague. Not sure
>whether and how the envisioned 'automatic dynamic resolver' may use the
>internationalization capabilities (RunAsCaller, RunAsServer,
>RunAsSpecified) before selecting specific Web service operations to invoke.
>
>A.36 S510 Internationalization is definitely a QoS. The support for this
>particular QoS should be available explicitly in UDDI.
>
>Tex's concern (see the last two lines of Section 2.36.2): Suppose a Web
>service operation OP is advertised to execute under RunAsCaller i18nContext
>management policy. Assume a particular invocation of the operation is
>associated with xx_YY inbound locale, and the Web service provider do not
>have resources to localize computations under the requested xx_YY locale.
>What should be the behaviour of OP? Will it raise a fault or use some
>default locale?
>
>Depending on the importance of the computation performed by OP, any one of
>the above mentioned two strategies may be used.
>
> If the requester can tolerate locale substitution (default locale for
> xx_YY), OP can use the default locale.
> If the requester must receive the result in the requested locale, OP can
> raise an appropriate fault with the 'Reason' in the default locale?
>
>The behaviour of Web service operations deployed as RunAsCaller in case the
>requested locale can not be honoured should be specifiable externally at
>the deployment time. This particular deployment attribute should also be
>available at an appropriate place in the UDDI registry.
>
><toDO> Need to work on exact formalization. </toDO>
>
>A.37 S600 Not sure about the term 'WSD definition'. If it refers to
>interface and similar stuff, internationalization is not an issue. However
>elements like 'wsil:abstract' may be localized in various languages for
>human interpretation. The inbound i18nContext can profitably be used in
>this scenario to receive localized versions of elements like
>'wsil:abstract'.
>
>A.38 S601 Internationalization is not an issue here.
>=========================================================
>
>
>B. Web Services Internationalization Usage Scenario, dated February 18,
>2003 (http://www.w3.org/International/ws/ws-i18n-scenarios-edit/)
>------------------------------------------------------------------------------------------------
>
>B.1 S-003 In case we have both i18nContext as a SOAP header and also the
>'Accept-Language' HTTP header which one shall be honoured by the service
>provider? Shall we stipulate: first i18nContext in the SOAP header and in
>its absence the 'Accept-Language' header? After all we want to define the
>internationalization semantics of Web services independent of the carrier
>protocol (HTTP, SMTP, etc.).
>
>Also, why 'xml:lang' in SOAP fault and in general in SOAP responses? The
>'Reason' can contain region dependent stuff too. Can we envision a more
>general tag something like 'xml:locale'?
>
>B.2 S-004 Clearly the suggested solution is impractical; in real life
>enterprise environments, it may not be possible to generate and transmit a
>'fault' containing 'Reason' in all available languages. This is an ideal
>case for the use of i18nContext. The service provider's invocation
>i18nContext should be used to generate the localized fault.
>
>In this context, it should be mentioned that the specification of 'fault'
>in the SOAP 1.2 specification is rather weak and incomplete.
>
>(a) Unlike the exception models of the modern programming environments like
>Java or C#, SOAP faults can not be nested. The ability to nest faults
>allows the application developers to maintain clear separation between
>application-level fault details from low-level (say data access) fault
>details without loosing any valuable diagnostic information. SOAP 1.x
>should carefully consider the issue of defining nested/chained faults.
>
>(b) In a hop-by-hop SOAP processing model, the use of simple texts as a
>fault 'Reason' is inadequate for the purpose of distributed
>internationalization. The reverse chained nodes can all be configured under
>different locales.
>
>Even in a simple two node request-response SOAP scenario, some may consider
>the existing definition of SOAP fault to be inadequate. A Web service
>provider may log certain category of faults locally before transmission.
>Suppose a language negotiation mechanism as mentioned in the SOAP V1.2
>primer, Dec. 19, 2002 (Section 2.3) exists between a SOAP requester and
>service provider. Assume a fault is produced at an American server for
>processing a request from a Japanese requester. Using the language
>negotiation mechanism, the service provider can generate the fault in
>Japanese language. If the Japanese language faults are logged at the
>American server, the English speaking system administrator may have tough
>time in interpreting the system log. Probably SOAP faults should be defined
>to optionally contain a structured locale-neutral object. The structured
>object should have the 'on-the-fly' localization capability. One or more
>methods can be invoked on the structured object which can produce all the
>'displayable texts' in a locale of choice.
>
>B.3 S-006 Impractical like B.2. See also A.32.
>
>B.4 S-007 See B.2 and A.32.
>
>B.5 S-008 An ideal case for i18nContext.
>
>B.6 S-009 The description of the use case is not very clear; a diagram
>may help. Maybe the services and requesters should be labelled distinctly
>to avoid confusion. Some may think that for the way one-way
>'fire-and-forget' messaging, requesters can not receive any faults. The
>reference (http://www.w3.org/TR/ws-desc-usecases/, Section 2.1.2) should be
>included to clarify the issue.
>
>Again, the inbound i18nContext from provider "A" should influence the
>language of the 'Reason' generated at "B".
>
>B.7 S-010 Can be viewed as the argument against using the Accept-Language
>HTTP header as the initial candidate for determining the inbound locale for
>SOAP-based messaging. SOAP i18nContext should ideally be totally
>independent of the carrier protocol.
>
>B.8 S-011 Again the description can be somewhat clearer. See B.6, and
>B.2. The i18nContext can be used to generate the 'Reason' text.
>
>B.9 S-012 See A.10
>
>B.10 S-013 The name of the section is somewhat misleading. Will something
>like 'Locale Sensitive Computation" be a better choice?
>
>The provider should be deployed as RunAscaller, and the invocation
>i18nContext should be used for the string comparison.
>
>B.11 S-014 We need to define the term 'Connection-Less'.
>
>B.12 S-015 Both "A" and "B" should use i18nContext. See A.3 too.
>
>B.13 S-016 The sentence: "For example, 2003-05-31 in Korea ... Japan"
>probably needs some clarification [also I think it should be '2003-05-31 in
>France']. Are we referring to time zone issue?
>
>B.14 S-017 Is it possible to bring this scenario under the general canopy
>of 'locale' and 'time zone' in place of 'currency' and 'location'?
>
>B.15 S-018 i18nContext is of no use in the first example. The 'currency'
>(can it be generalized to 'locale'?) tag is a part of data, and the SOAP
>receiver has to parse individual parts to interpret the price. The second
>example mentions: "It is possible ... SOAP header". I think the sentence
>needs more explanation or be completely omitted. In a clean Web service
>programming model all the meta information (here the 'default currency
>attribute') should be propagated as SOAP headers. We should not advocate a
>questionable programming model in our use case document.
>
>B.16 S-019 The inbound i18nContext (the caller i18nContext) can be used to
>interpret locale dependent inbound data.
>
><toDo> Explore WSDL for the issue raised in this scenario. </toDo>
>
>B.17 S-020 The relevant section number of the WSA document should be
>provided. Is the use case somewhat similar to B.9? Again, caching data and
>faults in all possible languages is impractical. See also A.10.
>
>B.18 S-027 See B.4 and A.36.
>
>B.19 S-031 It may not be possible to advertise the internationalization
>capabilities to the minutest possible detail; the size of that XML document
>will be substantial. Can we decide on RunAsCaller type of thing, which at
>least promises to provide the capability to localize (approximately in some
>cases) in commonly considered locales. WSDL annotations can externalize the
>default behaviour too.
>
--
Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.
Internationalization is an architecture. It is not a feature.
[Chair, W3C-I18N-WG, Web Services Task Force]
http://www.w3.org/International/ws
Received on Wednesday, 12 March 2003 16:38:00 UTC