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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: