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