OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-ndrsc] Minutes for 18 September 2002 UBL NDR SC meeting

PLEASE NOTE: We ARE meeting next week!  We un-canceled the September 25
meeting.  We will try to keep it under ONE HOUR.

Minutes for 18 September 2002 UBL NDR SC meeting 

1. Roll call (quorum is 8)
    Bill Burcham       YES
    Mavis Cournane     no
    Mark Crawford      YES (joined y:40)
    Fabrice Desré      no
    Arofan Gregory     no
    Jessica Glace      YES (joined y:40)
    Michael Grimley    YES
    Eduardo Gutentag   YES
    Eve Maler          YES
    Sue Probert        YES
    Lisa Seaburg       YES
    Gunther Stuhec     no
    Paul Thorpe        YES
    Kris Ketels        no

   Quorum not achieved as of x:42.  We proceeded informally.  Quorum
   achieved at y:40.

2. Acceptance of minutes of previous meeting

   11 September 2002


3. Adoption of agenda


4. Schedule planning and prioritizing

   We assume that our "proactive" work will conclude by the November

   We discussed what to do with undone work at the end of the year:
   Does the NDR document say "These will be fleshed out in the fullness
   of time", or does it say "These will be undertaken in a Phase 2 of
   this work next year"?

   ACTION: Eve to get this issue on the F2F agenda.

   Each of us listed up to five items that we think are most important:

   Sue: nested SCs, naming rules wrt CCTS V1.85
   Lisa: date/time, code lists, facets, containership, local vs. global
   Eduardo: containership, nested SCs, modnamver, referencing strategies,
   Eve: code lists, containership, local vs. global, CCT handcrafting, 
     incorp'ing all decisions/issues
   Bill: CCTS 1.85 alignment, referencing strategies
   Michael: containership, local vs. global, code lists, date/time, 
     embedded doc'n
   Paul: local vs. global, nested SCs, code lists, ASN.1 schema


   CCT module work (includes nested SCs, upgrading to 1.85 ...): 5 votes
   Local vs. global: 4 votes
   Code lists: 4 votes
   Containership: 4 votes
   Date/time: 3 votes (lump this in to the CCT module work)
   Referencing strategies: 2 votes
   Naming rules wrt CCTS V1.85: 1 vote
   Facet outreach (helping LC SC): 1 vote
   Modnamver: 1 vote
   Embedded doc'n: 1 vote
   ASN.1 schema: 1 vote

   Things that didn't get mentioned that we don't want to lose:

   Updating guiding principles
   Nillability (Jessica)
   Instance constraints (Lisa)

   Our new prioritized list:

   A Local vs. global
   A Code lists
   A CCT module work (work on this at the F2F)
   A Containership (work on this at the F2F)
   B Referencing strategies
   B Naming rules wrt CCTS V1.85
   C Facet outreach
   C Modnamver
   C Embedded documentation
   C ASN.1 schema
   C Updating guiding principles
   C Wildcards
   C Nillability
   C Instance constraints

   Bill also noted that it would be helpful to immediately start
   submitting CC discoveries to the UN/CEFACT folks.  Sue reported
   that work is under way to accept such input.

   Today we will discuss local vs. global and code lists.  Next week
   we will plan our F2F agenda and review the NDR document against
   previous meetings' minutes.

5. Review open action items

     - Write content referencing paper.
     - Send date/time NDR snippets to Mavis.
     - With Arofan, prepare samples of how to handle second-tier
     - Bring the donkey to Burlington!

     - Update modnamver paper. (C)
     - Start an email thread proposing a schema location solution. (C)
     - Start a thread on RTs in aggregates and possible NDR
       document bugs in this area. CANCEL

     - Update the embedded documentation writeup.

    - Suggest new F2F agenda item to Jon, as noted above.

6. Work on top one or two items discussed in agenda item #4

6. a. Local vs. global

   We are just waking up this issue now; we'll try to decide it at the 
   F2F, when Fabrice will be present.

   We need to assess the three choices (local unqualified, local 
   qualified, and global) against XSD derivation and see how the 
   resulting schemas and instances look.

   We need to look at the following resources to help us understand
   what's at stake:

   Fabrice's position paper:

   Bill's role model paper:

   Global elements would require that some of our sets of elements with 
   the same name ("ID") would have to get different names.

6. b. Code lists

   Eve's message of last Friday listed several issues we can consider 
   on the code list draft:

   *The need for attributes for the supplementary components

   Mark thought that, in practice, it won't be safe to just use the 
   namespace as a semantically clear indication of the code list being 
   used.  Bill pointed out that we'll have a proliferation of code types 
   and code elements along the version axis, which may be okay -- it's 
   sort of like static type checking as opposed to dynamic type checking 
   (i.e., you have to check the versionID attribute before knowing how 
   to understand the value).

   Sue and Mark mentioned examples of the same code list being published 
   for pay by ISO and for free by UN/ECE, meaning that they're really 
   considered different lists and would have different agencyIDs, 
   versionIDs, etc.

   Our decision on this issue is to RETAIN the current structure, with 
   attributes being required.

   *Whether to encourage/require foreign inner code elements

   We had originally rejected the possibility of using foreign code 
   elements because of our local unqualified element decision.  But 
   since we're importing someone else's type, they can define their 
   own foreign (to us) subelements anyway, and we would *have* to use 
   them in namespaced fashion (assuming they're namespace-qualified, 
   of course!).

   Eve's motivation in bringing up this idea is that it would make the 
   code list schema module more "saleable" to all consumers, not just 
   UBL (which is unusual in trying to define a standard vocabulary with 
   unqualified elements).

   Sue noted that unit of measure codes and currency codes are the ones 
   on which Commerce One receives the most inquiries.

   Bill and Eduardo were in favor of not telling code list agencies to 
   define elements in addition to types, Eduardo on the grounds that if 
   popular application support for elements grows, then UBL won't be 
   able to take advantage of that software in its use of the types 
   only.  Bill's reasoning was that we shouldn't rehash our local vs. 
   global decision, and it's consistent with that decision to require 
   only code types.

   In the absence of support for reopening this, our decision is to 
   RETAIN the current understanding that we just want code list agencies 
   to define types. However, it's okay for the code list document to 
   mention the non-normative possibility of defining elements as long 
   as it doesn't send mixed messages to people who are striving for 
   conformance to our spec.

   *Inner vs. outer code elements

   Eve decided, after all, not to champion this issue, so we dropped it.
   An outer code element is needed for XSD reasons (the neat and clean 
   extension of its type by trading communities) and for ebXML reasons 
   (it represents the true BIE; the inner code elements are just XML 

7. Adjourn

   Adjourned at z:20.

Eve Maler                                       +1 781 442 3190
Sun Microsystems                           cell +1 781 883 5917
XML Web Services / Industry Initiatives     eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC