← Prev in month ← Prev in thread
Next in thread → Next in month →

Schema Changes Required for further, requested compliance with the CLSC Design

From
Stephen Green
Date
2004-03-27T21:41:00+00:00
ID
Thread
Schema Changes Required for further, requested compliance with the CLSC Design
MHonArc v2.5.0b2 -->
















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Schema Changes Required for further, requested compliance with the CLSC Design




From: "Stephen Green" <>
To: <>
Date: Sat, 27 Mar 2004 21:55:46 -0000









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]
← Prev in month ← Prev in thread
Next in thread → Next in month →