RE: [ubl-dev] Hybrid approach to local vs. global

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2007-03-01 08:32 -0700, David RR Webber \(XML\) wrote:
>I'm not wanting to re-visit with Ken on the "it's not UBL if it does not
>have the namespaces and the XSD".

I feel a bit restrained here :{)} so rather than repeat myself I'll 
try a new tack.

>What CAM can do for people is get them out of a practical hole with
>their XML and allow them to bridge to formal UBL depending on their
>operational needs and their partner systems.
>
>The key is - as you get more fielded UBL implementations out there -
>these production needs will drive future development of the standard
>and the practical tools used to support it.
>
>For example - if the Russian Government said - "we'd love to use UBL -
>but we need different tagnames for in country use" - then having the
>option to use CAM to morph between localization details and say an EU
>base-line - would obviously be enabling... and overall I'm guessing the
>bigger goal is UBL adoption and use, rather than say driving XSD
>adoption and use!?!

This isn't a new idea and my comments regarding not supporting this 
have nothing to do with CAM.  ISO/IEC 19757-8 Document Schema 
Renaming Language (DSRL) was also posited to address the use case of 
a community of UBL users wanting to have "local" names for a 
transliterated (not transformed) document vocabulary equivalent in 
structure to UBL.  This has already been discussed.

Perhaps when we start seeing Java languages with the keywords 
transliterated to Russian, or DocBook with the vocabulary 
transliterated to Japanese, or any widely distributed computer-based 
vocabulary requiring localized vocabularies in order to gain 
acceptance ... then the UBL TC might even entertain a notion to start 
thinking about considering what possible benefit there might 
potentially be ... but until then the localization argument for 
acceptance and "drive for future development" is totally 
disingenuous.  The predominant use of any set of mnemonics for 
worldwide compatibility is there for just that, worldwide 
compatibility.  If someone develops a Java application using Russian 
keywords, they then burden the rest of the world with having to 
transliterate that work into the standardized Java keywords for the 
Java systems in the rest of the world to operate.

Have we seen localized versions of HTML?  If someone posted a web 
page using a localized version of the HTML vocabulary would anyone 
else's browser understand it?  Did the English language use of 
mnemonics in the HTML vocabulary prevent worldwide adoption?

As the mnemonics in a UBL instance are not meant to be documentary 
(though were chosen to give a hint to human readers of the English 
language), UBL instances will be created by computer programs that 
will have plug and play localized user interfaces.

We are talking document interchange here ... how many users will be 
editing UBL by hand?

I'm very worried that readers of the archive will be misled into 
thinking that a localized vocabulary of anything (not just UBL) is 
somehow equivalent to a standardized vocabulary.

What *possible* benefit is there for a computer program, indeed why 
would it not be considered a burden on a computer program, to have to 
consider transliterated vocabularies when a standardized vocabulary 
is needed for interchange?  Working with markup is behind the scenes 
... users see program interfaces ... only when all tools break down 
that a user has to actually look at angle brackets, the choice of 
language of the basis of the mnemonics isn't necessary since the 
reference documentation exists.  We are talking here about fallback 
contingencies, not day-to-day work.

I hope readers of the archive will consider the vast worldwide 
acceptance of a single set of keywords for a given vocabulary of 
anything (e.g. Java, SQL, HTML, etc.) promotes more interoperability 
than introducing localized versions of anything that is dealt with by 
computer programs.

I hope this has added a fresh look at the issue and is not considered 
a rehash.  Please don't make out there is a problem when the evidence 
of the worldwide acceptance of popular vocabularies proves there is 
no such issue.

I truly hope this helps.

. . . . . . . . . . . . . Ken

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal