RE: [ubl-comment] Code list rules document

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

I believe that the recommendation as it stands does precisely what you want Terry.  See the codelist module template (schema) for an example.  

The iso3166:CodeType extends iso3166:CodeContentType with three fixed attributes: ID (fixed to "ISO 3166"), agencyID (fixed to "6"), and versionID (fixed to "0.2").  That means that the PSVI for a node of type iso3166:CodeType will always have these three attributes with those three values.  So, while in the instance document, you see a nice, readable (perhaps):

...
<ShippingAddress>
 <PostalZoneId>75075</PostalZoneId>
 <CountryIdentificationCode>AF</CountryIdentificationCode>
...

So an XML processor (such as an XSLT stylesheet) is able to (automatically) validate the code content (in this case "AF") and the stylesheet "sees" not only the content, but the metadata (the ID, agencyID and versionID attributes).

As for external maintenance (i.e. maintenance by the agencies -- not by UBL), again I believe that is the intent of the proposal.  The purpose of having the (complex) code type "wrapping" the (usually simple) code content type is that the latter is usually provided by the agency.  So if an agency provides something as basic as a simple type with a bunch of enumerations (like the example) then it's easy for UBL to "wrap" that in a complex type (adding the descriptive PSVI metadata) and viola!  If the agencies decide to adopt the metadata practice too, then so much the better -- UBL won't have to do any wrappering at all.

That's how I understand it anyway.

Bill Burcham
Sr. Software Architect, Standards and Applied Technology
Sterling Commerce, Inc.
469.524.2164
bill_burcham@stercomm.com <mailto:bill_burcham@stercomm.com>

-----Original Message-----
From: Terry Schager [mailto:tschager@earthlink.net]
Sent: Friday, August 30, 2002 6:22 AM
To: Eve L. Maler; Philip Goatly
Cc: ubl-ndrsc@lists.oasis-open.org; ubl-comment@lists.oasis-open.org
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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>