RE: USD Section 6.7 Regimes

Added. Uploading in a few minutes.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture.
It is not a feature.

> -----Original Message-----
> From: public-i18n-ws-request@w3.org
> [mailto:public-i18n-ws-request@w3.org]On Behalf Of A. Vine
> Sent: vendredi 19 mars 2004 14:40
> To: I18n WSTF
> Subject: USD Section 6.7 Regimes
>
>
>
> Notes:  Scenario A is big and ugly.  It might make more sense to
> cut it down to
> one of the sub-services.  I'm not sure if Scenarios B & C are
> what we're after.
>   I was trying to think of a legal example, and most seem too complex.
>
> 6.7 Regimes
>
> 6.7.1 Modeling Tax, Customs, Legal, and other Cross-Border and Cultural
> Considerations
>
> Tax, customs, legal, and similar matters are usually
> country-specific.  However,
> much of the types of processing involved are the same.  For
> example, many tax
> calculations take a percentage or set of percentages of a given
> amount.  A set
> of Web services can work together to provide information for many
> countries,
> avoiding code and process duplication.
>
> There is more information needed in these types of processes than
> just the
> country identifier.  Language information is crucial for legal
> documents, and
> important for other regime-type operations as well.  For tax
> calculations, the
> currency of the incoming values as well as the currency of the
> result must be
> specified.  Other cross-border services will likely require other
> types of
> information, such as address formats or some sort of legal status
> indicator.
>
> Scenario A:  Web service A takes in the value of a sale, the
> currency used in
> the sale and an optional currency preferred for the tax value, a language
> parameter, the name of the city, the province, state, county, and/or
> principality, and the country name.  Service A then calls a set
> of services,
> translating names into identifiers.  Service B takes in a city
> id, a monetary
> value, and a currency, then calculates city sales tax based on
> current tax
> tables it retrieves from other services; it returns the tax
> amount in the same
> currency.  Service C performs a similar function for taxes at the
> provincial,
> state, county, and principality level.  It returns one or more
> values with tags
> as to which tax the value represents.  Likewise, Service D takes
> the country
> name and returns a series of values with tags.  Service A then takes the
> returned values, converts them into the preferred currency (if
> provided), and
> returns the values with identifying tags and the currency.
>
> Scenario B:  An application provides ordering capabilities for a
> number of
> products, via a detailed choreography of Web services.  The
> products are known
> and categorized.  Web service X takes the country id of origin of
> the product,
> the country id of the potential buyer, and the product category.
> It looks up
> the product category in a database and and determines whether it
> is legal to
> sell and/or to ship the product to the buyer.
>
> Scenario C:  Web service M takes a country id, looks it up in a
> database, and
> return the driving rules for that country.
>
> --
> I have always wished that my computer would be as easy to use as
> my telephone.
> My wish has come true. I no longer know how to use my telephone.
> -Bjarne Stroustrup, designer of C++ programming language (1950- )

Received on Friday, 19 March 2004 17:36:39 UTC