[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Change requests for the next 1.0 schema generation
Issue 12: 'format' supplementary components not in cct schema module (MikeG) Resolution: These should be added to the CCT schema for Numeric, Indicator and DateTime (as per models). this is CCTS requirement. we just encourgae implementations not to use them. David to fix.if this does not align with your understanding, then can you re-state it better. we wanted to say what you understood.
Greetings,As mentioned in a previous email, and not included below, the latest CCT schema still has 'DateTime', 'Indicator' and 'Numeric' types defined as simple types (with a *Restriction* on the built in type).I believe we had agreed in Washington that they would be redefined to conform to the CCTS. That is, the required supplementary component 'Format' would be added to the definition of each.
I wasn't able to make yesterday's meeting (until the end, anyway) and Jon has made it very clear that that is where the decisions are made; however, this involves CCTS conformance and, if I am not mistaken, the decision was made in joint session with Tim and Steve on the phone, so there was good representation of all concerned SCs.
Thank You,
Mike Grimley
-----Original Message-----
From: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
Sent: Wednesday, 17 March 2004 15 42
To: ubl@lists.oasis-open.org
Subject: [ubl] Change requests for the next 1.0 schema generation
Here is a list of the change requests just sent to David at Gefeg for the next iteration ofUBL 1.0 Schema generationChanges Requested(1) The Codelist Schema Modules should be treated as being Specialised DataTypeSchema Modules. They are to remain as separate Codelist Schema Modules butthe existing Specialised DataTypes Schema Module will no longer be used to referencethe Codelist Schema Modules. Instead it will be almost empty (similar to how it was in betaas the 'DataTypes Schema Module'). I would predict it looking like this (if it is generated for draft 8):<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1:0-draft-8.4">
<xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/>
</xsd:schema>
[with the usual UBL Header comment block too]or, if Tim releases his draft 9 very soon, like this:<xsd:schema targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1" xmlns="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-9.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1:0-draft-9.1">
<xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-9.1" schemaLocation="UBL-CoreComponentParameters-1.0-draft-9.1.xsd"/>
</xsd:schema>[In the following examples I'll just keep to the draft-8.4 scenario.](2) This Specialised DataTypes Schema Module will only need to be imported into the Common Basic Components Schema Modules.This is because the Code and Identifier BBIEs are the only ones declared outside of the CBC Schema and of these two types the only relevant one is likely to be code which has its specialised datatypes defined in the separate codelist schema modules (a special type of SDT Schema) and not now in the 'Specialised DataTypes Schema Module'.
(3) The 'use' subfolder within the 'codelist' folder is to be dropped and all the codelists schema modules just placed in the 'codelist' folder(4) With the change in the non-codelist SDT Schema Module in (1) above, the other Schema Modules willneed to reference the Codelist Schema Modules directly, i.e.:targetNamespace="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4" xmlns:res="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4"...xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4" xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-8.4" xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4" xmlns:cbc="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" xmlns="urn:oasis:names:tc:ubl:CommonAggregateComponents:1:0-draft-8.4" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1:0-draft-8.4"<xsd:import namespace="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-8.4" schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0-draft-8.4.xsd"/>
...<xsd:import namespace="urn:oasis:names:tc:ubl:codelist:AcknowledgementResponseCode:1:0-draft-8.4" schemaLocation="../codelist/UBL-CodeList-AcknowledgementResponseCode-1.0-draft-8.4.xsd"/>
<xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-8.4" schemaLocation="UBL-CoreComponentParameters-1.0-draft-8.4.xsd"/>
<xsd:import namespace="urn:oasis:names:tc:ubl:CommonBasicComponents:1:0-draft-8.4" schemaLocation="UBL-CommonBasicComponents-1.0-draft-8.4.xsd"/>
<xsd:import namespace="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-8.4" schemaLocation="UBL-UnspecialisedDatatypes-1.0-draft-8.4.xsd"/>(5) The mention of DerivedCodeType is to change to xxxxxCodeType where xxxxx is the Property Term of the CodeListe.g. cur:DerivedCodeType becomes cur:CurrencyCodeType(in future, external groups might be defining their own names for these codelist schema modules but we will stick to using the property from the SDT model)(6) Note that since the Codelist Schema Modules are now considered to be a kind of Specialised DataType Schema Module and that the modulecalled the Specialised DataType Schema Module (of which in future there could be many incidentally) is almost empty in UBL 1.0, the referenceto the type of a code having a codelist schema module from within the CommonAggregateComponents Schema Module or, where required,a Document Schema Module will look not like sdt:DerivedCodeType or sdt:CurrencyCodeType but for the example of the currency code like this:<xsd:element name="CurrencyCode" type="cur:CurrencyCodeType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
...(7) Not, I think, a change request but more a note: In beta, the credits for codelist schemas defined in the codelist spreadsheet (now the SDT spreadsheet)were added to the UBL comment header block. Now they won't appear at all in the Schemas (as, I believe they don't anyway) but will just be held in thespreadsheets.(8) Again, not a change request but a note, since you've already started implementing it: The codes will all be based, not on the cct:CodeType but on theudt:CodeType (thanks)(9) The 'names' for codes from the codelists (the second string from the code text file) should appear in some way in annotation/documentation associatedwith the 'value' enumeration in the Codelist Schema Module.e.g.<xsd:element name="CurrencyCode" type="CurrencyCodeType"/>
<xsd:complexType name="CurrencyCodeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Instance>
<ccts:Prefix>cur</ccts:Prefix>
<ccts:CodeListQualifier>ISO 4217</ccts:CodeListQualifier>
<ccts:CodeListAgency>6</ccts:CodeListAgency>
<ccts:CodeListVersion>0.3</ccts:CodeListVersion>
</ccts:Instance>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="udt:CodeType">
<xsd:enumeration value="ADP">...
<xsd:enumeration value="USD"><xsd:annotation>
<xsd:documentation>
<CodeName>United States Dollar</CodeName>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>...
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="codeListID" type="xsd:normalizedString" use="optional"/>
<xsd:attribute name="codeListAgencyID" type="xsd:normalizedString" use="optional"/>
<xsd:attribute name="codeListAgencyName" type="xsd:string" use="optional"/>
<xsd:attribute name="codeListName" type="xsd:string" use="optional"/>
<xsd:attribute name="codeListVersionID" type="xsd:normalizedString" use="optional"/>
<xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="languageID" type="xsd:language" use="optional"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>I'm not sure in this example whether you'd use this same element <CodeName> . In the CLSC examplean undefined prefix is hinted at but I think we have yet to see how things turn out with the issues aroundthe use of the Core Components Parameters Schema Module - whether an element defined there mightbe suitable. For now I'd suggest sticking with <CodeName> without a prefix unless you've a better idea.(10) I was asked to correct my e-mail bug report concerning DateType - I wrote cct:DateType; it should of course read udt:DateTypeand the udt:DateType should be based on the xsd:date (a secondary representation term interpreting a udt:Date as an xsd:date just asUBL has a udt:Time as based on an xsd:time).<xsd:complexType name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date. Type</ccts:DictionaryEntryName>
<ccts:Definition>A particular point in the progression of time together with the relevant supplementary information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>should be<xsd:complexType name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date. Type</ccts:DictionaryEntryName>
<ccts:Definition>A particular point in the progression of time together with the relevant supplementary information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="udt:DateType"/>
</xsd:simpleContent>
</xsd:complexType>So the fixes should then be made to the Unspecialised DataType Schema Module, according to UBL's longstanding NDR-endorsed exception tothe udt based on cct rule, such that<xsd:complexType name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date. Type</ccts:DictionaryEntryName>
<ccts:Definition>A particular point in the progression of time together with the relevant supplementary information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>should become<xsd:complexType name="DateType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Date. Type</ccts:DictionaryEntryName>
<ccts:Definition>A particular point in the progression of time together with the relevant supplementary information.</ccts:Definition>
<ccts:RepresentationTerm>Date</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:date"/>
</xsd:simpleContent>
</xsd:complexType>and<xsd:complexType name="TimeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Time. Type</ccts:DictionaryEntryName>
<ccts:RepresentationTerm>Time</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="cct:DateTimeType"/>
</xsd:simpleContent>
</xsd:complexType>should become<xsd:complexType name="TimeType">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:CategoryCode>DT</ccts:CategoryCode>
<ccts:DictionaryEntryName>Time. Type</ccts:DictionaryEntryName>
<ccts:RepresentationTerm>Time</ccts:RepresentationTerm>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:time"/>
</xsd:simpleContent>
</xsd:complexType>(11) Not sure what the root of this problem was but there should be no more code types like 4461_ Code. Type;all should be replaced with their text equivalents e.g. PaymentMeansCode. Type . I'm not sure if this is a modelissue though.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
-- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]