ubl — archive

Minutes, Pacific TC meeting, 2 December 2004

From: Anne Hendry
To: [email protected]
Date: Thu, 02 Dec 2004 03:35:00 -0000

MHonArc v2.5.0b2 -->

ubl message

Subject: Minutes, Pacific TC meeting, 2 December 2004

From: Anne Hendry <[email protected]>
To: [email protected]
Date: Wed, 01 Dec 2004 19:44:22 -0800

The UBL Pacific call occurred at 00h30 UTC on 2 December 2004

Present:  Tim McGrath, Anne Hendry

Discussion (from Atlantic agenda items):

UBL-CoreComponentTypes
------------------------------
4. [MDC1] UBL Libraries and Schemas MUST only use ebXML Core Component
     approved ccts:CoreComponentTypes.

     Actions/Questions for TC:
     - Consider the impact of the fact that we have removed the 'format'
       'format' attribute and constrained these as simple types.
       Is this really how we want these represented in the future?

   20041202:
   We do use the approved CCTs.  Rule doesn't say anything
   about their supplementary components.  The reason we've
   done this thing with 'format' is that our use of xsd makes having
   the additional ccts format ambiguous. Now that we've done this it's
   not clear what the ramifications will be (probably not a problem),
   nor the issues of going back.  Think this is best left alone for now.
   May be resolved with 5, 6, and 7 below.

5. The ss and schemas of cctypes are currently quite different
     because EF is not reading the CCT spreadsheet - the CCT schema
     is generated manually as was originally provided by Gunther.
6. [STD1] For every ccts:CCT whose supplementary components map
            directly onto the properties of a built-in xsd:Datatype,
            the ccts:CCT MUST be defined as a named xsd:simpleType
7. [CTD7] Every unspecialised Datatype must be based on a ccts:CCT
            represented in the CCT schema module, and must represent
            an approved primary or secondary representation term
            identified in the CCTS.

   Actions/Questions for TC (for 5,6, and 7):
     - Decide on need for generation of CC Types and UDT by UBL.
       Work towards convergence with ATG2.  Obvious concerns:
       impact on legacy and the fact that ATG2 has always been
       a moving target, hence the misalignment we find ourselves
       in now, as our current implementation was put forward as
       the ATG2 method.  Determine actions and timeline.

   20041202:
   We agreed that it is fruitless for UBL to develop new version of these
   that are not convergent with atg2.  We can evaluate this again once
   atg2 has been approved. Can't do for 1.1.  Tim posted lasat week
   the results of the most recent conversations.  If we have an atg2
   liaison this should be in their hands.   Possibly put  on2.0 list.

UBL-SpecializedDatatypes
----------------------------

5. Three attributes used for each of the code types in the spreadsheet
     (codeListNamespacePrefixID, codeListDescription, CodeListCredits)
     are not represented in the schemas.

     Actions/Questions for TC:
     - Agreement from Jon that CodeList Credits are not needed any longer.

   20041202:
   We probably should have Credits for a legal reason, esp for  iso ones.
   How do we extend the ccts model for things like these?
   We've only done this in the specialized (UBL) codes.
   But this could use more explanation somewhere.
   Need to have a way to add information that is not specified in CCTS.
   There will always be this need since no implementation can be as
   generic as CCTS.

   For testing, Stephen removed these three rows from each of the
   Code/Codelists in the SpecializedDatatypes spreadsheets and created
   two new columns 'Codelist Schema Prefix' and 'Content Definition',
   However, this is not a way we can carry forward as it incorrectly
   models these elements.  Need better way to reprsent this in our
   abstract model (ss).  Also need to decide how to show it in the schema.

   - Need to resolve both how to model extra info and how to implement 
in schema
   - Also need to reinstate 'credits'.

   Discuss again in Atlantic TC call.

Spreadsheets - General
----------------------

2. [DOC2] A Datatype definition MAY contain one or more Content
            Component Restrictions to provide additional information
            on the relationship between the Datatype and its
            corresponding Core Component Type.  If used, the Content
            Component Restrictions must contain a structured set of
            annotations in the following patterns: ...
   
   20041202:
   See figure 7-1 and table 7-1 in CCTS).
   UBL doesn't use format restrictions so this won't apply to our schemas.
   This could possibly be used for Code Lists (to restrict the 
enumerations).

Other:
   Next set of SS will be ones that come out of the SS/EF round-trip 
testing process.
   Until then, all else should be viewed as prototyping.
 
Adjourn: 2h15 UTC