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