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
<mailto:>
-----Original Message-----
From: Terry Schager [mailto:]
Sent: Friday,
August 30, 2002 6:22 AM
To: Eve L. Maler; Philip Goatly
Cc:
;
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)
-----Original Message-----
From:
Eve L. Maler [mailto:]
Sent: Thursday,
August 29, 2002 2:54 PM
To: Philip Goatly
Cc:
;
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>
