[ubl-ndrsc] Minutes for 9 January 2002 UBL NDR meeting

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

1. Roll call (till x:05)
    Bill Burcham       YES
    Doug Bunting
    Dave Carlson
    Mavis Cournane     YES (x:15)
    Mark Crawford      YES (left y:26)
    John Dumay         YES
    Matt Gertner       YES
    Arofan Gregory     YES (left y:43)
    Eduardo Gutentag
    Eve Maler          YES
    Dale McKay         YES
    Sue Probert        YES (left x:30)
    Ron Schuldt        YES (left y:15)
    Gunther Stuhec     YES
    Mike Rawlins       YES

    Quorum reached

2. Acceptance of minutes of previous meeting (till x:06)
    19 December 2001:
    http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00001.html

    Accepted.

3. Adoption of agenda (please send suggestions *before* meeting) (till x:07)

    Adopted.

4. Action item review (till x:09)

    ACTION: Mark to update tag structure position paper.
    Continued until Friday, January 11.

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

    ACTION: Sue and Maryann to do some use case brainstorming offline.
    Continued until the F2F.

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

    ACTION: Dale to work on the legal issues text provided by Arofan and give
    it to Mark for inclusion in the NDR document.
    DONE. He had list problems; will send it to Eve for forwarding to
    the list.

    ACTION: Mark and Eduardo to propose a set of tag naming
    abbreviation rules before January 9.
    In progress (effectively DONE because we made a decision during this
    meeting).

    See also additional new ACTIONs below.

5. Current position paper champions, status, and priorities (till x:10)

    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
    Mike:
    - Code (enumerated) lists
    Dale:
    - Legal issues

6.  Tag structure position

     Last time we agreed to Option 1: high structure.  We are now
     considering whether to specify fully qualified structured names
     (option 1a) or abbreviated structured names (option 1b), and
     Mark and Eduardo have been working on a proposal for this.

     Here is a rough outline of what they're working on:

     Make global type declarations, and then local element
     declarations within those type declarations with names that are
     named with the property/rep terms and no object classes, and then
     define global elements that aggregate these local elements and are
     called xxxDetails.  The local elements would "inherit" the object
     class of whatever aggregate element they're in (we need to get
     more precise about this).

     So AddressCity, AddressState, and AddressZip (etc.) would be locally
     defined in AddressType, and MailingAddressDetails and
     ShippingAddressDetails (etc.) would be of AddressType.  You wouldn't
     need MailingAddressCity and so on.  The plus is reuse.  The minus
     is losing semantic clarity in tag names.

     We'd still have to decide whether MailingAddress and ShippingAddress
     are allowed to reuse AddressType as is, or whether they will be
     required to trivially derive MailingAddressType and ShippingAddressType.
     But this doesn't prevent us from making decisions on tag naming.

     This proposal doesn't affect global elements that are other than
     xxxDetails elements.  Those global elements would have to have the
     object class/property term/rep term construction.

     One question about this is that it seems to make the most reusable
     elements local, and the least reusable elements global.  Mark feels
     it's justifiable to drop the object class prefix for local elements,
     but not to drop it for global elements.

     "City" elements might be reusable in many locations: airport city,
     rental car drop-off city, etc.  Do we need to be able to reuse a
     CityName element among address, airport, etc. constructs, or is it
     good enough to be able to reuse a CityType in constructing
     AddressCityName, AirportCityName, etc. elements?

     There is more than one level of abbreviation/reuse opportunity:

     MailingAddressCity, ShippingAddressCity, HomeAddressCity,
     RegionalAirportCity, CommercialAirportCity, etc. elements
       vs.
     AddressCityName, AirportCityName, etc. elements
       vs.
     CityName element

     There was agreement that CityName is an acceptable property term/
     representation term pair, and also gives the most reuse.

     Arofan is concerned that we'll have too many levels of xxxDetails
     within yyyDetails.  There will be some elements that don't end in
     representation terms that are, by definition, containers.  His
     proposal is to have a rule for removing "Details" either in all
     cases but the innermost case of xxxDetails, or in 100% of all
     cases.  However, we didn't adopt this.

     Mark notes that there may be some elements declared locally that
     need to have an object class in their name.  For example,
     AddressNumber is better than Number, which is too generic and
     likely to be misinterpreted.  This will be at the discretion of
     the Library Content SC.

     Root document elements shouldn't use the Details construction.
     They should use the Document suffix instead, which is a privileged
     case of Details.

     We achieved unanimous consent on adopting this whole proposal.
     We recognize that input from the Library Content SC or elsewhere
     may make us change our minds.

     We will also have the following issues to decide:

     - Do we use tag names based on ebXML naming conventions (option 1E)
       or tag names based UDEF's naming conventions (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?

     Some of these may have been obsoleted in part by the above decision.

7.  Modnamver position

     See Bill's position paper:
     http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-burcham-modnamver-01.doc

     See also Mark's schema dependency flowchart:

     http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00007.html

     Arofan spoke in favor of Option 3, with the addition of the idea that
     extensions would explicitly be in a third namespace layer.  For
     most context-driven derivations, we want to strongly encourage
     only UBL-namespaced elements to be used.  Any contextualized
     schema derived by UBL means will need its own namespace because
     it will be defining derived types (and possibly new elements etc.).

     (Note that UBL will not be entirely vanilla; it will have a little
     bit of context baked into it.)

     Mike brought up the idea of an Option 0: don't use namespaces.  The
     main technical reason for namespaces is to avoid name clashes.  Another
     reason has to do with performance -- you can use them to do lazy
     loading of individual namespaces.  The xCBL experience (without
     namespaces) has shown that namespaces would have been better, though
     till now the tools support has been spotty.

     There are two places you could put version information: in the
     namespace name and in-band (in the document instance as, e.g.,
     an attribute on the root element).  It should theoretically be
     possible to map the same namespace URI to successive versions of
     a schema, but in practice the tools don't support this mapping
     very well.  However, even if we put the version in the namespace
     URI, it might also be useful to duplicate the version information
     in-band.  Different application levels will benefit from each.

     We settled on the idea that the core namespace should have a version
     and each functional area should have a version.  At the third ring,
     extensions can point to whichever versions they want.  If the core
     revs, we're not sure all the functional areas should have to rev.

     We liked the notion of a major-minor versioning scheme, where a
     minor revision is backwards compatible (e.g., adding a new optional
     element) and a major revision is backwards incompatible (e.g.,
     adding a new required element or removing an element, which breaks
     existing documents, or changing a default value, which changes the
     legal contract agreed to by trading partners).

     How would we indicate the compatibility between pairs of the core
     and individual functional namespaces?  We could say that the major
     number of a functional namespace must be greater than or equal to
     the core, because any backwards-incompatible change to the core
     should force a rev of the functional namespace.

8.  Next steps (till y:59)

     The next meeting will start one hour later than usual, and go for
     one hour.  Mark will run the call.  We will focus on modnamver and
     specific goals for F2F #2.  Spending about half a day on use cases
     at the F2F will be a good idea.

     ACTION: Bill to update the modnamver position paper by Friday,
     January 11.

     ACTION: Eve to make the dial-up arrangements for next week's meeting
     and send out an agenda.

9.  Adjourn
     Adjourned at z:00.
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com