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


Hi Ken,

I am going to wait for your decision; then I think that information you provided me should be enough to complete the required changes ... otherwise I will ask you for helping :-)

Hoping to help you in deciding, I would like to remember  you as follows:

a lot of changes from UBL 2.0 from UBL 2.1 reported below should be due to inconsisten naming components problems; for example:

all xxx. Sales Order Identifier. Identifier are  old= 0..1 new=   

because we decided to allign them to the UBL 2.0 Line Item. Sales_ Order Identifier. Idetifier

(see mail from Tim http://lists.oasis-open.org/archives/ubl/201005/msg00018.html)


Best regards

Arianna

Il 14/07/2010 17:07, G. Ken Holman ha scritto:
7.0.1.0.2.20100714104358.02244600@wheresmymailserver.com" type="cite">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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/3003 - Release Date: 07/13/10 20:36:00



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]