- From: Addison Phillips [wM] <aphillips@webmethods.com>
- Date: Tue, 13 Apr 2004 16:30:05 -0700
- To: <andrea.vine@Sun.COM>, "I18n WSTF" <public-i18n-ws@w3.org>
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