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: UnitCode and UnitOfMeasureCode, and CurrencyID and CurrencyCode

Hello again,

In my last post I highlighted the code list meta 
data for two qDT code lists (repeated here):


       <LongName xml:lang="en">Currency</LongName>
       <LongName Identifier="listID">ISO 4217 Alpha</LongName>
          <LongName xml:lang="en">United Nations 
Economic Commission for Europe</LongName>


       <LongName xml:lang="en">Unit Of Measure</LongName>
       <LongName Identifier="listID">UN/ECE rec 20</LongName>
       <Version>Revision 4</Version>
          <LongName xml:lang="en">United Nations 
Economic Commission for Europe</LongName>

I understand that I am to validate the 
CurrencyCode enumeration against the following in defaultCodeList.xsl:


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:documentation xml:lang="en">
Currency. Identifier</ccts:DictionaryEntryName>
               <ccts:Definition>The currency of the amount.</ccts:Definition>
               <ccts:ObjectClass>Amount Currency</ccts:ObjectClass>
               <ccts:UsageRule>Reference UNECE 
Rec 9, using 3-letter alphabetic codes.</ccts:UsageRule>
name="currencyCodeListVersionID" type="xsd:normalizedString" use="optional">
            <xsd:documentation xml:lang="en">
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>

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 
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?


. . . . . . . . . . . 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

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