[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: VS: [ubl] Agenda for Pacific UBL TC call 12 July 2010
At 2010-07-14 16:37 +0200, Peter L. Borresen wrote: >Comment to report (compared between UBL-2.1-models-20100629-1202z and OS UBL >2.0) > >Cardinalities found in error: 22 >"Application Response. Version Identifier. Identifier" old= 0..1 new= | >plb: no differences found There is a difference: the June 29 models have "Application Response. Version. Identifier" >"Certificate Of Origin. Version Identifier. Identifier" old= 0..1 new= | >plb: no differences found There is a difference: the June 29 models have "Certificate Of Origin. Version. Identifier" >"Consignment. Transport_ Contract. Contract" old= 0..1 new= | plb: >UBL 2.0 is correct Fine. >"Goods Item. Value. Amount" old= 0..1 new= | >plb: UBL 2.1 is correct (Value Amount. Amount) Do we keep the old name for semantic equivalence to UBL 2.0? >"Item Comparison. Price. Amount" old= 0..1 new= | plb: UBL 2.1 >is correct (price Amount. Amount) Do we keep the old name for semantic equivalence to UBL 2.0? >"Monetary Total. Allowance Total Amount. Amount" old= 0..1 new= | >plb: UBL 2.1 is correct (Allowance_ Total Amount. Amount) (the concept is >total amount) Do we keep the old name for semantic equivalence to UBL 2.0? >"Monetary Total. Charge Total Amount. Amount" old= 0..1 new= | >plb: UBL 2.1 is correct (Charge_ Total Amount. Amount) (the concept is total >amount) Do we keep the old name for semantic equivalence to UBL 2.0? >"Monetary Total. Tax Exclusive Amount. Amount" old= 0..1 new= | plb: >UBL 2.1 is correct (Tax Exclusive_ Amount. Amount) (but Tax Inclusive should >be updated as well) Do we keep the old name for semantic equivalence to UBL 2.0? >"Order Change. Customer Reference. Text" old= 0..1 new= | >plb: UBL 2.0 is correct (actual both can be correct, but I see no reason why >this has changed) Fine. >"Order Change. Sales Order Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.1 is correct Do we keep the old name for semantic equivalence to UBL 2.0? >"Order Change. Sequence Number. Identifier" old= 0 new= 1 | >plb: none of them are correct: The correct term should be Sequence Number_ >Identifier. Identifier Changing this to the UBL 2.0 name would maintain semantic equivalence to UBL 2.0. >"Order Change. Sequence_ Number. Identifier" old= 1 new= | >plb: same item Do we keep the old name for semantic equivalence to UBL 2.0? >"Order Reference. Sales Order Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.1 is correct Do we keep the old name for semantic equivalence to UBL 2.0? >"Order Response. Customer Reference. Text" old= 0..1 new= | >plb: UBL 2.0 is correct Fine. >"Order Response. Sales Order Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.1 is correct Do we keep the old name for semantic equivalence to UBL 2.0? >"Order. Customer Reference. Text" old= 0..1 new= | >plb: UBL 2.0 is correct Fine. >"Order. Sales Order Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.1 is correct Do we keep the old name for semantic equivalence to UBL 2.0? >"Package. Goods Item" old= 0..n new= | >plb: Error in 2.1 qualification "Contained" should be removed Fine. >"Packing List. Version Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.0 is correct Fine. >"Receipt Line. Oversupply Quantity. Quantity" old= 0..1 new= | >plb: UBL 2.1 is correct (Oversupply is a qualifier just like "short" in >Short_ Quantity) Do we keep the old name for semantic equivalence to UBL 2.0? >"Signature. Validator Identifier. Identifier" old= 0..1 new= | >plb: UBL 2.0 is correct Fine. >"Status. Sequence. Identifier" old= 0..1 new= | >plb: UBL 2.1 is correct. (OPS: Status in 2.0 has a ASBIE called "text") Do we keep the old name for semantic equivalence to UBL 2.0? I'm not sure what more you are trying to say about the ASBIE. >None of this will affect the names in the schema Granted, but in our correspondence with UN/CEFACT and in the publishing of the normative definitions, the Dictionary Entry Name has been the unique key across all of UBL. Using the correct DEN for new items is, of course, appropriate. Above where you say the DEN name was incorrect in UBL 2.0 and is correct in UBL 2.1, I'm of the opinion we keep the incorrect UBL 2.0 DEN for legacy purposes and consistency of definitions between UBL 2.0 and UBL 2.1. This will become important when I (eventually!) get around to creating the public subject identifiers (PSIs) for UBL. The semantics of the constructs in UBL 2.0 are, supposedly, unchanged in UBL 2.1, because of backwards compatibility. The schemas are normative. The definitions are normative. The DEN is the unambiguous key to the definitions. I think this gives the UBL 2.0 dictionary entry names privileged status. At today's teleconference let's decide if we keep the DEN unchanged from UBL 2.0 in UBL 2.1 even if it was wrong in UBL 2.0. I think we should accept that we made the mistake then and keep living with it, making sure in UBL 2.x any new constructs are carefully crafted. And perhaps we should annotate the models in column "U - Analyst Notes" that we are accepting the incorrect name for backward compatibility. Two alternatives are we start building our semantic libraries (such as the PSI project) only on UBL 2.1 and not on UBL 2.0 ... or we have two names in the semantic libraries for the same concept: the incorrect UBL 2.0 name and the correct UBL 2.x name. And do we update our submissions to UN/CEFACT with the repaired names? I suppose I can live with any of the three decisions, but I want the committee to understand the nuances between the three. We've been focused on schemas, but I see a growing reliance in the dictionary entry names. Arianna, once this decision is made, do you need more information to complete the changes above? . . . . . . . . . . . Ken -- XSLT/XQuery training: after http://XMLPrague.cz 2011-03-28/04-01 Vote for your XML training: http://www.CraneSoftwrights.com/o/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 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]