UnitCode and UnitOfMeasureCode, and CurrencyID and CurrencyCode

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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