ubl-ndrsc — archive

[ubl-ndrsc] Re: [ubl-comment] Code list rules document

From: Eve Maler
To: [email protected]
Date: Tue, 27 Aug 2002 14:00:00 -0000

MHonArc v2.5.2 -->

ubl-ndrsc message

Subject: [ubl-ndrsc] Re: [ubl-comment] Code list rules document

From: "Eve L. Maler" <[email protected]>
To: Philip Goatly <[email protected]>
Date: Tue, 27 Aug 2002 13:59:46 -0400

This is a good question (and one that should be treated in the spec...). 
  This architecture doesn't prevent any hierarchical structuring of 
codes that the agency might desire to reflect in the actual code data. 
For example, this could be done with subelements in the inner code 
element (done as a complex rather than a simple code content type), or 
with punctuation as delimiters (done with pattern-matching on the simple 
code content type, so that, say, hyphens are enforced as the separators).

However, my understanding is that often code lists have elaborate 
classification hierarchies above the level of the actual code, *which 
you can access by reference to the code* and which need not be baked 
into the code string that appears in a message.  For example, if 024581 
(or 02-45-81 or <sub>02</sub><sub>45</sub><sub>81</sub> or whatever) 
means "canned food, baked beans, non-fat", the code as a whole can be 
treated as essentially opaque as far as the schema is concerned, while 
still having a sophisticated hierarchy as a code list ontology/taxonomy.

So in practice, an agency, in addition to preparing a reuse-ready code 
list module that could be pulled into vocabularies such as UBL, might 
very well have one or more data-dictionary representations of the code 
list that supply all of the definitions, parental relationships, etc.

Of course, there are various XML and non-XML formats already used for 
formally defining code lists in this way.  The UBL recommendations don't 
try to address this use case at all, but rather try to ensure the actual 
usage of codes in an instance.  As an example, I believe the UNECE code 
list schemas are never intended to have instances, so there are some 
reuse criteria that they don't satisfy.

Does this satisfy your concern?  If not, do you have suggestions on how 
the spec should change?

Thanks,

	Eve

Philip Goatly wrote:
> Sorry UB/SPSC should read UN/SPSC
> 
> Cheers, Phil
> 
>