[ubl] Fwd: [ubl-ndrsc] Minutes for 2 January 2002 UBL NDR meeting

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

If you care about tag names and "modnamver" (modularity, namespaces, and 
versioning), you should take a look at the NDR subcommittee's latest 
minutes below.  You can find all relevant position papers on our portal:

   http://www.oasis-open.org/committees/ubl/ndrsc/

>Date: Wed, 02 Jan 2002 13:02:39 -0500
>From: "Eve L. Maler" <eve.maler@sun.com>
>Subject: [ubl-ndrsc] Minutes for 2 January 2002 UBL NDR meeting
>To: ubl-ndrsc@lists.oasis-open.org
>List-Archive: <http://lists.oasis-open.org/archives/ubl-ndrsc>
>
>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:
>    http://lists.oasis-open.org/archives/ubl-ndrsc/200112/msg00049.html
>
>    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
>    checking.
>
>    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.
>
>    Mark:
>    - Tag structure (A-priority)
>    - Design principles
>    - Relationship between UBL and UN/CEFACT constructs
>
>    Eve:
>    - Choice of schema language (DONE)
>
>    Doug:
>    - TPA
>
>    Arofan:
>    - Customization (taken over by Context Methodology SC)
>
>    Bill:
>    - Modularization/namespaces/versioning (A-priority)
>
>    Gunther:
>    - Elements vs. attributes
>    - Document size and performance considerations (Section 6.1)
>
>    Dave:
>    - Use cases (with Maryann) (A-priority)
>    - Local vs. global elements (A-priority; goes with modnamver)
>
>    Mike:
>    - Code (enumerated) lists
>
>    Dale:
>    - 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?
>
>       Deferred.
>
>7.  Modnamver position
>
>     See Bill's position paper:
> 
>http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-burcham-modnamver-01.doc
>
>     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:
>http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-carlson-localvsglobal-01.txt
>
>     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 
> namespaces,
>     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 much
>     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
>       modnamver.
>
>     - 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