[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Second run in producing draft7 schemas
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]