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 13 February 2002 UBL NDR meeting

1. Roll call
    Doug Bunting and Mike Rawlins are no longer voting members.
    Lisa Seaburg is now a full voting member.

    Bill Burcham       YES
    Dave Carlson
    Mavis Cournane     YES
    Mark Crawford      YES (x:17; reached quorum)
    Fabrice Desré      YES
    John Dumay
    Matt Gertner
    Arofan Gregory     YES
    Phil Griffin
    Eduardo Gutentag   YES (left y:50)
    Eve Maler          YES
    Dale McKay         YES (x:50; left y:50)
    Joe Moeller        YES
    Sue Probert        YES
    Ron Schuldt
    Lisa Seaburg       YES (x:22)
    Gunther Stuhec     YES (x:58)
    Paul Thorpe        YES

    Marion Royal       YES (y:22; observer; left x:55)

    Quorum not reached as of x:06.  We decided to start informally.  We
    reached quorum at x:17.

2. Acceptance of minutes of previous meetings

    6 February 2002 telecon:

    Eduardo noted that he was volunteered for something inappropriately.
    It was pointed out that the action was to *ask* him to do something,
    not for *him* to do something. :-)

    Minutes accepted once quorum was reached.

3. Adoption of agenda

4. Planning for March 11 deadline

    - Feb 7-13:     Finish tag structure/data dictionary issues and code
    - Feb 14-20:    Finish elements vs. attributes and Empty Elements
    - Feb 21-27:    extension and MODNAMVER and Top Level Element Naming
    - Feb 28-Mar 6: Qualified vs unqualified and Name/Type Sharing
    - Mar 7-9:      Final NDR document/position paper edits

    We need to properly document the decisions we've made to date, and
    make sure it works for the LC SC.  The NDR document needs new content
    reflecting our "tag structure/local vs. global/relationship to CC"

    New 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.

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

5. Action item review

    ACTION: Mark to update tag structure position paper.  Now an action
    for Arofan and Mark both.

    ACTION: Sue and Maryann to do some use case brainstorming offline.
    Action dropped because it's been overtaken by events.

    New ACTION: Eve to ask Dave if he wants to drop back to observer

    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 (till y:15)

    The ur-issue is: Should code lists be validatable?  Some are, but
    some aren't.  For example, we might not want to validate zip codes
    or location codes, but then they're not enumerable in practical
    terms.  A potential candidate for enumeration (by whatever means)
    needs to have a closed set of codes, where the set might change
    only every few months.  However, this would include zip codes, and
    we still don't think it's reasonable to enumerate zip codes.

    Are most SMEs are going to be using more than a limited subset of
    most code lists in their document creation process?

    What are the costs of letting a "bad code" get through to the
    application?  Considering that the application has to know about
    a code in order to take the appropriate action on encountering it,
    what is the real consequence of letting applications do their own

    It's possible to get "partial validation" in XSD by just doing
    pattern matching.  In this case, extension and subsetting is a lot
    less complicated procedure, and "code list identification" wouldn't
    be needed.

    The use of XSD validation is only one thing standing in the way of
    people who want to abuse the ability to make their own codes.  They
    will still do "code abuse."

    xCBL has what may be a good starter set of code lists.  We could draw
    the dividing line there, or much sooner (fewer lists).  There is a
    considerable cost for each "internal" code list because we have to
    maintain it, track its mapping to external ones, etc., so perhaps we
    should minimize the creation of internal code lists.

    Would it be possible to ask external organizations to produce and
    maintain schema modules that define enumerated types for their codes?
    The UN is the primary one.  If they get around to doing this, at that
    time we could consider using them for run-time validation.

    Mark's proposal: We should use external code lists as much as
    possible, and in those cases leave validation and subsetting up
    to the application (except perhaps for pattern matching).  We
    should create our own validatable code lists sparingly.  This is
    a short-term solution.  In the long term, we would have the option
    to use validatable forms of the external code lists provided by
    external organizations.

    Formal vote: Arofan votes no, Bill and Lisa abstain.

    We noted that, in the few cases where UBL does need internal code
    lists, we should try to start with xCBL's.  This needs to be discussed

    Identifiers for a whole code list:
    - Requirements:
      . Refers unambiguously and uniquely to one list
      . UBL can assign (for internal code lists)
      . Others can assign (for external code lists)
      . Extension designers can assign without clashing

    UBL needs a list of code list identifiers.  The items in the list
    need to be unique and unambiguous.  But they can be mapped to the
    formal names of the relevant external code lists (e.g., the ISO
    ones) -- they don't have to be identical to the ISO one.

    If we define enumerated types, these types are in some XML namespace.
    We could play games with defining such types in a variety of different
    namespaces.  We could "version" the types by putting attributes in
    the schemas somehow.

    - Options:
      1. URI reference as a "code list namespace name", not necessarily
         resolvable on the web
      2. Ad hoc (e.g., ISO number, UBL descriptive keyword, etc.)
      3. Let people use whatever names their system recognizes
      4. Other

    We didn't discuss any of the other code list issues below.

    Versioning a whole code list:
    - Requirements:
      . Need to keep the identifier the same when version changes?

    - Options:
      1. Put version in identifier
      2. Keep identifier the same over time but provide separate
         version info in markup

    Maintenance of external code lists:
    - Requirements:
      . UBL will need "machine-readable" form of these
      . Can UBL afford to maintain?
      . Are there legal issues around this?

    - Options:
      1. UBL maintains
      2. External groups maintain, through arrangement if necessary
      3. No machine-readable form of these
      4. Other

    Provision of a code in markup:
    - Requirements:
      . Ideally can be checked to be a valid code
      . Can fully but succinctly document the code's meaning
      . Do users ever need the "zz" escape hatch capability?
      . Possible codes should be subsettable based on context
      . Do codes need to be extensible based on context?
      . Possible codes should be extensible by extension designers
      . Performance requirements in validation?
      . Performance requirements in processing?

    - Options:
      1. Enumerated list of string values
         a. With "zz" option
         b. Without "zz" option
      2. Unrestricted string
      3. String with pattern-matching restrictions
      4. One unique UBL element per code
      5. String from code list validated at run time
      6. Other

    Style of code naming:
    - Requirements:
      . Ideally should match the prevailing industry code list usage?
      . Needs to be compact and concise?
      . Needs to help instance readability?
      . Needs to provide semantic clarity?

      1. Alphanumeric
      2. Numeric
      3. Full spelling
      4. Combination
      5. Ad hoc
      6. Other

7. Tag structure (till y:50)
    Position paper:

    - Getting the tag structure decisions documented and bought into

    Other issues:
    - Oxford English

      We should rubber-stamp this next time.

    - Delimiters between portions of a name

      These may be needed only in the dictionary and not in the tag names.
      If there's ever a situation wherein there are two dictionary entry
      names that could resolve (once delimiters are removed) into the
      same tag name, we may have to reexamine it.  Then again, it may be
      possible to deal with these on a case-by-case basis and not have to
      add delimiters to tag names in a blanket fashion.  This issue is
      currently being examined by the LC SC folks.

    - Acronyms, abbreviations, and truncations

      We may want to discuss selectively allowing a few acronyms (like
      "ID" instead of "Identifier"!).  But "PO" for purchase order is
      not good practice.

    - Non-letter characters

      Is "enumeration" (like AddressLine1, AddressLine2, etc.) a good
      practice?  It would be nice to really restrict numbers.

    - Singular and plural
    - Articles, prepositions, etc.

      These are probably pretty good rules.

    - Recommendation for maintenance of RT list

      Not discussed.

8. Next steps

    We will try to finish "tag structure" (the big picture) and code lists
    next week.  We will need to examine proposals in email.

9. Adjourn

    Adjourned z:04.
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

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

Powered by eList eXpress LLC