Agenda for Co-ordination meeting Wednesday 24 March at 08:00 Californiat

A joint meeting of the UBL subcommittees will be held Wednesday 24 March 2004 from 8-10 a.m. California time to
progress the devlopment of the UBL 1.0 schemas.  

Check your timezone at...

http://www.timeanddate.com/worldclock/fixedtime.html?year=2004&mon=03&day=24&hour=16&min=0&sec=0


Every UBL member with an opinion on this subject should attend the call.  

   #############################################
   STANDING INFORMATION FOR UBL CONFERENCE CALLS
   U.S. domestic toll-free number: (866)839-8145
   Int. access/caller paid number: (865)524-6352
   Access code: 5705229
   #############################################

The proposed agenda is as given, if you have other items please post to the list before the call...

A. Action Items for 9.2 schemas
-------------------------------
(apologies for re-numbering issues but it had to be done!)
1) We are missing a required 'Version' element in the documentation
      of every data type. (We seem to be missing it in all the other
      schemas as well, for data types *and* BIEs.)
Agreed.
AI - Mike - add to cc parameters
AI - David - populate in schemas using 'build number' (e.g. "1.0-draft-9.1")

2)There are some documentation elements whose names do not reflect
   those specified in the NDR: Occurrence, & ComponentType.
   should be Cardinality & CategoryCode
AI - Tim - Occurrence to be changed to Cardinaility in models and CC Parameters
   NDR - CategoryCode to be changed to ComponentType in NDR

3) In the CCT schema, the attribute definitions all declare
    'use="optional"' even though it is the default value and does not
    need to be declared. In the UDT schema, 'use="optional"' is *not*
    declared (except in the restriction of 'cct:IndicatorType'). Do we
    want/need to be consistent here?
AI- David - consistently, explicitly spell out 'use="optional"'

4) The documentation elements are not listed in the order specified in
    the NDR.
AI - Mike G - change the order in cc parameter schema
AI - David - recognize when building the schemas

5) 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.
AI- David - populate data type of secondary rep terms with primary rep
      term.

6) Should have an import statement for UnspecialisedDatatypes to
    indicate this is where to get data types for any new types from.
AI- David add import statement to top of schemas.

8) 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).
AI - David - don't include root element in code list schemas

10) We should have a ccts:DataTypeQualifer value for each code type (in
     the documentation).
AI - David populate in schema documentation.

11) Minimum and Maximum Temperature do not have a correct ccts:DataType
    (it says <ccts:DataType>. Type</ccts:DataType>)
AI - Tim - remove definition of data type for ASBIE's in model.

12) Document schemas should import Specialised Data Type schema
AI - David - add import statement for Spec data type for all document schemas.

13) In the UDT schema, the 'DateTimeType' definition is what I would
     expect; there is a restriction on cct:DateTimeType that removes the
     infamous 'format' attribute.
     However, the datatypes with a base of 'cct:IndicatorType' or
     'cct:NumericType' define a restriction, but then include the
     'format' attribute, which in effect makes it no different than the
     CCT datatypes.     Is this what was intended?
AI - David remove format attribute on UDT indicator type, and numeric
       type (and those based on)

B. Open Items for Further Discussion
------------------------------------
14) there seems no point in a /codelist directory. shouldn't these just
    be in '/common'?
Sponsor - Tim

15) 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.
AI - Mike G -research and give example(s) for discussion Wed.
    Related issue: should any elements be defined in document schemas or should all be in cbc.(was tim's issue 11.)
Sponsor - Tim

16) list all required final release changes
       - e.g. relative paths are being used for now to facilitate our validation (e.g. so we can review them without being connected to the internet).
       - remove all vendor names.
Sponsor - Mark

   17) There are modules created (cC parameters) we don't define,
Sponsor - Mark

   18) There are modules missing (UCTDT),
Sponsor - Mark

   19) There are empty modules (SDT despite specialised datatypes masquarading as unspecialised or changed CC types),
Sponsor - Mark

   20) There are elements declared that should not be ( for cct and datatypes),
Sponsor - Mark

   21) The code list schema modules are imported Directly intothe cbc and cac modules rather than the UCTDT module which I believe causes circituous import issues,
Sponsor - Mark

   22) The truncation rules are not applied consistently (see the cct supplementary components for an example),
Sponsor - Mark

   23) The base types for almost all of the cct supplementary components have been changed in the cctmodule rather than creating specialised datatypes as we previously agreed to.
Sponsor - Mark

C. Other Business.
------------------

ubl message