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

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]