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