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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[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