Re: [ubl] Understanding code list declarations

[Tim McGrath <tmcgrath@portcomm.com.au>]

Just so we dont lose track of the real issue.  It is that we use 
Currency Code both as a BBIE and as a secondary component to the Amount 
data type.  I have mentioned this before and had hoped the code list 
discussion would resolve it in New York.

Yes, we have an issue with representing code lists in the spreadsheets 
but I don't think Ken's problem isn't caused by that.

Sylvia Webb wrote:

>Ken,
>
>IMO, the simple type unconstrained CurrencyCodeType is an error due to
>previously reported missing and inconsistent information in the hand crafted
>spreadsheets for code lists that were imported into EDIFIX to create the
>data models, and subsequent CBC schema module.   
>
>I believe there is an action item to correct the hand crafted spreadsheets
>for the next schema generation.  Once the spreadsheets are accurate, EDIFIX
>will create the correct data models and auto generate the correct CBC schema
>module with complex types for all identified CodeTypes with the
>corresponding constraints.
>
>On a slightly different note, we recently changed the name of EDIFIX to
>GEFEG.FX to reflect the added functionality in the product from the original
>product that only included EDI functionality. We will refer to GEFEG.FX as
>just FX in the future.
>
>Regards,
>Sylvia
>
>-----Original Message-----
>From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
>Sent: Friday, February 10, 2006 2:04 PM
>To: Universal Business Language
>Subject: [ubl] Understanding code list declarations
>
>Hi folks!
>
>I'm working on my code list obligations and I'm confused about something
>that I see in the UBL 2 schemas.
>
>I note the following in my analysis:
>
>   <Context item="@cbc:amountCurrencyID" codes="CurrencyCodeContentType"/>
>   <Context item="cac:CurrencyCode" codes="CurrencyCodeType"/>
>   <Context item="in:InvoiceCurrencyCode" codes="CurrencyCodeType"/>
>   <Context item="in:PricingCurrencyCode" codes="CurrencyCodeType"/>
>   <Context item="cac:SourceCurrencyCode" codes="CurrencyCodeType"/>
>   <Context item="cac:TargetCurrencyCode" codes="CurrencyCodeType"/>
>   <Context item="in:TaxCurrencyCode" codes="CurrencyCodeType"/>
>
>What caught my eye was the existence of both "CurrencyCodeContentType"
>(which is constrained to the ISO list) and "CurrencyCodeType" (which is
>unconstrained):
>
>   <xsd:simpleType name="CurrencyCodeContentType">
>     <xsd:restriction base="xsd:token">
>       <xsd:enumeration value="AED">
>         <xsd:annotation ...
>
>   <xsd:complexType name="CurrencyCodeType">
>     ...
>     <xsd:simpleContent>
>       <xsd:extension base="xsd:normalizedString">
>         <xsd:attribute ...
>
>I'm curious why we don't constrain all currency values the same way ... is
>this an oversight in the schemas?
>
>If not, which of the following should I provide to trading partners needing
>code list value validation?
>
>   - only one degree of flexibility (all currencies),
>   - two degrees of flexibility (CurrencyCodeContentType and
>CurrencyCodeType)
>   - seven degrees of flexibility (@cbc:amountCurrencyID, cac:CurrencyCode,
>in:InvoiceCurrencyCode, in:PricingCurrencyCode, cac:SourceCurrencyCode,
>cac:TargetCurrencyCode, and in:TaxCurrencyCode)?
>
>Thanks for your guidance!
>
>. . . . . . . . . . . . Ken
>
>--
>Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
>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/o/
>Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
>Male Cancer Awareness Aug'05  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.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://www.docengineering.com/