[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Understanding code list declarations
Dear NDR Team, Please confirm that it was agreed in Manhattan that UBL will not use ATG2 NDR for the uDT schema module. If this is correct, please point us to the UBL NDR which: 1) Permit enumerations in uDT's 2) Permit restrictions of uDT's without qDT's for codelists and identifier lists. 3) Support for restricting CCTS data types as described in these email messages below and Tim's email (http://lists.oasis-open.org/archives/ubl/200602/msg00036.html). 4) Fully describe what rules are used and when, to determine when a uDT can have enums, when a qDT should be created, how uDT's should be restricted, when a qDT should be used to restrict a uDT. As I mentioned in Manhattan, FX currently uses ATG2 NDR for the uDT schema module. The current technical approach for these use cases described below are in violation of ATG2 NDR therefore, we need clear and specific UBL rules to do the proper programming for these use cases. Regards, Sylvia -----Original Message----- From: Stephen Green [mailto:stephengreenubl@gmail.com] Sent: Sunday, February 12, 2006 6:37 AM To: Universal Business Language 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 > > > > > > > > > --------------------------------------------------------------------- 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]