OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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



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