[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] UnitCode and UnitOfMeasureCode, and CurrencyID and CurrencyCode
i agree with your assessment. we once built a data model for unqualified data types that did expose some inconsistencies. i suspect they relate to these data types being grown rather than designed. anyway, as we now use the ATG2 uDT, it is a moot point. your comment about UnitType may be caused by some legacy datatypes in the schema generator. I dont recall anything called Unit. G. Ken Holman wrote: > Hello again, > > In my last post I highlighted the code list meta data for two qDT code > lists (repeated here): > > CurrencyCode: > > <Identification> > <ShortName>CurrencyCode</ShortName> > <LongName xml:lang="en">Currency</LongName> > <LongName Identifier="listID">ISO 4217 Alpha</LongName> > <Version>2001</Version> > > <CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:54217:2001</CanonicalVersionUri> > > > <LocationUri>http://docs.oasis-open.org/ubl/os-ubl-2.0/cl/gc/cefact/CurrencyCode-2.0.gc</LocationUri> > > <Agency> > <LongName xml:lang="en">United Nations Economic Commission > for Europe</LongName> > <Identifier>6</Identifier> > </Agency> > </Identification> > > UnitOfMeasureCode: > > <Identification> > <ShortName>UnitOfMeasureCode</ShortName> > <LongName xml:lang="en">Unit Of Measure</LongName> > <LongName Identifier="listID">UN/ECE rec 20</LongName> > <Version>Revision 4</Version> > > <CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:66411:2001</CanonicalVersionUri> > > > <LocationUri>http://docs.oasis-open.org/ubl/os-ubl-2.0/cl/gc/cefact/UnitOfMeasureCode-2.0.gc</LocationUri> > > <Agency> > <LongName xml:lang="en">United Nations Economic Commission > for Europe</LongName> > <Identifier>6</Identifier> > </Agency> > </Identification> > > I understand that I am to validate the CurrencyCode enumeration > against the following in defaultCodeList.xsl: > > @currencyID > cbc:CurrencyCode > cbc:DocumentCurrencyCode > cbc:PaymentAlternativeCurrencyCode > cbc:PaymentCurrencyCode > cbc:PricingCurrencyCode > cbc:RequestedInvoiceCurrencyCode > cbc:SourceCurrencyCode > cbc:TargetCurrencyCode > cbc:TaxCurrencyCode > > I note that the use of @currencyID has only one piece of meta data, > that being currencyCodeListVersionID, which I can map to the <Version> > element in genericode: > > <xsd:extension base="xsd:decimal"> > <xsd:attribute name="currencyID" type="xsd:normalizedString" > use="optional"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > <ccts:UniqueID>UNDT000001-SC2</ccts:UniqueID> > <ccts:CategoryCode>SC</ccts:CategoryCode> > <ccts:DictionaryEntryName>Amount Currency. > Identifier</ccts:DictionaryEntryName> > <ccts:Definition>The currency of the > amount.</ccts:Definition> > <ccts:ObjectClass>Amount Currency</ccts:ObjectClass> > > <ccts:PropertyTermName>Identification</ccts:PropertyTermName> > > <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> > <ccts:PrimitiveType>string</ccts:PrimitiveType> > <ccts:UsageRule>Reference UNECE Rec 9, using 3-letter > alphabetic codes.</ccts:UsageRule> > </xsd:documentation> > </xsd:annotation> > </xsd:attribute> > <xsd:attribute name="currencyCodeListVersionID" > type="xsd:normalizedString" use="optional"> > <xsd:annotation> > <xsd:documentation xml:lang="en"> > <ccts:UniqueID>UNDT000001-SC3</ccts:UniqueID> > <ccts:CategoryCode>SC</ccts:CategoryCode> > <ccts:DictionaryEntryName>Amount Currency. Code List > Version. Identifier</ccts:DictionaryEntryName> > <ccts:Definition>The VersionID of the UN/ECE Rec9 code > list.</ccts:Definition> > <ccts:ObjectClass>Amount Currency</ccts:ObjectClass> > <ccts:PropertyTermName>Code List > Version</ccts:PropertyTermName> > > <ccts:RepresentationTermName>Identifier</ccts:RepresentationTermName> > <ccts:PrimitiveType>string</ccts:PrimitiveType> > </xsd:documentation> > </xsd:annotation> > </xsd:attribute> > </xsd:extension> > > Regarding units of measure, I note that MeasureType has an @unitCode > with one piece of metadata: @unitCodeListVersionID, which I can get > from <Version>. > > Interestingly (because it is different) QuantityType has an @unitCode > with three pieces of metadata: @unitCodeListID, @unitCodeListAgencyID > and @unitCodeListAgencyName, which I can get from > LongName[@Identifier='listID'], Agency/Identifier, and Agency/LongName > respectively. > > The type for element <cbc:Unit> is "udt:TextType" so that isn't based > on the unit code type ... same for <cbc:OrderableUnit> being based on > "udt:TextType (are these correct?). But this is moot because there is > no spreadsheet row for <cbc:Unit>, so I'm guessing it is created > because of UnitType ... but I don't see any cbc:* elements that are > based on UnitType except <cbc:Unit> ... I understand everyone is very > busy, but why do we even have <cbc:Unit> and UnitType in our schemas > if they aren't referenced or represented in our spreadsheets? > > Am I correct, then, in assessing there are no elements using the > UnitOfMeasure code list? > > So, it would seem that I can algorithmically determine what meta data > to use for elements, but there will be some tests in > defaultCodeList.xsl for non-existent meta data for attributes of some > information items ... but this is innocuous in the methodology since > the first pass schema validation will prevent the non-existent items > from being expressed in the first place. > > I will be checking for four attribute meta data attributes > "@XXXCodeListID", "@XXXCodeListVersionID", "@XXXCodeListAgencyID" and > "@XXXCodeListAgencyName" for each of the two attributes "@currencyID" > and "@unitCode" so you can see there will be some unnecessary > checking. I will see if I can reduce the amount of unnecessary > checking when it comes time to code. > > Tim, do you agree with this assessment? Does anyone else have any > comments? Is there a reason the attributes based on codes do not all > have the same sets of meta data attributes? > > Thanks! > > . . . . . . . . . . . Ken > > p.s. I apologize for these lengthy posts, but I try to write the > specifications before I write the code so that I only write the code > once ... and I'm finding asymmetrical patterns in our data that will > be difficult to code for. > > -- > UBL/XML/XSLT/XSL-FO training: Vårø, Denmark 2006-10-02/06,11-20/24 > UBL International 2006 2006-11-13/17 http://www.ublconference.com > World-wide corporate, govt. & user group UBL, XSL, & XML 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 > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 web: http://www.portcomm.com.au/tmcgrath
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]