Re: [ubl] A Codelist Issue

[jon.bosak@sun.com]

This looks to me like the same use case; the only difference is
that the trigger for the creation of an expanded special-use code
list came from IBM rather than BSI.  You're going to go through
the same committee meetings and the same software revision to
implement this change that you would in my original example.

So my question remains: how much work total have we saved at the
expense of using a mechanism we explicitly ruled out for the rest
of the specification?

If you are saying that this would allow valid UBL instances to
include currency codes from alien namespaces without changing the
namespace of the instance, I believe that we are all agreed now
that this would be a bug, not a feature.  If instances are going
to be coming into my system that have unexpected currency codes,
then I want those instances to carry a namespace that tells me up
front that they have data structures that my system doesn't know
how to handle.

(Bear in mind that I am not an XSD guru, so if I'm missing
something here, let me know.)

Jon

   From: Burnsmarty@aol.com
   Date: Thu, 11 Mar 2004 16:05:12 EST

   In a message dated 3/11/2004 3:48:10 PM Eastern Standard Time, 
   jon.bosak@sun.com writes:

   | 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
   Jon, 

   Substitution groups are not trying to address this use case which I think 
   would procede as you describe.

   Now, however, let us say we have produced UBL 1.1 and IBM wants to make an 
   agreement with its suppliers to use ubl and wants to enable "IBM" bucks as a 
   currency. They would be able to do so by defining the IBM namespace, import  the 
   UBL namespace(s) and define their own schema extension as follows (fragment 
   shown):

   |-----------------------------------------------------------------------------
   ---------------

    <xs:element name="CurrencyCode" substitutionGroup="cur:CurrencyCodeA">
     <xs:complexType>
      <xs:simpleContent>
       <xs:extension base="CurrencyCodeContentType">
	<xs:attribute name="codeListID" type="xs:normalizedString" fixed="IBM"/>
	<xs:attribute name="codeListAgencyID" type="xs:token" fixed="0"/>
	<xs:attribute name="codeListVersionID" type="xs:string" fixed="0000f"/>
       </xs:extension>
      </xs:simpleContent>
     </xs:complexType>
    </xs:element>

    <xs:simpleType name="CurrencyCodeContentType">
     <xs:union memberTypes="iso4217:CurrencyCodeContentType">
      <xs:simpleType>
       <xs:restriction base="xs:normalizedString">
	<xs:enumeration value="IBM"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:union>
    </xs:simpleType>


   |-----------------------------------------------------------------------------
   ---------------

   With this definition, instance documents could use the following anywhere in 
   the ubl schemas cur:CurrencyCode was used:

   <ibm:CurrencyCode>IBM</ibm:CurrencyCode>

   |-----------------------------------------------------------------------------
   ---------------

   Marty