RE: [ubl-dev] Re: About CodeList for UnitCode

["Sylvia Webb" <swebb@gefeg.com>]

Hello All,

This is an error and not conformant to UN/CEFACT ATG2 Naming and Design
Rules for unqualified data types which UBL has adopted. I believe it falls
into the category of codelist errors identified in the UBL TC meetings
before the package was released, and the UBL 2.0 front matter comments of
known issues. 

There are several known codelist issues that should be corrected for the
next publication of UBL 2.0 for public review.


Regards,
Sylvia

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Sunday, March 19, 2006 8:54 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Re: About CodeList for UnitCode

Good morning, all ... I apologize that it took so long for me to pick up on
this post, but I was teaching all last week and am only now catching up.
Work is (thankfully) back in full swing for me, a month ahead of schedule,
but that impacts on the plans I had for my volunteer work.

At 2006-03-19 00:05 -0800, jon.bosak@sun.com wrote:
>In UBL 2.0, we are using a new methodology for code lists in which all 
>the code list value checking takes place in a second validation pass 
>using schematron (ISO/IEC 19757-3 Document Schema Definition Languages 
>(DSDL) -- Part 3: Rule-Based Validation -- Schematron).  This approach 
>allows much greater flexibility in specifying, extending, and 
>subsetting code lists.  For details, see the proposal at
>
>    http://lists.oasis-open.org/archives/ubl/200602/msg00062.html

Unfortunately, Jon, I believe this will not help Véronique in her specific
situation.

At 2006-03-13 15:24 +0100, Véronique Testa wrote:
>UBL 2.0 : Quantity (InvoicedQuantity,
>BaseQuantity...) is associated to the only one attribute "UnitCode".

Indeed that is true:

       <xsd:simpleContent>
          <xsd:extension base="xsd:decimal">
             <xsd:attribute name="unitCode"
                  type="clm66411:UnitCodeContentType" use="optional">


>UnitCode allowed are issued from the codelist defined by UN/CEFACT Rec 
>20. This specification provides a good way to identify the information 
>in multiple business situations but still for EDI traditional partner 
>inheritance, we need to keep and transmit other codes.
>
>Take for example:EDI Invoic D96a received with the following :
>QTY+47:2050:PCE
>QTY+52:6:PCE
>...
>PRI+AAB:1.518:::1:PCE
>PRI+AAA:1.548:::1:PCE
>
>In this exemple, the Unit is PCE  which is unknown in 
>"CodeList_UnitCode_UNECE_7_04.xsd" . Expected or oversight ???

I do not know how it was decided to use CodeList_UnitCode_UNECE_7_04.xsd
rather than another set ... and I hope another committee can comment on the
choice itself, but there are ramifications of that choice to Véronique's
situation that I want to follow up on.

>The syntax in UBL 1.0 output file (ie
>QTY+47:2050:PCE)  is  : <cbc:InvoicedQuantity
>quantityUnitCode="PCE">2050</cbc:InvoicedQuantity>
>This syntax is not valid in UBL 2.0.

Correct.

>To keep the compatibility I thought we will be able to use : 
><cbc:InvoicedQuantity unitCode="ZZ">2050</cbc:InvoicedQuantity> but 
>where could we note that mutually code is PCE ???

That is a good choice, because I note in CodeList_UnitCode_UNECE_7_04.xsd
that the value "ZZ" is for "mutually defined".

So Véronique's question is very important:  where do we express a private
code that is not in CodeList_UnitCode_UNECE_7_04.xsd while we are using "ZZ"
to specify that a private code is being used.

I think the committee should consider including an optional privateCode=
attribute for QuantityType whose semantic would be the code value outside of
the adopted list.

The problem with the proposed code list value validation methodology is that
for the three data types defined by the CCTS code sets, the methodology only
supports *restriction* of those coded values.  The mandatory first pass that
does structural validation imposes the limitation of no extensions to the
data types defined by the CCTS enumerations, while it does not impose any
limitation on all of the remaining coded data types.  Trading partners are
open to specify any value they wish for those data types not defined by
enumerations, but Véronique needs to extend the value set for a data type
which is defined by an enumeration, thus it is not possible.

An alternative approach to Véronique's problem is that she and a trading
partner could agree on a private extension to UBL, a customization that
could be achieved by the method we are debating regarding the use of NVDL:

   http://lists.oasis-open.org/archives/ubl/200602/msg00117.html

Then she could have something like:

   <cbc:InvoicedQuantity unitCode="ZZ"
                         vt:value="PCE">2050</cbc:InvoicedQuantity>

But then all trading partners would end up coming up with their own ways of
customizing the model and we would have multiple approaches to a common
issue.

I think Véronique's situation is evidence that the committee should consider
providing a standardized way that users would supply private codes when
using a unitCode value of "ZZ", as in:

   <cbc:InvoicedQuantity unitCode="ZZ"
                      privateCode="PCE">2050</cbc:InvoicedQuantity>

I will add this to the issues list through the comment form.

. . . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-06-12/16
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/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the archives, you must subscribe before
posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/