RE: 4.15.1 Modeling Tax, Customs, Legal, and Other Cross-Border and Cultural Considerations

I incorporated Andrea's text, but didn't modify the section structure.

With regard to Andrea's questions, I'm starting to feel that this section
might be a rathole that doesn't really demonstrate anything germane to WS
technology...

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: Tuesday, April 13, 2004 3:04 PM
> To: I18n WSTF
> Subject: 4.15.1 Modeling Tax, Customs, Legal, and Other Cross-Border and
> Cultural Considerations
>
>
>
> One comment, we have a section 4.15, with no intro paragraph and
> one subsection
> 4.15.1.  We should either consolidate it all under 4.15, or come
> up with at
> least one more subsection and an intro paragraph.
>
> I broke out Scenario A with a simplification, then a what if, to show the
> complexities of cross-border services.  I felt like it was
> important to point
> out just how complex such a service is when serving multiple countries.
>
> I made some minor edits to Scenarios B and C.
>
> ---------------------------------------
> 4.15.1 Modeling Tax, Customs, Legal, and Other Cross-Border and Cultural
> Considerations
>
> {leave first 2 paragraphs as is, or not}
>
> Scenario A:  Web service A, specific to a country C, takes in the
> value of a
> sale, a language parameter, and the names of the city and the
> province.  The
> currency is limited to country C's official currency.  Service A
> then calls a
> set of services, translating names into identifiers.  Service B
> takes in a city
> id and a monetary value, then calculates city sales tax based on
> current tax
> tables it retrieves from other services; it returns the tax
> amount as a numeric
> value.  Service C performs a similar function for taxes at the
> provincial level.
>     Service A then takes those monetary values and returns them
> with identifying
> tags for the city and provincial tax.
>
> If Service A were to be used for multiple countries, there would
> have to be
> additional parameters, for example:
>
> 	o a country identifier
> 	o other regional identifiers, such as county and state
> 	o a currency identifier
>
> There would have to be a function to handle currency
> calculations, possibly in a
> separate service.  The additional tax regions need to be managed,
> again by
> separate services.
>
> Scenario B:  An application uses a Web service to send DVDs to
> rental customers
> around the world. DVDs contain a region code that limits where
> they can be
> played (according to the country they are intended for.) The Web
> service takes
> the country ID of of the customer and selects the right region
> code DVD to send.
>
> Scenario C:  Web service M takes a country ID, looks it up in a
> database, and
> returns the driving rules for that country.
> ---------------------------------------------
>
> I'm not sure what other subsections would fit into this category.
>  I had a
> thought about a scenario of a service which took a product code
> and looked up
> whether it was legal to ship that type of product to the country
> identified as
> the destination.  But it seemed a bit complex to have as a service.
>
> Anyone else have an idea what might be included in this section?
>
> Andrea
> --
> 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 Tuesday, 13 April 2004 19:35:56 UTC