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] CurrencyCodeContentType and CurrencyCodeType issues


Good morning, all,

At 2006-07-19 16:44 +0800, Tim McGrath wrote:
>i think we should also have a listSchemeURI of 
>"urn:un:unece:uncefact:codelist:specification:54217:2001" 
>for currency code in the QualifiedDataTypes 
>schema. this is what we now have in the 
>spreadsheets.  so please note, i have updated 
>the QDT schema in the latest build.

Great ... that is reflected in the massaged XSD files.

>also, why do the QualifiedDataTypes for code lists have:
><xsd:attribute name="listURI" type="xsd:anyURI" use="optional">
>- when the spreadsheets say the values for 
>ListURI should be the genericode files, e.g.: 
>"../codelist/gc/CurrencyCodeType.gc" ?

It looks like you are not working from the latest 
spreadsheets, Tim ... Alan made some last-minute 
changes that included this.  The relative 
addresses were removed from the attributes 
because to an application accessing an instance, 
the relative addresses would be relative to the 
instance, not the model, and we have no idea 
where the user's instance is, as I posited in:

   http://lists.oasis-open.org/archives/ubl/200607/msg00073.html

>if this is in error we need to update those as well.

I've done an analysis of the sanity1 ODF models 
with the sanity2 ODF models and the only 
differences I see (copied below) are in the qDT 
part of the information model.  I see the 
following differences (with my comments as to which I think is correct):

(1) - the listURI is present in sanity2 and not present in sanity1 (I think
       sanity1 is correct)
(2) - the listSchemeURI has ":schema:xsd:" in sanity2 and ":codelist:gc:"
       in sanity1 (I think sanity1 is correct since the list contents are not
       XSD files; I can be swayed, though, if we want to say the scheme is XSD
       because the structure is declared in XSD, but the values are not in the
       XSD but are in genericode so that is why I think sanity1 is correct)
(3) - the listVersionID for country code has "0.3" in sanity2 and "0,3" in
       sanity1 (I think this sanity2 is correct and this should be "0.3"; I
       note that the XSD has "0.3" and I'm not sure why but the XSD is correct;
       opening the sanity1 model in OpenOffice I see "0.3" yet the XML that
       is exported puts out "0,3", so this must be an ODF localization issue
       because sanity1 was created in Denmark and sanity2 in Australia)
(4) - the listVersionID for currency code has "2001" in sanity2 and "0,3" in
       sanity1 (I think sanity2 is correct based on the Pacific call this week
       and this is part of the massage I'm doing to the schemas)

It is understandable when collaboratively working 
on files to get slightly out of sync.  This is 
something we can clean up ... and based on (3) 
above, I think that either (a) Tim should modify 
his model or (b) change the value in the 
spreadsheet cell from a number type to a string 
type so that the XML export is "0.3" instead of 
"0,3" to reflect what we need.  This is the first 
evidence I've seen of the impact of the 
localization of OpenOffice on data, but I think 
the impact makes sense: the field is numeric, so 
it is saved in the file as a localized numeric 
value ... we should be treating the version ID as 
a string so that it is not changed by localization.  I've not seen this before.

And regarding clean up, I noted this morning that 
the timestamps of the spreadsheets reveal a 
possible mismatch between the ODF versions and 
the XLS versions.  My understanding is that the 
ODF file is the master and the XLS is the slave 
copy, such that the timestamp of the XLS should 
always follow the timestamp of the ODF thus 
revealing that it should be up-to-date as in:

2006-07-19  17:08            21,662 UBL-qDT-2.0.ods
2006-07-19  17:15           109,056 UBL-qDT-2.0.xls

But I note that the ODF follows the XLS in this example:

2006-07-14  19:18           169,197 UBL-CommonLibrary-2.0.ods
2006-07-14  17:46           860,672 UBL-CommonLibrary-2.0.xls

... and the maindoc models are almost all different by six days:

2006-07-14  19:18            18,839 UBL-ApplicationResponse-2.0.ods
2006-07-08  14:16            42,496 UBL-ApplicationResponse-2.0.xls
2006-07-14  19:18            19,181 UBL-AttachedDocument-2.0.ods
2006-07-08  13:53            86,528 UBL-AttachedDocument-2.0.xls

... and a date order sort of the listing of 
maindoc files reveals that all XLS files predate 
all ODF files.  But I do not have time to check 
this this morning because I have to work on 
defaultCodeList.xsl and the analysis above took 
more time than I planned ... perhaps someone else can check these.

Thanks!

. . . . . . . . . . . . . Ken

T:\>diff sanity1\CraneUBLModelReport.xml sanity2\CraneUBLModelReport.xml
13848a13849
 >       <Values>../codelist/gc/AllowanceChargeCodeType.gc</Values>
13859c13860
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:AllowanceChargeReasonCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:AllowanceChargeReasonCode-2.0</Values>
13963a13965
 >       <Values>../codelist/gc/ChannelCodeType.gc</Values>
13974c13976
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:ChannelCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:ChannelCode-2.0</Values>
14075a14078
 >       <Values>../codelist/gc/ChipCodeType.gc</Values>
14086c14089
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:ChipCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:ChipCode-2.0</Values>
14159c14162
<       <Values>0,3</Values>
---
 >       <Values>0.3</Values>
14189a14193
 >       <Values>../codelist/gc/CountryIdentificationCodeType.gc</Values>
14200c14204
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:CountryIdentificationCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-2.0</Values>
14273c14277
<       <Values>0,3</Values>
---
 >       <Values>2001</Values>
14303a14308
 >       <Values>../codelist/gc/CurrencyCodeType.gc</Values>
14314c14319
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:CurrencyCode-2.0</Values>
---
 > 
<Values>urn:un:unece:uncefact:codelist:specification:54217:2001</Values>
14415a14421
 >       <Values>../codelist/gc/DocumentStatusCodeType.gc</Values>
14426c14432
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:DocumentStatusCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:DocumentStatusCode-2.0</Values>
14527a14534
 >       <Values>../codelist/gc/LatitudeDirectionCodeType.gc</Values>
14538c14545
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:LatitudeDirectionCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:LatitudeDirectionCode-2.0</Values>
14639a14647
 >       <Values>../codelist/gc/LineStatusCodeType.gc</Values>
14650c14658
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:LineStatusCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:LineStatusCode-2.0</Values>
14751a14760
 >       <Values>../codelist/gc/LongitudeDirectionCodeType.gc</Values>
14762c14771
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:LongitudeDirectionCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:LongitudeDirectionCode-2.0</Values>
14863a14873
 >       <Values>../codelist/gc/OperatorCodeType.gc</Values>
14874c14884
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:OperatorCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:OperatorCode-2.0</Values>
14978a14989
 >       <Values>../codelist/gc/PaymentMeansType.gc</Values>
14989c15000
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:PaymentMeansCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:PaymentMeansCode-2.0</Values>
15090a15102
 >       <Values>../codelist/gc/SubstitutionStatusCodeType.gc</Values>
15101c15113
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:SubstitutionStatusCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:SubstitutionStatusCode-2.0</Values>
15202a15215
 >       <Values>../codelist/gc/PortCodeType.gc</Values>
15213c15226
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:PortCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:PortCode-2.0</Values>
15314a15328
 >       <Values>../codelist/gc/PackagingTypeCodeType.gc</Values>
15325c15339
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:PackagingTypeCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:PackagingTypeCode-2.0</Values>
15426a15441
 >       <Values>../codelist/gc/TransportationStatusCodeType.gc</Values>
15437c15452
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:TransportationStatusCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:TransportationStatusCode-2.0</Values>
15538a15554
 >       <Values>../codelist/gc/TransportModeCodeType.gc</Values>
15549c15565
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:TransportModeCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:TransportModeCode-2.0</Values>
15650a15667
 >       <Values>../codelist/gc/UnitOfMeasureCodeType.gc</Values>
15661c15678
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:UnitOfMeasureCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:UnitOfMeasureCode-2.0</Values>
15762a15780
 > 
<Values>../codelist/gc/ContainerSizeTypeCodeType.gc 
[Note: this is not available for public distribution]</Values>
15773c15791
< 
<Values>urn:oasis:names:specification:ubl:codelist:gc:ContainerSizeTypeCode-2.0</Values>
---
 > 
<Values>urn:oasis:names:specification:ubl:schema:xsd:ContainerSizeTypeCode-2.0</Values>


--
Registration open for UBL training:    Montréal, Canada 2006-08-07
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
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]