[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
syntax
* 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
interoperability
* 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
representation".
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
model.
Eve referred to the following article as revealing of the problem
of thinking there's "one true answer" in markup/modeling:
http://www.itworld.com/nl/xml_prac/08222002/pf_index.html
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)
separately.
- 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
practice.
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
Deferred.
6. Work Plan
* Action items
- Naming rules
- Position papers
ACTION ITEMS:
- Tim to send out a writeup on "containers of functionally dependent
information".
- Gunther to send out proposals for additional container types.
- Eve to send out a writeup on what the relevant processing
paradigms and list container.
NEXT TIME:
We will continue these joint sessions next week, except that the
"joint" portions will start half an hour into the beginning of each
call.
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