[ubl-ndrsc] Minutes for 20 February 2002 UBL NDR meeting

["Eve L. Maler" <eve.maler@sun.com>]

1. Roll call (till x:05)
    Dave Carlson is no longer a voting member.  (This isn't reflected on
    the portal yet.)

    Bill Burcham
    Mavis Cournane     YES
    Mark Crawford
    Fabrice Desré
    John Dumay
    Matt Gertner       YES
    Arofan Gregory
    Phil Griffin
    Eduardo Gutentag
    Eve Maler          YES
    Dale McKay
    Joe Moeller        YES
    Sue Probert        YES
    Ron Schuldt        YES
    Lisa Seaburg
    Gunther Stuhec
    Paul Thorpe

    We didn't achieve quorum, but we did achieve critical mass, and began
    by discussing the code list position paper.

2. Acceptance of minutes of previous meetings (till x:06)
    13 February 2002 telecon:
    http://lists.oasis-open.org/archives/ubl-ndrsc/200202/msg00057.html

    Deferred.

3. Adoption of agenda (till x:07)

    Accepted by default (though we bounced around a lot).

4. Planning for March 11 deadline (till x:15)

    ACTION: Arofan and Mark have to make progress on the tag structure
    writeup as soon as possible!  (Arofan, hope you feel better soon!)

     - Feb 21-17:    Ratify code lists, finish tag structure (relies on
                     Mark/Arofan update), sharing tag names/types
     - Feb 14-20:
     - Feb 21-27:
     - Feb 28-Mar 6:
     - Mar 7-9:

     Remaining work (how to fit it into the weeks?):
     Elements vs. attributes
     Empty elements
     modnamver
     Sharing names when types are shared
     Final edits

5. Action item review (till x:20)

    Discussion of these was deferred.

    ACTION: Arofan to join Mark in writing the tag structure material.
    It needs to be written in a "normative" way (i.e., as instructions
    ready to be put into the NDR document).  Due February 20.

    ACTION: Eve to take over the writing of the code list material.

    ACTION: Bill and Mavis to champion the URI/URN issue and determine
    an approach.  Arofan suggested talking to Kelly Schwartzhoff about
    this problem.  In progress.

    ACTION: Arofan, Tim, Gunther, and Lisa to develop example and code
    with LC SC.  This example should grow to illustrate the modnamver
    proposal.  To be sent to both LC and NDR SCs.

    ACTION: Arofan to liaise with the CMSC on the issue of code list
    extensibility and subsetting.  In progress.

6. Code lists

    Subsetting: It may be possible to subset code lists by reference to
    an externally defined subsetting in some cases, e.g. in certain
    industries.  But in addition we might need to allow for subsetting
    of an external code list by raw enumeration.  Both of these, if
    determined as actual requirements, will probably need to be accounted
    for explicitly in the design of the context rules language.

    Handling new versions of code lists: Very rarely, it does happen that
    an old code gets defined to have a different meaning in a new version
    of the code list.  In these cases, the text in Section 3.1 of the
    position paper would apply, but we probably don't have to worry too
    much about backwards incompatibilities in external code lists.

    Extension: What if we allowed the regular code field to contain anything
    you want, and then have an additional field that's a boolean "custom
    flag"?  That way, you only have to check the one field for the actual
    desired value, and if you case that it's custom or not, you can check
    the flag.

    Further regarding extension: Is it ever legitimate to extend a code
    list by adding an ad-hoc custom value, when the code list itself doesn't
    give "permission" for this?  Can you do "un-premeditated extension"?
    It appears that most, if not all, code lists will build in the escape
    hatch, so maybe this isn't a concern.  Sue notes that the escape
    hatches are usually in order to cover legacy data.  Should we force
    all custom codes to somehow point to their own documentation, e.g.,
    with a URI reference?  The use of XML "namespace prefixes" here would
    not be consistent with good XML practice, but it's intuitively quite
    appealing.

    Code lists and their management are sort of a "societal" problem.  UBL
    has the opportunity to help make the extension and growth of code lists
    more tractable, but it has to avoid being swallowed up in the process.

    New ACTION: Eve to update the code list position paper to reflect the
    ideas brought up in the 20 Feb discussion, and disseminate it to the
    LC SC before their meeting on 21 Feb.

7. Tag structure
    - Oxford English (deferred, but we plan to support it)
    - Delimiters between portions of a name (LC SC is looking at it)
    - Non-letter characters (deferred)
    - Singular and plural
    - Articles, prepositions, etc. (deferred)
    - Acronyms, abbreviations, and truncations:

      We think we have the answer to this from last time.  However, we
      think that there may be some exceptions that really do creep in,
      e.g., DUNS ID and UNDG (UN Dangerous Goods Number).  And we'll
      have to decide how to spell these: DUNSID or DunsId?  We'll have
      to keep a library of all these exceptions.  We're leaning towards
      spelling these all uppercase; of course the dictionary entry will
      indicate the "parts" of the names in order to make everything
      clear.  This potentially has the same problem with ambiguity as
      the decision to avoid delimiters in the markup names; we'll just
      have to keep an eye on this.

    - Top-level tag names

      Matt's argument against a representation term of "Document" on the
      top-level elements is that it's unnecessary.  These elements are
      distinguished as document elements in several ways: They're uniquely
      at the top and they're global.  Thus, OrderDocument could be just
      Order.

      "Document" has a technical meaning in XML.  So even if you're
      exchanging "enterprise" data or "person" data, it's still conveyed
      in an XML document.  In discussing the idea of a "Document"
      representation term, do we mean it in the XML sense or in the
      sense of a top-level business transaction document (which perhaps
      isn't always the case)?

      Ron is concerned that some transactions might involve partial
      documents, e.g. asking a party for its identifying information and
      having them respond with just a "party" block that isn't a whole
      UBL document.  Sue points out that there is a "master data"
      exchange that involves a sharing of metadata, so that subsequent
      transaction can just say "the usual, please" :-) without having
      to specify the particulars by value.

      The current list of planned UBL documents doesn't include these
      "partial-document" document types.  Do we have a problem with
      exchanging instances of parts of the core library without a
      governing document type?  Or alternatively, should UBL be defining
      more of these generic, small document types?

      New ACTION: Ron to write up a description of the "partial document"
      use case by next Monday for review by the NDR SC and LC SC.  Sue
      to forward Ron's NDR mail on this to the LC list.

      We will try and resolve this before Barcelona.

7'. Sharing tag names/types and the "role" proposal

     We briefly discussed Bill's role proposal.  There was somewhat
     of a sense that tag names should directly reflect facts about
     the structural type, since making tag names match because of
     "role" similarities is a much more subjective process.  Also,
     there was some resistance to and confusion about saying that a
     header in an order has a "header" role.  The concept of a "role"
     is overloaded and possibly risky.

     We briefly discussed whether it's a good idea to give "role"
     semantics to the same element depending on its position (e.g.,
     the first Party element in an order is the buyer and the second
     Party element in an order is the seller).  It's considered bad
     XML practice to do this.  It may be necessary sometimes to have
     an attribute that allows you to set the desired role (e.g.,
     <OtherParty Role="BillTo">...).  But this still distinguishes
     the role syntactically.

     It was suggested that this need to allow for "extensible roles"
     may need a design rule.  We suspect that it's better to lock
     down the role as a property term qualifier if you can, because
     this gives you more validation power.  But when you can't know
     the role in advance, we may want a design pattern to solve this.

     New ACTION: Matt to do a writeup on the "document design time"
     (fixed vs. varying) assignment of roles.

8. Next steps

     - Feb 21-17:    Ratify code lists, finish tag structure (relies on
                     Mark/Arofan update), sharing tag names/types

9. Adjourn

    Adjourned at y:43.
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com