Re: [ubl] A Codelist Issue

[jon.bosak@sun.com]

[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