W3C home > Mailing lists > Public > public-i18n-ws@w3.org > June 2003

RE: WS-Arch Usage Scenario S032: Caching

From: Addison Phillips [wM] <aphillips@webmethods.com>
Date: Tue, 17 Jun 2003 17:44:34 -0700
To: "Martin Duerst" <duerst@w3.org>, <public-i18n-ws@w3.org>
Message-ID: <PNEHIBAMBMLHDMJDDFLHOEDNGMAA.aphillips@webmethods.com>

Thanks Martin. Added to the sign-up document.

Others: where are yours?


> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of Martin Duerst
> Sent: Tuesday, June 17, 2003 2:37 PM
> To: public-i18n-ws@w3.org
> Subject: WS-Arch Usage Scenario S032: Caching
> I'm not sure I can do as good a job as Addison, but I'll give
> it a try.
> Scenario S032 is about caching. The description says that this
> can be on several levels, i.e. a whole SOAP message or just
> some part. I'm not very sure the thing with the 'parts' is
> practical, but anyway, this is about i18n :-).
> There are mainly two internationalization considerations:
> 1) The potential for caching gets reduced if the relevant messages
>     or message parts contain some i18n aspects, because only a subset
>     of the recipients will want to get exactly the same message.
>     This can be improved by using late localization as much as possible,
>     by including several alternatives (e.g. having a fault message
>     in 5 languages means that the same cached fault message can be
>     used for an audience covering these 5 languages, rather than just
>     one language). In order for caching to not produce errors with i18n,
>     the i18n context has to be well-known (explicit) to the caching
>     mechanism, or messages with i18n aspects have to be marked as non-
>     cachable.
> 2) In many areas of the world, connectivity is worse, and caching
>     therefore potentially more important, than in the better connected
>     part of the world. Example include Africa and some parts of Asia,
>     but also to some extent Australia/New Zeeland,...
> Regards,    Martin.
Received on Tuesday, 17 June 2003 20:44:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:38 UTC