Subject: Clarification of Ottawa Code List Deceisions (Was RE: (no subject ))
(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: