OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Understanding code list declarations


A further thought: are there limitations of just the two types (one simple
with the enumerations and the other complex, reusing the simple
for enumerations and adding attributes)? What if the added attributes
in the CodeType themselves required codelists? Would this be
covered with the use of the CodeContentType simple type for the
other attributes? I guess it would. The real limitation seems to be that
the single type for codelists, the XyzCodeContentType, cannot itself
have metadata in CodeType attributes which can be expressed in the
instance; such metadata (like versionID) can only be found in the
schema(s). For some codelists this may be fine but there may be cases
where it causes problems. So far we've not had too much problem though.
Ity does show a weakness in the code type that it can only have metadata
associated with it in an instance, where the metadata can be flexible, if
the codelist is for an element and * not * where the codelists relates to
an attribute which is itself metadata.



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]