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 2 January 2002 UBL NDR meeting

1. Roll call -- quorum is 9
                                        1a vs. 1b straw poll
    Bill Burcham       YES (x:30)             1b
    Doug Bunting       YES (left y:00)
    Dave Carlson
    Mavis Cournane
    Mark Crawford      YES                    1a (needs to see rules for 1b)
    John Dumay         YES                    1a
    Matt Gertner       YES (y:06)
    Jack Gager
    Arofan Gregory
    Eduardo Gutentag   YES                    1b
    Eve Maler          YES                    1b
    Dale McKay         YES                    1a (needs to see rules for 1b)
    Sue Probert        YES                    1a (needs to see rules for 1b)
    Ron Schuldt        YES                    1a (needs to see rules for 1b)
    Gunther Stuhec
    Mike Rawlins

    Quorum not reached as of x:10; we proceeded informally.  We reached
    quorum at x:30.

2. Acceptance of minutes of previous meeting
    19 December 2001:

    Accepted (x:30).

3. Adoption of agenda

    Agenda adopted.

4. Action item review

    ACTION: Mark to update tag structure position paper.

    ACTION: Mark to check with Mike on what the purpose of Section 5.4 is,
    and follow up with editorial changes as necessary.
    Mark is waiting for Mike to respond.

    ACTION: Sue and Maryann to do some use case brainstorming offline.

    ACTION: Arofan to create a new use case for instance constraint

    Addition new ACTIONS appear below.

5. Current position paper champions, status, and priorities

    ACTION: Dale to work on the legal issues text provided by Arofan and give
    it to Mark for inclusion in the NDR document.

    - Tag structure (A-priority)
    - Design principles
    - Relationship between UBL and UN/CEFACT constructs

    - Choice of schema language (DONE)

    - TPA

    - Customization (taken over by Context Methodology SC)

    - Modularization/namespaces/versioning (A-priority)

    - Elements vs. attributes
    - Document size and performance considerations (Section 6.1)

    - Use cases (with Maryann) (A-priority)
    - Local vs. global elements (A-priority; goes with modnamver)

    - Code (enumerated) lists

    - NEW: Legal issues

6.  Tag structure position

     Decision process:

       Eduardo is concerned that at some level, "naming judgment" is being
       applied anyway, which means that there is always a place where you
       make an arbitrary naming decision.  He also distinguishes compound
       names (having multiple words) from structured names (where there
       are different parts of names with different roles).  He wants to
       ensure that our element names are not too long, and that we don't
       perpetuate the myth that XML versions of EDI have to replicate
       the "flatness" of EDI data.

       All are agreed that reuse of XML elements is desirable, and thus
       that it's not a good idea to lock down all elements to one
       "structural context" (i.e., parent element).

       Ron mentioned the notion of an explicit wildcard for parts of a
       structured name that have been elided.  For example, if you chop
       off the object class that would have clarified the "thing" that
       a DeliveryDate applies to, you could name your element
       <WildcardDeliveryDate> or <AnyDeliveryDate> or something.

     - Do we use highly structured names (option 1) or slightly
       structured names (option 2) or unstructured names (option 3)?

       Option 3: With the caution that some businesses will want to
       create aliases for canonical names, which is not covered by this
       decision, we don't support totally unstructured names.

       Option 2 vs Option 1: With the caution that the choice of strong
       structure is in service of naming the *semantics* and not
       necessarily the *elements*, we agree with Option 1.

     - Do we use fully qualified structured names (option 1a) or
       abbreviated structured names (option 1b)? How much abbreviation
       do we want to allow?

       It's theoretically possible to chop off some representation terms
       because their function is replicated by datatypes in the schema
       document that governs the business document.  However, no one
       supports this because we're dubious that the PSVI will always be
       available.  It's just easier to attach this information to the
       element name.

       We're more confident about chopping off prefixes, namely, the object
       class portion.  The reason for this is precisely to allow the
       element to be reused in multiple parent elements, and therefore
       implicitly take on multiple "object classes".  In any case, the
       simple "ancestry" XPath will always let you address the element
       in all of its structural contexts.

       Mark noted that only leaf-level elements have the tripartite
       structure in his example.  However, we think that some leaves
       are too trivial for this (e.g., ApartmentNumber in an address).
       Also, Mark is concerned that the "reuse" we desire in doing
       abbreviation may not be achievable.

       Option 1a vs. Option 1b: We can't decide until we develop some
       proposed rules for abbreviation.

       ACTION: Mark and Eduardo to propose a set of tag naming
       abbreviation rules before January 9.

     - Do we use ebXML/11179-style names (option 1E) or UDEF-style
       names (option 1U)?

     - Do we add attributes to UBL elements that link them to the
       UDEF structured UIDs?

     - Do we use ebXML-style names for aggregate elements and UDEF-style
       names for leaf elements?


7.  Modnamver position

     See Bill's position paper:

     In reviewing this paper, we realized that the local vs. global elements
     position is intimately tied up with this because if we choose to use
     all-local elements, the decision about how to handle namespaces might
     become a lot simpler.  Dave owns this paper:

     We rejected Option 1 and Option 2 because they're too simplistic and have
     obvious problems.  Option 3 results in exactly two levels, while Option 4
     allows intermediate levels to be introduced, in order to manage the
     "crowdedness" of the original two-level namespaces.

     Option 3 vs. Option 4: This is a little bit like the difference between
     fully structured names and abbreviated (or slightly structured) names; 
if you
     have to make any judgment calls about when to create additional 
     we'll need to make rules/guidelines about this in order to retain
     consistency.  An alternative is to allow more than one included schema
     module file per namespace.

     Matt noted that the 7 +/- 2 doesn't seem to apply to schema modules as 
     as to memorizing telephone numbers, and that it seems fine to have (e.g.)
     a dozen or more types per module.

     We discussed the "semantic difference" between importing and including
     modules.  Bill's current paper uses "root schema" as shorthand for a
     schema module that has its own namespace and gets imported (not included).

     Eve proposed to accept Option 3 provisionally until we start feeling
     uncomfortable with the "size" of any namespaces/files.  At that time, we
     can decide what to do.  We weren't able to decide this yet, but we're
     making progress.

8.  Next steps

     - Plans for January 9 and 16 meetings

     ACTION: Eve to make arrangements for these meetings.  We will meet for
     two hours on the 9th and for one hour (starting an hour later than usual)
     on the 16th.  The same phone number from today will be used.  Mark will
     run the meeting on the 16th.

       Topics for the 9th: Finish tag structure and continue discussing

     - Goals for F2F #2 in Menlo Park

       At least Ron, Dale, and John won't be at the F2F.  At a minimum, we hope
       to decide on all the position papers we have published so far.

9.  Adjourn

     Adjourned at z:00.  Happy new year, everyone!
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