Re: [ubl] Understanding code list declarations

[Stephen Green <stephengreenubl@gmail.com>]

It is worth clarifying that XyzCodeContentType can be 'wrapped' inside
XyzCodeType anyway but both the simple type CodeContentType with
its enumerations and the wrapping of the CodeType with its further
supplementary component code type metadata attributes are
indispensable.

Steve

On 12/02/06, Stephen Green <stephengreenubl@gmail.com> wrote:
> 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
> >
> >
>