[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 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]