Change requests for the next 1.0 schema generation

MHonArc v2.5.0b2 -->
















ubl message






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

--

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








Subject: Change requests for the next 1.0 schema generation




From: "Stephen Green" <>
To: <>
Date: Wed, 17 Mar 2004 20:41:52 -0000









Here is a list of the change requests just sent to 
David at Gefeg for the next iteration of
UBL 1.0 Schema generation
 
 
 

Changes Requested
 
(1)  The Codelist Schema 
Modules should be treated as being Specialised DataType 
Schema Modules. They are to remain as separate 
Codelist Schema Modules but
the existing Specialised DataTypes Schema 
Module will no longer be used to reference
the Codelist Schema Modules. Instead it will be 
almost empty (similar to how it was in beta
as 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 
will
need 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 CodeList
e.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 module 
called the Specialised DataType Schema Module (of 
which in future there could be many incidentally) is almost empty in UBL 1.0, 
the reference 
to 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 the
spreadsheets.
 
(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 the
udt: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 
associated
with 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 example
an undefined prefix is hinted at but I think we 
have yet to see how things turn out with the issues around
the use of the Core Components Parameters Schema 
Module - whether an element defined there might
be 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:DateType
and the udt:DateType should be based on the 
xsd:date (a secondary representation term interpreting a udt:Date as an xsd:date 
just as
UBL 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 to
the 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 model
issue though.












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

--

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