[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Re: [ubl] Minutes of Atlantic UBL TC call 13 May 2009
Ken, This requirement is addressed through the namespace declaration for the currency code list. Each of the 7 code lists used by the UDT schema are updated with each release of the directory. As such, there is no requirement for the supplementary component. So let me make sure I understand this - UBL had deliberately chosen to deviate from the UN/CEFACT code list approach, and as a result, must also deviate from the UN/CEFACT representation of supplementary components. Is that correct? Kind Regards, Mark -----Original Message----- From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sent: Friday, May 15, 2009 10:11 PM To: ubl-dev@lists.oasis-open.org Subject: Re: [ubl-dev] Re: [ubl] Minutes of Atlantic UBL TC call 13 May 2009 At 2009-05-15 19:59 -0400, Crawford, Mark wrote: >As all supplementary components are already addressed, I would like >to see the specific stakeholder requirements that require attributes >vice the current approach. As an example in the current approach you cite, the AmountType data type has been realized in the D08B UnqualifiedDataType_7p0.xsd schema fragment without a schema expression for the supplementary component "UDT000001-SC 3" named "Amount. Currency Code List Version. Identifier" found in row 9 of the CCL08B_17FEB09.xls spreadsheet. Yildiray tells us that this year's ISO currency code list uses "TRY" for Turkish Lira, while in the currency list in play for UBL 2.0 "TRL" is the code for Turkish Lira: http://lists.oasis-open.org/archives/ubl/200904/msg00015.html So in UBL 2.1 we need to be able to support the following to be both backward compatible and current: <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount> <cbc:TaxAmount currencyID="TRY">17.50</cbc:TaxAmount> <cbc:TaxAmount currencyID="TRL" currencyCodeListVersionID="2001">17.50</cbc:TaxAmount> <cbc:TaxAmount currencyID="TRY" currencyCodeListVersionID="2009">17.50</cbc:TaxAmount> While at the same time rejecting the following invalid combination: <cbc:TaxAmount currencyID="TRL" currencyCodeListVersionID="2009">17.50</cbc:TaxAmount> And this cannot be done without the expressed attribute for the cited supplementary component for AmountType. Note that the UnqualifiedDatTypeSchemaModule-2.0.xsd file that was chosen to be used in UBL 2.0 also does not have this modeled supplementary component expressed, so UBL 2.0 users are restricted only to say: <cbc:TaxAmount currencyID="TRL">17.50</cbc:TaxAmount> ... and are not able to say: <cbc:TaxAmount currencyID="TRL" currencyCodeListVersionID="2001">17.50</cbc:TaxAmount> Which is why we are making changes for UBL 2.1 both in schema validation (which, in order to support the four success use cases and one failure use case, cannot cite code lists in schemas) and in second-pass validation (which can support all five use-cases). For items based on Code Type, this would be the equivalent to be both backward compatible and current: <cbc:DocumentCurrencyCode>TRL</cbc:DocumentCurrencyCode> <cbc:DocumentCurrencyCode>TRY</cbc:DocumentCurrencyCode> <cbc:DocumentCurrencyCode listVersionID="2001">TRL</cbc:DocumentCurrencyCode> <cbc:DocumentCurrencyCode listVersionID="2009">TRY</cbc:DocumentCurrencyCode> While at the same time reject the following invalid combination: <cbc:DocumentCurrencyCode listVersionID="2001">TRY</cbc:DocumentCurrencyCode> Note that the unqualified code type does have the required supplementary components for this use case. This means that UBL 2.1 currency values must support two code lists, because "TRL" isn't in the new code list and "TRY" isn't in the old code list. UBL 2.1 has to validate UBL 2.0 instances with "TRL" (to be backward compatible) and validate UBL 2.1 instances with "TRY" (to be current). A simple W3C Schema union of values from two lists won't support the required rejections described above. The proposed UBL 2.1 second-pass validation does meet all the above use cases. Having the supplementary component allows the user not to be ambiguous regarding in which list a specific code is found. Without the supplementary component, one would not be able to distinguish the semantics of two codes of the same value from two different lists. For example, the currency code "RON" for the Romanian leu has had two different semantic meanings in the life of ISO currency codes. While not a problem between 2001 and 2009, it is an example of a real-world use case when established codes are reused for new purposes. We have no idea if codes in code lists used by UBL will be reused in the future. Users can choose to add instance-level meta data to coded values in order to be unambiguous and protect against future uses. I responded to Yildiray with these details regarding how we cannot meet his specific stakeholder requirement with the current UBL 2.0 approach: http://lists.oasis-open.org/archives/ubl/200904/msg00016.html Please let me know if you need any more detail regarding this established user requirement and how the current approach does not meet the need. . . . . . . . . . . . Ken -- XSLT/XQuery/XSL-FO hands-on training - Los Angeles, USA 2009-06-08 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]