[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]