MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] A Codelist Issue
[Burnsmarty@aol.com:]
| By requiring a user or group of users to only define their
| differences and use unaltered UBL and third party code lists, for
| that matter, we facilitate a robust application of the technology
| and an evolutionary path forward.
I'm not seeing the big advantage here over just deciding to use a
revised code list schema.
Let's say that we've agreed to use BSI currency codes, and now BSI
adds a new one (as they did a few years ago with the euro). Now
we need to agree that we need to support the new value -- that's
some committee meetings right there -- and then we need to revise
our currency schema to validate "euro," and then we also need to
revise all of our software to process euros (which is *not*
accomplished simply by revising the schemas to validate "euro" --
quite the opposite, in fact). In light of all this, what's the
incremental work saved by using the substitution group mechanism
over just agreeing to use an updated version of the currency code
list schema?
Jon
From: Burnsmarty@aol.com
Date: Thu, 11 Mar 2004 14:50:16 EST
CC: ubl@lists.oasis-open.org, mark.palmer@nist.gov
Stephen,
The reason for needing substitution groups is so that vendors can make
agreements beyond UBL. That is, when company A and company B want to use UBL + a
couple of their own definitions, substitution groups allows them to do so for
code lists. Yes, of course they must identify their changes with a new namespace.
But this mechanism allows them to do so with a single definition of a union
of the original list and their extensions that would be able to apply wherever
that code list was in use.
The NIST eBSC committee has studied this problem for many months. The initial
UBL efforts, last year, originally gave up on extending enumerated values
because of this problem. We have been unable to find any other XMLSchema
mechanism to support this.
Since standards making bodies and consortia cannot always be instantly
responsive to changes in market needs, it is essential to provide users with the
ability to add to or subtract from the core models without having to alter the
underlying ubl models.
By requiring a user or group of users to only define their differences and
use unaltered UBL and third party code lists, for that matter, we facilitate a
robust application of the technology and an evolutionary path forward.
Hope this helps,
Marty
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]