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 4 September 2002 UBL NDR SC meeting (jointmtg w/ LC SC)

Minutes for 4 September 2002 UBL NDR SC meeting

1. Welcome from Joint Chairs
   * Statement of purpose
   * Rules of conduct
   * Appointment of Secretary to take minutes

     * Bill Burcham      YES
     * Mavis Cournane    YES
     * Mark Crawford     no
     * Fabrice Desré     regrets
     * Matt Gertner      regrets
     * Arofan Gregory    YES
     * Jessica Glace     no
     * Michael Grimley   YES
     * Eduardo Gutentag  YES
     * Eve Maler         YES
     * Sue Probert       no
     * Lisa Seaburg      YES (joined y:22)
     * Gunther Stuhec    YES
     * Paul Thorpe       regrets
     * Kris Ketels       no

     * Joe Chiusano      LC SC
     * Marion Royal      LC SC
     * Tim McGrath       LC SC
     * Ray Seddigh       LC SC
     * Bill Meadows      regrets
     * Jon Bosak         TC

     Quorum not reached as of x:35.  We proceeded informally.  We moved
     agenda item #2 to later in the day.  (We later achieved NDR quorum.)

3. Design requirements for UBL Library.
   * physical model (XML Schema)
   * logical model (conceptual)

    Tim compiled the following list of design goals and strategies:

     * Semantic clarity through a binding from Core Components to a
     * Choosing XML as that syntax!
     * Royalty-free IPR
     * Usable “on the cheap”
     * Urgency
     * “Standard” business components need to be different in different
       business contexts
     * These differences need to be accommodated without sacrificing
     * Straightforward Internet use
     * “Various and sundry” tools
     * Legibility (Human- and machine-readable)
     * Simplicity
     * 80/20 rule
     * Component reuse
     * Provide one way to encode information
     * Customization and maintenance
     * Prescriptiveness, tempered
     * Content orientation
     * XML technology
     * Namespace dependency caution
     * xCBL subset non-goal
     * (Schema generation)
     * Completely open, public, accountable standards process
     * Based on United Nations ebXML specifications
     * Intended for normative status under international law
     * Designed for B2B
     * Emphasis on exchange of legal documents
     * Legacy format non-goal BUT compatible with existing EDI systems

Several concepts were proposed and discussed:

- There needs to be a semantically unique and useful definition
   underlying every XML element in UBL.

   This still may leave the choice of adding "containers" up to human
   judgment and taste, but it turns it into a discussion of whether
   the underlying semantics are desirable/true/whatever, rather than
   seeming to reduce the discussion to "XML containers/physical

   We tried to figure out whether it's possible to have a "container"
   that's *not* an ABIE.  We believe that the requirement for a good
   definition means that all containers are ABIEs.  We noted that the
   latest CC work is inventing a "structural" container notion that is
   *not* an ABIE, but perhaps we won't ever need this notion.

   We tested the idea that the special case of "containers of series of
   like elements" is a mere physical container and doesn't have a logical
   reality.  However, a definition such as "Collection of line item
   information" is considered by some to be a sufficient definition for
   the series of line items.  Even if vanilla UBL doesn't actively use
   this "collection" notion (such as associating metadata with the list
   that applies to the entire list), a customization might.

   Another possibility is to automatically add a physical container
   surrounding each case of 0..n or 1..n property cardinality.  If
   someone wants to extend the model to tack on different elements
   to the content model, only then does the container turn into an ABIE.

   Arofan noted that it's possible to turn unlike elements into like
   elements by using the extensibility trick of making them be the same
   element with a property that indicates their type.

   It was certainly agreed that all *true* ABIEs need good definitions.

- Modeling doesn't give the end-all and be-all answer of what should
   be in your model

   It was noted that it's possible to follow even the most carefully
   designed and constrained modeling processes and tools, and get
   different results.  Real-world applications need to be the
   tie-breaker of when and how we decide to put something in our

   Eve referred to the following article as revealing of the problem
   of thinking there's "one true answer" in markup/modeling:


   There was some disagreement with this point of view, in that the
   context methodology should be properly applied to give the right
   answer.  However, it's unclear so far how to apply it properly,
   since the vanilla UBL Library doesn't have a formal context
   mechanism that affects the actual model, in the way that the
   the customization process does (or will).

- We need to avoid "Xeno's paradox" in making design decisions

   The line between list-containers and ABIEs is perhaps fuzzy.
   Where there are fuzzy distinctions, we may not want to spend
   too much effort drawing the line.

   It was suggested, on the one hand, that we may fail if we put
   "perfect" decisions ahead of decisions "soon", and on the other
   hand, that previous B2B vocabulary efforts were ineffective
   because they were inconsistent in their treatment of containers.

   Jon noted that it's possible to make unambiguous (semantically
   clean) decisions on a case-by-case basis, and so he doesn't see
   the need for a grand unified theory of containership.  Containers
   added to the logical model (ABIEs) will always be
   "information-bearing" and therefore deserve to be there, even if
   there are performance issues (as there often are with XML and its
   verbose, deeply nested ways).

   Arofan said that xCBL had made a mistake in being too container-
   intensive.  There's a human-understanding function of containers
   that they might have exceeded.

   UBL's "various and sundry" and "XML technology" design goals were
   invoked in a discussion of how we need to ensure that UBL XML
   representations are easy to process using existing (and sometimes
   dumb) tools.

4. Grouping elements
   * Containership approach
   * Data modeling approach
   * Other alternatives

We think there might be the following kinds of containers.  We can
assess the need for each of these (logically and physically)

- List containers

   This kind of container collects a series of like elements.  It
   is possible to put this container in the model (logical) or to
   apply it automatically (merely physical).

- Presentational containers

   This kind of container would have, as its motivation, either
   old habit (history) or, more likely, a particular mode of
   processing which the container facilitates (or at one time
   facilitated).  It's awfully hard to write good ABIE definitions
   for these; you have to resort to "pass-through" tricks such as
   "Order.Header.Details is a collection of information that
   applies to the order as a whole" and "OrderHeader.Language.Details
   is the language in which the parent of the order header is
   encoded".  (Note that the actual dictionary name of the latter
   ABIE in 0pt65 is, revealingly, Order.Language.Details and not
   OrderHeader.Language.Details!)  History-based presentational
   containers have arisen in both the traditional EDI world and the
   SGML/XML world.

   If this kind of container is ever desired, it must appear
   in the logical model somehow; its presence can't be inferred
   automatically in building the physical representation.

- Containers of functionally dependent information

   These are containers that wrap groups of information that are
   dependent on each other.  For example, party information (such
   as name and address) are functionally dependent in that when
   they vary, they vary together.  This is the notion of the third
   normal form, which is well established in database modeling

   This kind of container naturally fits into the logical model,
   and therefore has a physical representation as well.

It was noted that the same arguments that apply to ensuring that
the XML representation is readable and understandable also apply
to the readability and understandability of the logical model
as well.

Ray suggested that we need to account for "open containers" where
it's possible to add arbitrary non-UBL content.  This is a topic
that the context methodology work intends to treat.  There is also
a planned NDR discussion on wildcards, which is one way to implement
extensibility for UBL.

5. Open discussion on how these fit with requirements
2. NDR motion on containership for lists
   * Revised draft of statement


6. Work Plan
   * Action items
      -  Naming rules
      -  Position papers


- Tim to send out a writeup on "containers of functionally dependent

- Gunther to send out proposals for additional container types.

- Eve to send out a writeup on what the relevant processing
   paradigms and list container.


We will continue these joint sessions next week, except that the
"joint" portions will start half an hour into the beginning of each

We need to discuss the relevant processing paradigms that might
lead us to recommend presentational and/or list containers.

We plan to come up with a unified position paper on this whole area,
using the writeups contributed by various people as fodder.

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com

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

Powered by eList eXpress LLC