[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Outcomes of joint SC call 2004.03.30
Attendance: Jon Bosak Tony Coates Bill Meadows Anne Hendry Stephen Green David Kruppke Tim McGrath Marion Royal Lisa Seaburg Item 1 Schedule for this week Agreed: * Tuesday/Wednesday - agree and document change requests for GEFEG * Submit one official set of final changes to GEFEG * Formalize and schedule QA and sign off from GEFEG Item 2.1 Correctly defining re-usable BBIE Properties (Mike Grimley) Resolution: AI: Mike G.: Clarify rule for how the name of each complex type used for BBIE properties should be formed; David needs a rule, not just an example AI: NDRSC: Include rule in NDRs AI: David: Implement the change Reference: Message from Mike dated 26 March: "Draft 10.1 Schema Review - CBC Schema"; copy appended below Item 2.2 Agreed implementation of Code List Representation schema (Marty Burns/Stephen Green) Discussion: This is required for compliance with the CLSC design and involves some important functionality (the ability to validate CL attribute values). Resolution: Apply the changes per emails from Stephen and Tony. This will require more changes to the model and will require 2-3 days to implement. AI: Tim: Create an SDT model for UBL_Amount. Type AI: David: Implement the changes in Stephen's message of 27 March Reference: Message from Stephen dated 27 March: "Schema Changes Required for further, requested compliance with the CLSC Design"; copy appended below Item 2.3 Core Component Parameters: maxOccurs for Instance elements (Stephen Green) AI: Tim: In model draft 11, explicitly state maxOccurrs wherever it is not stated in CCP schema module AI: Tim: Change "contextualization" to "contextualisation" Other notes - We meet again tomorrow to receive AI's and clarify remaining questions. - Tomorrow's meeting will start an hour earlier than previously scheduled -- 7 a.m. San Francisco time instead of 8. - We think that these changes will have no effect on instances, so Ken should be able to start work using Stephen's instance examples for joinery and office together with the draft 10 schemas; Jean will still have to finish the UN specifications. We will visit this again tomorrow to confirm. ================================================================== Date: Fri, 26 Mar 2004 15:41:55 -0500 From: Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> To: "UBL List (E-mail)" <ubl@lists.oasis-open.org> Subject: Draft 10.1 Schema Review - CBC Schema Greetings, It looks to me as if the CBC schema has not changed much (if any). We still have: <xsd:element name="StreetName" type="udt:NameType"/> <xsd:element name="AdditionalStreetName" type="udt:NameType"/> We should have: <xsd:complexType name="StreetNameType"> <xsd:simpleContent> <xsd:extension base="udt:NameType"></xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:element name="StreetName" type="StreetNameType"/> In the CAC Schema (or wherever), we should see declarations such as: <xsd:element ref="cbc:StreetName"/> <xsd:element name="AdditionalStreetName" type="cbc:StreetNameType"/> Reference from NDR (wd-ublndrsc-ndrdoc-V1pt0Draftp.doc): [Line 1848]: BBIE properties are represented with complex types. [CTD3] Every ccts:BBIEProperty xsd:complexType definition content model MUST use the xsd:simpleContent element. [CTD4] Every ccts:BBIEProperty ComplexType content model xsd:simpleContent element MUST consist of an xsd:extension element. [CTD5] Every ccts:BBIEProperty xsd:complexType content model xsd:base attribute value MUST be the ccts:CCT of the unspecialised or specialised UBL datatype as appropriate. ----- Thank You, Mike Grimley ================================================================== Date: Sat, 27 Mar 2004 21:55:46 -0000 From: "Stephen Green" <stephen_green@seventhproject.co.uk> Subject: [ubl] Schema Changes Required for further, requested compliance with the CLSC Design To: ubl@lists.oasis-open.org Schema Changes Required for further, requested compliance with the CLSC Design In draft 10-1 the Codelist Codelist Schema Module starts with the complexType: <xsd:complexType name="CodeType"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>DT</ccts:ComponentType> <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName> <ccts:RepresentationTerm>Code</ccts:RepresentationTerm> ... <ccts:CodeListUniformResourceID>http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc</ccts:CodeListUniformResourceID> <ccts:CodeListSchemeUniformResourceID>urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1</ccts:CodeListSchemeUniformResourceID> <ccts:LanguageID>en</ccts:LanguageID> </ccts:Instance> </xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:restriction base="udt:CodeType"> <xsd:enumeration value="AED"> <xsd:annotation> <xsd:documentation> <CodeName>Dirham</CodeName> </xsd:documentation> </xsd:annotation> </xsd:enumeration> ... <xsd:enumeration value="ZWD"> <xsd:annotation> <xsd:documentation> <CodeName>Zimbabwe 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" fixed="ISO 4217 Alpha"/> <xsd:attribute name="codeListAgencyID" type="xsd:normalizedString" use="optional" fixed="6"/> <xsd:attribute name="codeListAgencyName" type="xsd:string" use="optional" fixed="United Nations Economic Commission for Europe"/> <xsd:attribute name="codeListName" type="xsd:string" use="optional" fixed="Currency"/> <xsd:attribute name="codeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/> <xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional" fixed="http://www.bsi-global.com/Technical%2BInformation/Publications/_Publications/tig90x.doc"/> <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" use="optional" fixed="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1"/> <xsd:attribute name="languageID" type="xsd:language" use="optional" fixed="en"/> </xsd:restriction> </xsd:simpleContent> </xsd:complexType> where the complexType includes, following the 'Component' and 'Instance' annotation/documentation, the enumeration and the Supplementary Components. A. The Codelist SC has proposed the following changes: 1. The complexType above should become a complexType with just the 'Component' and 'Instance' annotation/documentation and by necessity (my addition) the Supplementary Components: <xsd:complexType name="CodeType"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>DT</ccts:ComponentType> <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName> ... </ccts:Component> <ccts:Instance> <ccts:CodeListID>ISO 4217 Alpha</ccts:CodeListID> <ccts:CodeListAgencyID>6</ccts:CodeListAgencyID> ... </ccts:Instance> </xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:extension base="CurrencyCodeContentType"> <xsd:attribute name="name" type="xsd:string" use="optional"/> ... (Supplementary Components with fixed values) <xsd:attribute name="codeListSchemeURI" type="xsd:anyURI" fixed="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" use="optional"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> 2. A new simple type is created too which holds the enumerations and is based on xsd:normalizedString: <xsd:simpleType name="CurrencyCodeContentType"> <xsd:restriction base="xsd:normalizedString"> <xsd:enumeration value="AED"> <xsd:annotation> <xsd:documentation> <CodeName>Dirham</CodeName> </xsd:documentation> </xsd:annotation> </xsd:enumeration> ... </xsd:restriction> </xsd:simpleType> 3. At the end of the Schema is added <xsd:attribute name="CurrencyCode" type="CurrencyCodeContentType"/> This allows us to use the Currency Codelist Schema Module to provide XSD validation to, for example, the 'amountCurrencyID' in the Amount Type of the UDT *but to do so restricts the allowed values in the udt:AmountType* so it has to now be a Specialised DataType, such as sdt:AmountType. B. The Specialised DataType Schema Module could then have: <xsd:restriction base="udt:AmountType"> <xsd:attribute name="amountCurrencyID" type="cur:CurrencyCodeContentType" use="required"/> and its amountCurrencyCodeListVersionID could be fixed as is a codelist schema's Supplementary Components ... <xsd:attribute name="amountCurrencyCodeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/> </xsd:restriction> There would also, of course, be the need for the cur: namespace declaration and all references to udt:AmountType could be changed to sdt:AmountType in Document Schema Modules and Common Basic Components Schema Modules. But, since the Codelist Schema Module type has to be a simpleType to allow validation of attributes which are codes (such as Supplementary Components as we have in AmountType), the udt:CodeType cannot be the base. The simpleType still has to be based on 'xsd:normalizedString' and the complexType which holds the Supplementary Components is no longer based on the udtCodeType but has no base type (the link to the udt:CodeType being conceptual). 1. So a new Specialised DataType Schema Module which allowed the newly-to-be-introduced validation of the Amount currency code Supplementary Component attribute could look like this: <xsd:schema targetNamespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1" xmlns:udt="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" xmlns:ccts="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-10.1" xmlns:cct="urn:oasis:names:tc:ubl:CoreComponentTypes:1:0-draft-10.1" xmlns:cur="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1:0-draft-10.1"> <xsd:import namespace="urn:oasis:names:tc:ubl:UnspecialisedDatatypes:1:0-draft-10.1" schemaLocation="UBL-UnspecialisedDatatypes-1.0-draft-10.1.xsd"/> <xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentParameters:1:0-draft-10.1" schemaLocation="UBL-CoreComponentParameters-1.0-draft-10.1.xsd"/> <xsd:import namespace="urn:oasis:names:tc:ubl:CoreComponentTypes:1:0-draft-10.1" schemaLocation="UBL-CoreComponentTypes-1.0-draft-10.1.xsd"/> <xsd:import namespace="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-10.1" schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0-draft-10.1.xsd"/> <xsd:complexType name="AmountType"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>DT</ccts:ComponentType> <ccts:DictionaryEntryName>Amount. Type</ccts:DictionaryEntryName> <ccts:Definition>A number of monetary units specified in a currency where the unit of the currency is explicit or implied.</ccts:Definition> <ccts:RepresentationTerm>Amount</ccts:RepresentationTerm> </ccts:Component> </xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:restriction base="udt:AmountType"> <xsd:attribute name="amountCurrencyID" type="cur:CurrencyCodeContentType" use="required"/> <xsd:attribute name="amountCurrencyCodeListVersionID" type="xsd:normalizedString" use="optional" fixed="0.3"/> </xsd:restriction> </xsd:simpleContent> </xsd:complexType> </xsd:schema> 2. The Common Basic Components Schema Module would have to include the SDT namespace, e.g. xmlns:sdt="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1" and the SDT import, e.g.: <xsd:import namespace="urn:oasis:names:tc:ubl:SpecialisedDatatypes:1:0-draft-10.1" schemaLocation="../common/UBL-SpecialisedDatatypes-1.0-draft-10.1.xsd"/> and the use of the sdt:AmountType instead of the udt:AmountType e.g. <xsd:element name="Amount" type="sdt:AmountType"/> and <xsd:element name="LineExtensionTotalAmount" type="sdt:AmountType"/> etc. This would mean that an instance could now have validation of its Amount amountCurrencyID Supplementary Component e.g. <cbc:Amount amountCurrencyID="AED" amountCurrencyCodeListVersionID="0.3">3.14</cbc:Amount> but note that the Amount's CCTS Supplementary Components do not include those found in a cct:Code so as to allow all the details of the currency codelist to be stated and possibly fixed Discussion points: 1. Is the above acceptable or does it introduce the possibility of any serious problems for implementers and users, etc? 2. Can / should the other Supplementary Components such as those found in a Code DataType be added to the sdt:AmountType in the SDT Schema Module e.g. by extension so as to allow these too to be stated and fixed? 3. Does this matter warrant delaying these CLSC changes too till 1.1 so as to resolve this issue if time does not permit now? __________________________________________________________________________________________________________________ Stephen Green
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]