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