OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


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


Following are the minutes from today's meeting of the Naming and Design 
Rules subcommittee.  We made some major decisions on tag structure/markup 
naming today, and we will be looking to the Library Content subcommittee 
(and others!) to get feedback.  Look for an updated position paper on this 
topic at the NDR portal by the end of the week:

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

We also started firming up our opinions on the 
modularity/namespaces/versioning issues.

         Eve

>Date: Wed, 09 Jan 2002 13:01:09 -0500
>From: "Eve L. Maler" <eve.maler@sun.com>
>Subject: [ubl-ndrsc] Minutes for 9 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 (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



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


Powered by eList eXpress LLC