Re: [ubl] UBL, localization (customization)

[jon.bosak@sun.com]

[DVINT@acord.org:]

| Is this "customization" to add tags that are need for their
| business purposes? Then customization agrees with our use in
| ACORD. We have service provider extensions (IFX term) that
| customize our schema for a trading partner by adding and removing
| elements and code values.

Yes, I believe that's the idea (though I sincerely hope that UBL
2.0 can be customized for national use simply by turning off some
features rather than by adding any).

| OR are you talking about changing the name of an existing tag from
| an English word to a Danish word? This I would call something
| different.

Indeed... something different from "UBL."  There is only one
version of the tags themselves.

| Pardon my ignorance here, but related to this
| localization/internationalization question is; How would be issues
| with currency and units of measure and even presentation of data
| values when they are displayed be handled or considered in this
| question.

The presentation of data is a classic localization issue in the
proper sense of the word.  If, for example, the internal date
format is 2005-12-09, then whether to present this to the user as
"2005.12.09" or "9/12/05" is a paradigmatic localization
question.  Ditto for currencies (whether the currency symbol is
displayed before or after the quantity), numerics (whether to
indicate the decimal point with a full stop or a comma), etc.

| Is that already somewhat handled by the international nature of
| these documents and their basic requirements or is this something
| that also needs some specification and control?

I believe that UBL has done a pretty good job of internally
representing all such data in a locale-independent manner, so the
specification of locale-specific presentation rules is going to be
up to localization experts in each area.  This is why software
localization is almost always carried out by teams based in the
target locales.

Jon