[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-comment] Code list rules document
Hi Eve, Thanks for your prompt reply. What you say is quite true there are a number of ways of handling hierarchical code lists. The question is what should be recommended and can we have a Schema for the recommendation. Lets take a very simple example. Countries and their sub regions(States US, France Departements, UK Counties, Germany Laender etc.in one list. At the country level we have established code lists.Quite clearly if a user selects US as the country he/she cannot select Languedoc as the region since that is peculiar to France. Also bear in mind that there may be no set of codes for the UK counties - just the names in full. Another question the above scenario raises is where does the 'data' end and where does the particular implementation - in s/w terms begin. Cheers, Phil. -----Original Message----- From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: 27 August 2002 19:00 To: Philip Goatly Cc: ubl-ndrsc@lists.oasis-open.org; ubl-comment@lists.oasis-open.org Subject: Re: [ubl-comment] Code list rules document 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 > > -----Original Message----- > From: Philip Goatly > Sent: 27 August 2002 09:13 > To: 'eve.maler@sun.com'; ubl-ndrsc@lists.oasis-open.org; > ubl-comment@lists.oasis-open.org > Subject: RE: [ubl-comment] Code list rules document > > > Folks, > > Have I missed something? What about hierarchical code lists e.g UN/LOCODES 2 level Country-Location and > UN/SPSC codes which involves 4 levels. > > If I have n't missed something - I am very disappointed that the consideration of code lists should > have been conducted at such a naive level. > > Cheers, Phil > > -----Original Message----- > From: Eve Maler - Sun Microsystems [mailto:Eve.Maler@sun.com] > Sent: 25 August 2002 22:13 > To: ubl-ndrsc@lists.oasis-open.org; ubl-comment@lists.oasis-open.org > Subject: [ubl-comment] Code list rules document > > > I have managed to finish a real draft of the code list rules document. > This document extracts and expands on the code list rules that were in > the most recent public snapshot of the NDR document (draft 12). While > there are a few outstanding issues, I think it's largely usable in its > current state. I hope you all will give this a careful review, try it > out, and send your comments in. > > In my current technical circumstances I'm unable to attach files to > email messages -- perhaps a blessing! I have FTP'd the relevant files > to both the NDR archive and the "current" directory (Mavis, could you > please update the NDR portal?): > > http://www.oasis-open.org/committees/ubl/ndrsc/archive/wd-ublndrsc-codelist-01.doc > http://www.oasis-open.org/committees/ubl/ndrsc/archive/wd-ublndrsc-codelist-01.pdf > http://www.oasis-open.org/committees/ubl/ndrsc/archive/CodeListModuleTemplate.xsd > > Thanks, > > Eve -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 883 5917 XML Web Services / Industry Initiatives eve.maler @ sun.com _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC