MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Code lists
At 2005-09-16 08:01 -0700, jon.bosak@sun.com wrote:
>In another thread, Ken asked:
>
>| thanks to anyone who can help me with these code list artifacts
>| (genericode instances and code list type catalogue) I need while I
>| write the XSLT for the Schematron.
>
>Is anyone working on this? If not, is there some gruntwork that I
>can contribute here?
I think manual gruntwork won't be repeatable and reliable (no offense
to your ability to do the gruntwork, just that we all make mistakes
and it will be labourious).
Today using XSLT and the latest XPath files for UBL 1.0 CD 2
(recreated tonight because the SBS work added new features to the XPath files):
http://www.oasis-open.org/committees/download.php/14539/UBL-1.0-CD2-XPath-20050919-0440z.zip
... I mechanically created a catalogue in XML but have reported in
text from all document types of UBL 1.0 all of the elements and
attributes with string "Code" in the data type name:
http://www.oasis-open.org/committees/download.php/14538/codelist-contexts-20050919-0510z.zip
ACTION: Could someone please confirm that data types with the string
"Code" in their name are *all* and *only* those data types that are
based on code lists of any kind? If not, then I'll need someone to
enumerate for me all of the data types based on code lists.
This analysis does not distinguish between code lists of type 1 and
code lists of type 2 because I am unaware of any distinctions in the
schemas and understand the distinctions to be business decisions for
each code list. As I had assumed from before, code lists of type 1
will have all enumerations defined in the UBL schemas and code lists
of type 2 will have no enumerations defined in the UBL
schemas. Using assertions as a supplement to schemas, trading
partners may wish to subset the values they use in code lists of type
1 and specify the values they use in code lists of type 2.
Thinking about Schematron and how it is based on XPath, I realized
that context is what is important to two trading partners. Are *all*
uses of a given code list going to require the same set of values, or
will trading partners need to be able to specify which lists are in
which contexts? Schematron could, indeed, allow trading partners to
specify different sets of codes for different contexts of the use of
code lists.
So, what are the unique contexts of elements and attributes whose
data type names include the string "Code"? Lots more than I thought
there would be:
DespatchAdvice: (12 uses of code list data types; 52 unique parents;
1225 unique contexts)
Invoice: (13 uses of code list data types; 41 unique parents; 403
unique contexts)
Order: (14 uses of code list data types; 50 unique parents; 1589
unique contexts)
OrderCancellation: (7 uses of code list data types; 11 unique
parents; 45 unique contexts)
OrderChange: (14 uses of code list data types; 50 unique parents;
1591 unique contexts)
OrderResponse: (13 uses of code list data types; 49 unique parents;
1590 unique contexts)
OrderResponseSimple: (7 uses of code list data types; 11 unique
parents; 45 unique contexts)
ReceiptAdvice: (12 uses of code list data types; 38 unique parents;
945 unique contexts)
To read the above, consider something simple like OrderCancellation
and this is the full report from the ZIP file:
===8<---
OrderCancellation: (7 uses of code list data types; 11 unique
parents; 45 unique contexts)
chn:ChannelCodeType: (1 unique parent; 5 unique contexts)
cac:BuyerParty/cac:Party/cac:Contact/cac:OtherCommunication/cac:ChannelCode
cac:SellerParty/cac:Party/cac:Contact/cac:OtherCommunication/cac:ChannelCode
cac:ShippingContact/cac:OtherCommunication/cac:ChannelCode
cac:AccountsContact/cac:OtherCommunication/cac:ChannelCode
cac:OrderContact/cac:OtherCommunication/cac:ChannelCode
cnt:CountryIdentificationCodeType: (1 unique parent; 6 unique contexts)
cac:BuyerParty/cac:Party/cac:Address/cac:Country/cac:IdentificationCode
cac:SellerParty/cac:Party/cac:Address/cac:Country/cac:IdentificationCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:Country/cac:IdentificationCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:Country/cac:IdentificationCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:Country/cac:IdentificationCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:Country/cac:IdentificationCode
cur:CurrencyCodeType: (1 unique parent; 2 unique contexts)
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:CurrencyCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:CurrencyCode
lat:LatitudeDirectionCodeType: (1 unique parent; 6 unique contexts)
cac:BuyerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:LatitudeDirectionCode
cac:SellerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:LatitudeDirectionCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:LatitudeDirectionCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:LatitudeDirectionCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:LatitudeDirectionCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:LatitudeDirectionCode
lon:LongitudeDirectionCodeType: (1 unique parent; 6 unique contexts)
cac:BuyerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:LongitudeDirectionCode
cac:SellerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:LongitudeDirectionCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:LongitudeDirectionCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:LongitudeDirectionCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:LongitudeDirectionCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:LongitudeDirectionCode
stat:DocumentStatusCodeType: (1 unique parent; 2 unique contexts)
xo:OrderCancellation/xo:DocumentStatusCode
cac:OrderReference/xo:DocumentStatusCode
udt:CodeType: (5 unique parents; 18 unique contexts)
cac:BuyerParty/cac:Party/cac:Address/cac:CountrySubentityCode
cac:SellerParty/cac:Party/cac:Address/cac:CountrySubentityCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:CountrySubentityCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:CountrySubentityCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:CountrySubentityCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:CountrySubentityCode
cac:BuyerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:SellerParty/cac:Party/cac:Address/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:RegistrationAddress/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:JurisdictionAddress/cac:LocationCoordinate/cac:CoordinateSystemCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxLevelCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxLevelCode
cac:BuyerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:TaxTypeCode
cac:SellerParty/cac:Party/cac:PartyTaxScheme/cac:TaxScheme/cac:TaxTypeCode
cac:BuyerParty/cac:Party/cac:Language/cac:LocaleCode
cac:SellerParty/cac:Party/cac:Language/cac:LocaleCode
===8<---
Trading partners need to consider for this document type 7 different
code lists. There are 11 elements or attributes that use these 7
different code lists, and they could, therefore, have 11 different
one-level contexts in which to use different sets of values. At the
extreme, however, trading partners actually have 45 different
contexts of ancestry in which the code lists can be distinguished, so
could, theoretically, use 45 different sets of values in the
different contexts or any combination thereof.
Now that I have all of the contexts, I can generate the Schematron
assertions for the values in every context. I think it is obvious
that generating them on each and every context (almost 1600 contexts
for OrderResponse) does not make sense. I don't see a problem,
however, of my doing the following with automated tasks:
(1) - create a set of Schematron assertions for a set of code
lists values for each parent context of the code list data type
(2) - separately enumerate for trading partners all of the code
list contexts so that they can choose where they might want to use
different sets of values for given code lists
Trading partners can then decide which subsets of the code lists they
want to use where and modify the Schematron assertions accordingly.
But how to package this? I can almost see the shape of an XML
instance agreed upon by trading partners that captures all of the
enumerations for each of the uses of data types in the contexts that
are of import to the trading partners, and then each synthesizing the
Schematron assertions from this one agreed-upon XML instance. Using
genericode perhaps it isn't a single instance but a package of a
control instance pointing to genericode instances. This sounds very
complex (and I guess it is in some ways), but I believe it is
guaranteed to be accurate and complete because it is methodical and
synthesized. When done mechanically, one might have a level of
assurance not gained by specifying these things in an ad-hoc fashion
between trading partners.
Please note the action item above listed below the hyperlinks, as
this will tell me if my list of code list based data types is
complete. My list is purely mechanical ... it will only be accurate
if only those and all those data types based on code list values
include the string "Code" in the data type name.
When the list is complete, I then need someone to (manually)
characterize each code list as type 1 or type 2 (or tell me how I can
tell the difference in my stylesheet; could this characterization be
annotated in UBL 2.0 somehow?). For type 1 I should be able to go
into the schema files and recreate the list of values for use in the
assertions.
I'm thinking that we need to package this enormous amount of
information in such a way that trading partners realize that the
schemas only do so much and that assertions will do additional stuff
but that assertions don't need to be used everywhere but there are
very many places where they could be used if that kind of fidelity is needed.
I hope this makes sense and the time I've put into this hasn't been
off on a tangent. I'm expecting to phone in Monday evening/Tuesday
morning Pacific call and I will entertain any questions about what
I've done here.
Thanks!
. . . . . . . Ken
--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]