MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ubl] Understanding code list declarations
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]