OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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: Burnsmarty@aol.com [mailto:Burnsmarty@aol.com]
Sent: Monday, 28 November 2005 1515
To: GrimleyMJ@Npt.NUWC.Navy.Mil; abcoates@londonmarketsystems.com; stephen_green@bristol-city.gov.uk
Cc: mavis.cournane@cognitran.com; Jon.Bosak@sun.com; mark.palmer@nist.gov
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, GrimleyMJ@Npt.NUWC.Navy.Mil 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    


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]