Re: [ubl-ttsc] Re: [ubl] Use cases (UBL compliance)

[jon.bosak@sun.com]

[abcoates@londonmarketsystems.com:]

| I have never yet supported the concept multiple language versions
| of XML element/attribute names for any specification I have worked
| on.

[etc.]

I'm traveling all over the place for the next two weeks, so I'm
not really in a position to engage in a debate on this subject.
But I do want to make sure that everyone is completely clear that
we are *not* in any way contemplating multiple language versions
of UBL documents.

The question of how we go about making industry-specific versions
of the UBL schemas is a huge one; it's an issue to which we will
have to devote a good deal of thought and discussion as we
consider developments after the release of UBL 1.0.  The question
of how we might then multiply each industry-specific version by X
number of natural languages simply boggles the mind.  It is way
beyond our scope.  Doing this is simply not on the table.

What is within our scope (or at least within the scope of each of
our localization subcommittees) is the preparation of lookup
tables for each locale that will give a locale-specific version of
each tripartite UBL dictionary name and each UBL tag and attribute
name.  Given such tables, any first-semester programming student
can easily construct a perl script that changes any normative UBL
instance into a non-normative "local" version if such a thing is
felt to be useful.  But there can only be one "real" UBL instance,
and that's the one that uses the names we've normatively defined.

The primary users of the localized lookup tables will be software
developers constructing UBL forms input tools; these people will
need the localized names for making menus, checklists, and other
GUI components.  But the product of such software can only be UBL
documents conforming to our normative schemas, and those schemas
will use only the names that we've spent the last two years
assigning.

Jon