Second run in producing draft7 schemas

["Michael Dill" <dill2@gefeg.com>]

Dear all,
in order to have a good second run in producing schemas and to call them V1
draft7, we have the following
questions and remarks:
---------------------

1. annotation for codes
The sent schemas do not yet have annotation/documentation for name and/or
description. We would prefer to get an example. Does Stephen has one?

2. Unique Identifier
Please be aware that the spreadsheets do not have a unique identifier as
requested by NDR [DOC4]:" The  xsd:annotationDocumentation element for every
Basic Business Information Entity repres definition there must be MUST
contain a structured set of annotations in the following patterns: §	Unique
Identifier (mandatory): The identifier that references a Basic Business
Information Entity instance in a unique and unambiguous way."
Solution proposal: Either Tim asks Mark to change the NDR or somebody has to
define all UIDs.

3. CoreComponentParameter.XSD
What did we do regarding the DOC-Annotations : We JUST produce
annotation/documentation as in 1.0 Beta. It seems that this schema does not
contain the structures as required by NDR. Anne,is a check whether DOCxx is
implemented or not, an TTSC issue?.

4.
Sue: Please help me to find codes and their names, please!!! Also, I'd
appreciate your check of the entries of the
UBL-UnSpecialisedDataTypes-draft7.xls. Maybe some entries are not correct
(rather CEFACT codelists than UBL).
Tim: IF you refer from specialisedDT to codelistsxx.TXT for NAMES of a code,
THEN: is this just a logical reference or more? if more then we have a
further codelist, don't we?

5. Tim, The next run will contain the UBL-CoreComponentTypes-draft7.xls.
However, Tim, the rules for built-in-types are (should, because I haven't
got any NDR update) in NDR, i.e. we cannot express everything here.

6. Tim, a specialised Data Type "4461_ Code. Type" results in "_4461....",
because a XML tag must not begin with a digit. Are we aware of this?

7a) Tim, I understand that the next schema run produces draft7. Without any
version number? I think we will have to produce them more than once with the
same data (bugs, other changes)
7b)To whom shall we send the schemas?
7c) I think that the Specialised... spreadsheet must have the codelist
namespace prefix at least or we do not have the necessary information to
produce schemas. Your opinion?

8. Michael, Lisa: have you checked the schema sent by David for technical
correctness? It would be good to get any feedback ASAP, even if we still
have to amend them.

9. Tim,you wrote:
"the code list mechanism used here is not what i expected to see.  for
example, in Order we use the Data Type "ISO4217 Alpha_ Code. Type"  for
the BBIE called "Order. Transaction Currency. Code".  you have also
taken "ISO4217 Alpha" as a Qualifier for the Representation Term and
thereby changed the Dictionary Entry Name - we don't want to do this."
Hm, three sentences and three related,but different issues.
1. Do you talk about the following part of the schema?
<xsd:element name="TransactionCurrencyCode" type="sdt:ISO4217AlphaCodeType"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
 <ccts:Component>
  <ccts:CategoryCode>BBIE</ccts:CategoryCode>
  <ccts:DictionaryEntryName>Order. Transaction Currency. ISO4217 Alpha_
Code</ccts:DictionaryEntryName>
  <ccts:Definition>the default currency of the transaction, to be used for
Invoicing.</ccts:Definition>
  <ccts:ObjectClass>Order</ccts:ObjectClass>
  <ccts:PropertyTerm>Transaction Currency</ccts:PropertyTerm>
  <ccts:QualifierRepresentationTerm>ISO4217
Alpha</ccts:QualifierRepresentationTerm>
  <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
  <ccts:DataType>ISO4217 Alpha_ Code. Type</ccts:DataType>
  </ccts:Component>
  </xsd:documentation>
  </xsd:annotation>
  </xsd:element>

2. In order to be fast, please do me the favour and change the example as
you feel, how it should look like.

CCTS:[D14]	The Dictionary Entry Name of a Data Type shall consist of a
Representation Term—preceded by Qualifier Term(s) as necessary —followed by
a dot, a space character, and the term Type. The space character shall
separate words in multi-word Qualifier Terms and Representation Terms. Each
Qualifier Term shall be followed by an underscore. To allow spell checking
of the words in the Dictionary Entry Name, a space character shall follow
the underscores after Qualifier Terms.

10. Tim wrote "also,  why do we still have a 'DerivedCodeType'?  Shouldn't
the
SpecialisedDataType just refer to the namespace for the precise code
list.  Is this just a legacy of the old code list mechanism (and hence
an unnecessary level of referencing) or does it add some value?"
Michael: Tim, we can have different Specialised dataTypes using the same
Codelist, escpecially when we have some customisation. E.G. Country code
will be sued by Ownership of a vessel and by an address.

11. Tim wrote "finally, the structures you build in the Specialised Data
Types still use the old/incorrect attributes and xsd:datatypes.  these
should now be taken from those in the models."
Michael: The Specialised Data Types 'inherit' or inherit the attributes and
xsd:datatypes from the CoreComponentTypes. After having implemented your
CoreComponentTypes-draft7.xls. these issues should be done also in
Specialised Data Types.

thanks
Michael