[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]