Re: [ubl] A Codelist Issue

[Tim McGrath <tmcgrath@portcomm.com.au>]

anne is correct that it does appear as if the separate code list schemas 
removes the need for specialised data type definitions.  if we compaore 
what was in the sdt for version 7-1 to that of the code list schemas 
suggested for 8-1 (even though the names have changed) we can see they 
duplicate each other.

furthermore, as we don't define any non-standard codes separating the 
standard from the non-standard seems unnecessary.

there seems to have crept into UBL a believe that we have to have 
schemas for every artifact the CCTS defines.  i dont see this as being 
true.just because CCTS has one cct, one udt and one sdt does not mean we 
have to implement them each as individual schema.  in fact, the CCTS 
does not even explicitly say one cct, one udt and one sdt. as far as i 
can see from the documentation, this is an NDR developed  idea.  CCTS 
just says we need Data Types derived from Core Component Types - it does 
not (and should not) say how this is done. (refer to the CCTS infamous 
figure 7-1).  we should not confuse the idea of the CCTS architecture 
with the implementation in XSD.  

the bottom line is that what anne says about our code list schemas being 
specialised data type defintions is correct. i believe that is exactly 
what they are.  we chose the implement them as separate schemas so we 
can outsource them to code list agencies and swap them in and out more 
easily.

if, at some future stage, we see we need other (none-code) specialised 
data types we could use a single schema to define these, but again it is 
not a CCTS constraint.  if we want to create any 'null' schemas then the 
sdt is the one i would choose.



Anne Hendry wrote:

> Well, yes, I was wondering myself what woudl be going into one that 
> wasn't in the other (cldt vs. sdt).  Not knowing enough about schema 
> really to know what the need was, but looking at your model, I'd say 
> there was no difference and therefore would not need both.  But, this 
> really only applies to code lists, correct?  I mean, if we decided 
> later to specialize some other datat types we would need the sdt.  
> It's just that we currently don't have anything other than cls that 
> are specialized right now?
>
> So I must confess that other than the distinction that was made 
> earlier - sdt could hold enumerated code lists of the codes taht are 
> truly UBL hard-wired - and all other codes would be files of their own 
> (code list schema modules) that could be somewhat repaceable - I don't 
> see what the difference is, unless we have non-code specialized data 
> types, that is, which at the moment I don't believe we do.
>
> Is there some type of interop or extensibility lost by not including 
> an sdt as separate from the code list schemas?  Can it be added later 
> when there is something to put in it?  In essence, the cl schemas 
> becomes the sdt, there are just multiple of them.  If there was an sdt 
> added later, would that cause backward compatibility issues?  Is the 
> problem trying to be solved by removing it worth the risk?
>
> -Anne
>
> Tim McGrath wrote:
>
>> i agree, this discussion is a sidetrack to the main issue.  lets move 
>> on with what we have (a working prototype) - we need to implement a 
>> solution over the next few days and this debate is not on the 
>> critical path.
>>
>> I am more concerned about the question of demarction between the 
>> CodeList Schema and the Specialised DataTypes - this appears to need 
>> resolution before we can build version 8.0 schemas.
>>
>>
>> Burnsmarty@aol.com wrote:
>>
>>> Thanks, Anne,
>>>  
>>> I obviously believe we should use the code list mechanism as 
>>> proposed and following the example provided last night and as 
>>> revised by Tim.
>>>  
>>> If 1.0 is released without this code list mechanism I am afraid 
>>> there will be no backward compatability if it is added later. The 
>>> premise of having an abstract type and an element used by reference 
>>> is essential to the mechanism. The schema generation has to be 
>>> revised whether this code list mechanism or the old one or any one 
>>> is used.
>>>  
>>> Once this mechanism is established it will be easy for third parties 
>>> to make extensible code list schemas for UBL to use. I think we want 
>>> to encourage this.
>>>  
>>> In addition, this mechanism has been reviewed by the CLSC and other 
>>> UBL-ers as well as leaders of OAGI, Rosettanet, and others at NIST 
>>> and found to be robust and desireable. Lets take advantage of all 
>>> this effort and capture it in the 1.0 version.
>>>  
>>> Marty
>>>  
>>> In a message dated 3/11/2004 5:47:31 PM Eastern Standard Time, 
>>> anne.hendry@sun.com writes:
>>>
>>>     I do see a difference in these use cases.  The first one is where a
>>>     standard organization that owns a standardized code list is
>>>     publishing a
>>>     revision their own code list, in a public forum, and the second
>>>     is where
>>>     some subset of trading partners are extending (not revivsing the
>>>     whole
>>>     thing) an existing code list for their own use by leaving the
>>>     existing
>>>     list in tact but adding to it their required values.  What Marty is
>>>     proposing allows for our earlier notion of 'stock' (or perhaps
>>>     'private') code lists.  The thing is that  since Beta we have
>>>     dropped
>>>     the inclusion of 'stock' and 'private' and now only supply 13
>>>     code lists
>>>     that we've defined as 'standard' ('standard' meaning that UBL
>>>     defines,
>>>     owns, and requires the use of these specific values) code lists
>>>     and all
>>>     the other code lists referenced in our schemas are completely
>>>     open to
>>>     whatever the tps want to use - they are what we originally called
>>>     placebo, and there is no restriction on their use and no
>>>     validation.  We
>>>     have now a white/black situation with no gradation, and Marty's
>>>     proposal
>>>     takes care of some of the in-between cases, but just to be aware
>>>     that
>>>     this proposal would only apply to a very few code lists at the
>>>     moment (3
>>>     maybe at most).
>>>
>>>     There is definitely support for Marty's use case (hopefully
>>>     you'll hear
>>>     from Sylvia shortly about her experience in this area), and Marty's
>>>     proposal seems like it could be considered for 1.1 or 2.0, but the
>>>     reality of the situation at the moment for UBL is that since we 
>>> have
>>>     removed support in the model for all of our other-than-standard 
>>> code
>>>     lists, there is no need in this release to have support for this
>>>     type of
>>>     extensibility - we ourselves would not be making use of it, and 
>>> as I
>>>     said, it would only apply to about 3 code lists max.   I'd
>>>     advocate that
>>>     we acknowledge the need for some type of feature to support Marty's
>>>     case, but that we shelve the implementation of  the solution
>>>     until we
>>>     can come to concensus on an appropriate one, since we do have
>>>     what we
>>>     need at the moment without substitution groups to solve the code
>>>     list
>>>     support we have (the 13 code lists), and then continue this
>>>     discussion
>>>     to try to come to resolution in the near future on this
>>>     requirement (I
>>>     do believe it is a requirement that we'll see the need to support
>>>     shortly).  But this would give us more time to review the
>>>     appropriateness of substitusion groups, or come up with an
>>>     appropriate
>>>     alternative - and still get 1.0 our the door.
>>>
>>>     -Anne
>>>
>>>     jon.bosak@sun.com wrote:
>>>
>>>     >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
>>>     >
>>>     >To unsubscribe from this mailing list (and be removed from the
>>>     roster of the OASIS TC), go to
>>>     
>>> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. 
>>>
>>>     >
>>>     >     >
>>>
>>>
>>>
>>>     To unsubscribe from this mailing list (and be removed from the
>>>     roster of the OASIS TC), go to
>>>     
>>> http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php. 
>>>
>>>
>>
>> -- 
>> regards
>> tim mcgrath
>> phone: +618 93352228  postal: po box 1289   fremantle    western 
>> australia 6160
>>  
>>
>>
>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160