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
Hi Ken,
In the case of the currency code we just need to provide the two
degrees of flexibility since the only places currency values are
used at present are in elements (CurrencyCodeType) and in the
single amountCurrencyID attribute of an Amount. The latter is the
reason we have CurrencyCodeContentType, as we can use the
codelist with an attribute, or so I understood from the codelist
strategy.
I don't think we have yet come across an occassion where the two
types, the CodeType for elements and the CodeContentType for
attributes hasn't been sufficient. I believe it covers all possibilities for
Supplementary Component attributes.
So in general I suggest we just cater for the two degrees of flexibility.
All the best
Steve
On 10/02/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> 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]