[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]