Comments on draft 9.1 schemas

[Tim McGrath <tmcgrath@portcomm.com.au>]

Please find attached my first impressions of the latest schemas.

I am particulary impressed by the code list schemas which are really 
looking  good - thank you once again David and Michael.


-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

Core Component Parameters.
-------------------------
1. We need to add "Version" to the ComponentType.  This can be populated with the Version in the xsd statement(the build number) and should be used for every definition.

Core Component Types.
-----------------------

2. "ccts:CategoryCode" should be "ccts:ComponentType" - these should be as given in the Core Component Parameters schema. (NB. it appears XMLSpy (at least) does not check references inside documentation - which is why we have been getting away with doing anything in there all this time).

Unspecialised Data Types.
-----------------------
3. We should have ccts:DataType in the documentation for each secondary representation term (e.g. Video has a data type of Binary Object. Type). It documents what the "base=" is.

Specialised Data Types.
-----------------------
4. Should have an import statement for UnspecialisedDatatypes to indicate this is where to get data types for any new types from.

Code List Schemas.
------------------
5. General comment: there seems no point in a /codelist directory.  shouldn't these just be in '/common'?  

6. General comment: we want these to be clearly identifiable as specialised data types, so i would also like to re-propose we change the names of the files to indicate this.  For example, "UBL-CodeList-CurrencyCode-1.0-draft-9.1.xsd" could be called "UBL-SpecialisedDataType-CurrencyCode-1.0-draft-9.1.xsd" 
and its urn "xmlns="urn:oasis:names:tc:ubl:codelist:CurrencyCode:1:0-draft-9.1" could be "xmlns="urn:oasis:names:tc:ubl:CurrencyCode:1:0-draft-9.1" or even "xmlns="urn:oasis:names:tc:ubl:sdt:CurrencyCode:1:0-draft-9.1"

7. I want to confirm that the statement...
  <xsd:element name="CurrencyCode" type="CurrencyCodeType">
    <xsd:annotation>
      <xsd:documentation>This element MUST be conveyed as the root element in any instance document based on this Schema expression</xsd:documentation>
    </xsd:annotation>
  </xsd:element>
 - is correct for each code list schema (obviously with the appropriate code list name).
 
Common Basic Components.
------------------------

8.  i suspect we have too many of these.  we only need cbcs for each "BBIE property" (PropertyTerm+Rep.Term) - not a cbc for each qualified BBIEs.  although i am then not sure how we can name any qualified BBIEs.

Common Aggregate Components.
---------------------------

9. We should have a ccts:DataTypeQualifer value for each code type (in the documentation).

10. Minimum and Maximum Temperature do not have a correct ccts:DataType (it says <ccts:DataType>. Type</ccts:DataType>)

Document Schemas in General
---------------------------
11.  There appears to be an inconsistency in layout between the cac schema and the document schemas.  The Common Aggregate Components schema lists elements at the top and document schemas list them at the bottom.  

For example in the Order schema we find this at the end of the schema...
  <xsd:element name="SellerParty" type="cac:SellerPartyType"/>
But in CAC we find the following at the top.
  <xsd:element name="SellerParty" type="SellerPartyType"/>

Which is correct?

12.  I think all document schemas should import the Specialised Data Type schema as well.  they may want to use any new types defined in there.

Order Schema and Order Change Schema.
-------------------------------------

13. Acknowledgement Responde Code not referenced, it says...
<xsd:element name="AcknowledgementResponseCode" type="udt:CodeType" minOccurs="0" maxOccurs="1">
but should say...
<xsd:element name="AcknowledgementResponseCode" type="res:AcknowledgementResponseCodeType" minOccurs="0" maxOccurs="1">