Clarification of Ottawa Code List Deceisions (Was RE: (no subject ))

Greetings,

 

(Because we are now discussing interpretations of 
decisions made as a group, I thought it best to include the whole 
list.)

 

Good, now at least all of our assumptions have been 
placed on the table (mine and Marty's). Let's see if we can reach agreement on 
some of them.

 

Again, a refresher on the two types of code 
lists from Ottawa:
    a. Code lists that define codes used only in UBL (status codes, for example). Such lists are 
typically well-defined, are completely 
under our control, and are not (or should 
not be) extensible.
    b. Code lists that are defined by 
outside agencies and referenced in UBL. 
These are conceptually distinct from the 
first category even if some happen to be bundled into the UBL package.

 

 

> I think that 
regardless of whether it is a type a) or type b) code list, it needs to have a 
data model and a schema in UBL. I think that the idea is to use genericode for 
the data model and generate a schema for incorporation into the UBL schema 
set.

> What I am suggesting is 
that the data model and the schema's generated from it (Tony has the data modem 
and which I have suggested a generated schema format for) become the 
normative part of the UBL deliverables.

 

Does everyone else agree that a schema for type-b code lists 
should be required for UBL deliveries? Should it be 
normative?

 

If a customizer needs to add a code to a type-b code list, 
shouldn't they just add another 'Row' to the Genericode XML instance for that 
list? They could then create a new schema, if desired, using the provided 
stylesheet. Wasn't the difficulty in extending schemas one of the motivating 
factors of the Ottawa decision?

 

 

> I might also point out that if 
you accept that a user of UBL might want to customize a type b) code list, it is 
hard to suggest that he be precluded from customizing a type a) code list since 
both would be external to him.

 

When differentiating between the the two types of codes, the group 
decided (assumed?) that type-a code lists "are completely under our 
control, and are not (or should not be) 
extensible". Does anyone disagree with this?

 

 

> The 
distinction of UBL or non-UBL provides a perspective difference if its ours (UBL 
committee) or theirs (third party). For a user its theirs or theirs, if you get 
my inference

 

The distinction is those "that define codes used only in UBL 
(status codes, for example)" and those 
"that are defined by outside agencies and 
referenced in UBL". This distinction is valid from any perspective, 
particularly when we are talking about codes used in UBL 
'documents'.

 

 

Also, if you haven't already done so, please revisit the Ottawa 
discussions and decisions:

    
http://lists.oasis-open.org/archives/ubl/200508/msg00042.html
    http://lists.oasis-open.org/archives/ubl/200508/msg00060.html

 

Thank You,

Mike

  

  
  From:  [mailto:] 
  
Sent: Monday, 28 November 2005 1515
To: 
  ; ; 
  
Cc: ; 
  ; 
Subject: Re: (no 
  subject)

  

  

  
Mike,

  
 

  
I think that regardless of whether it is a type a) or type b) code list, 
  it needs to have a data model and a schema in UBL. I think that the idea is to 
  use genericode for the data model and generate a schema for incorporation into 
  the UBL schema set.

  
 

  
What I am suggesting is that the data model and the schema's generated 
  from it (Tony has the data modem and which I have suggested a generated 
  schema format for) become the normative part of the UBL deliverables. In 
  addition, the Schematron generation XSLT's and related validation tools would 
  become informative parts of UBL (this simplifies our version control task, I 
  believe).

  
 

  
I might also point out that if you accept that a user of UBL might want 
  to customize a type b) code list, it is hard to suggest that he be precluded 
  from customizing a type a) code list since both would be external to him. The 
  distinction of UBL or non-UBL provides a perspective difference if its ours 
  (UBL committee) or theirs (third party). For a user its theirs or theirs, if 
  you get my inference.

  
 

  
Marty

  
 

  
In a message dated 11/28/2005 11:52:10 A.M. Eastern Standard Time, 
   writes:

  
    
 

    
A few basic questions just to make sure we are all on 
    the same page:

    
 

    
First a refresher on the two types of code lists from 
    Ottawa:
    a. Code lists that define codes used only in UBL (status codes, for example). Such lists are 
    typically well-defined, are completely 
    under our control, and are not (or 
    should not be) extensible.
    b. Code lists that are defined by outside 
    agencies and referenced in UBL. These 
    are conceptually distinct from the 
    first category even if some happen to be bundled into the UBL package.

    

    
Now, if we are talking about type-a 
    code lists, aren't 
    we talking about versioning and, 
    therefore, can use redefine as with other schema versioning?

    
If we are talking type-b code lists, 
    then haven't we decided that they are to be 
    represented in XML according to the genericode schema? Extensions to those code lists can simply 
    be done by adding another 'Row' element to the existing XML.

    
Am I missing something? Which 
    schema are we discussing here? 
    Are we referring to the schema that is developed via XSLT from the type-b 
    code list? If that's the case, then customization is not an issue because it 
    is done via the XML, right?

    
Thank You,

    
Mike