[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-comment] Code list rules document
Eve, You might consider the approach a few of the X12 and old TDCC Code tables adopted where the code provided pointed you to an agency (like AIA, AIAG, GCA, UCC, etc.) The agencies themselves maintain the code lists and take care of subscription or some other form of dissemination. As long as the agency qualifier is included in what re two conditional elements, document integrity is maintained. This benefits UBL because a code qualifier for a value is provided and it benefits the companies in a vertical industry because they are using codes they see relevance in (and are probably using already in back end apps or their EDI processing. Thoughts? Terry Schager Principal Aeon Consulting 322 Pleasant Hill Rd. Landrum, SC 29356 864.468.5429 (H) 864.360.1549 (M) tschager@earthlink.net -----Original Message----- From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: Thursday, August 29, 2002 2:54 PM To: Philip Goatly Cc: ubl-ndrsc@lists.oasis-open.org; ubl-comment@lists.oasis-open.org Subject: Re: [ubl-comment] Code list rules document The NDR group was trying to stay away from dictating the XML representation of the actual codes for any list, because UBL itself is able to be agnostic on this. (UBL doesn't want to be in the code list business at all, if it can help it!) The rules we've developed allow for a clean layering of implementation, so that you can have a plug-in/library/whatever for particular code lists that is separable from the UBL-specific handling. However, if our other recommendations start to be widely adopted, I suppose the issue of XML representations for codes could be an eventual direction for our NDR work if someone else doesn't get there first. (I've occasionally heard of some projects like this...) In any case, though, XSD isn't capable of capturing the context-specific constraints that you talk about below. For example, if you have two elements inside a code, one for the "higher-order bit" (like country) and one for the "lower-order bit" (like region within a country), XSD won't allow you to forbid the choice of "Languedoc" in the lower-order element based on "USA" being the content of the higher-order one. You'd need something more like Schematron or RELAX NG (?) for these sorts of constraints. Actually, RDF would be an interesting choice because it allows for arbitrary graphed relationships, not just hierarchies. Eve Philip Goatly wrote: > 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. -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 883 5917 XML Web Services / Industry Initiatives eve.maler @ sun.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC