[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 11 September 2002 UBL NDR SC meeting (jointmtg w/ LC SC)
Minutes for 11 September 2002 UBL NDR SC meeting PLEASE NOTE: The NDR SC is now planning to meet on September 25, rather than skipping that meeting. See the bottom of these minutes for details. 1. Roll call (quorum is 8) * Bill Burcham YES * Mavis Cournane YES * Mark Crawford no * Fabrice Desré no * Matt Gertner no * Arofan Gregory YES (joined y:12, left y:??) * Jessica Glace no * Michael Grimley YES * Eduardo Gutentag regrets * Eve Maler YES * Sue Probert YES (joined y:00) * Lisa Seaburg YES * Gunther Stuhec YES (joined y:00, left y:31) * Paul Thorpe regrets * Kris Ketels no Others: * Tim McGrath (LC) yes * Bill Meadows (LC) regrets * Joe Chiusano (LC) regrets * Jon Bosak (UBL) yes * Ray Seddigh (LC) yes NDR quorum not achieved. We proceeded informally. We achieved quorum at y:12, but lost it again at y:31. 1'. Approval of agenda Approved, noting that we can end early if we want! 2. Joint session begins: containership - Review Tim's paper: http://lists.oasis-open.org/archives/ubl-ndrsc/200209/msg00016.html Tim summarized the paper and added some side comments. Any vocabulary needs to have some way of logically grouping business information entities into aggregates. This paper describes a process of rules by which we can establish this logical grouping. The main concept around which grouping is done is "dependencies", and the process is called "normalization". (These come from the relational world.) The paper has an appendix on how to apply these logical processes to XML and XSD. Tim believes that any process we come up with will still have to allow for other factors, such as subjective judgment based on domain knowledge and so on. A process simply lets us to come up with somewhat consistent results. "Structure" and "ABIE" and "BIE" are terms to describe the logical model and its process. "Container" and "element" are terms used to describe the physical model (the XML result). A (functional) dependency is the organizing principle that we often use intuitively already. "Dependency means that if the value of an attribute changes when another attribute value changes, then the former set is dependent on the latter." A name depends on a date of birth , since when you change one, the other changes -- they vary together, per person. So "person" would make sense as a group structure (entity, in relational-speak). The normalization technique was evolved to help analysts figure out real dependencies and get rid of false ones. The different "<n>th normal forms" reflect different qualities or stages of normalization. Third normal form is what Tim believes we should target. We shouldn't have constituent BIEs inside an ABIE that are dependent on each other in addition to the ABIE. This means that they should be separated into their own ABIE. If transport providers vary per vehicle, vehicle should be a group structure. (To take Arofan's example in his containership paper.) In the case of persons, a name might in fact be useful as a unique identifier for each instance of a person. (So sometimes people use a shorthand, saying that dates of birth vary "per name".) In UBL modeling, we do have a lot of BIEs that are "Identifiers", but they're partial only -- they cover only one segment of what would be needed to *uniquely* identify the BIE in question. Each of the line items in an order can be partially identified by the item number, but to make it truly unique, an identifier would also have to refer to the order number. (However, it's also possible to create a singular line item identifier that incorporates the order number within it somehow.) First normal form involves removing sets of repeating structures an making them their own structure. Second normal form involves the name/date of birth types of analysis, checking each of the BIEs within an ABIE and ensuring that they are dependent on it (or, as shorthand, dependent on the BIE that can serve as a unique identifier within the ABIE). In third normal form, the final step (as recommended by Tim), the non-key (non-identifier) elements are scrutinized to find and remove anything that varies independently of the rest of the structure. This process formalizes things as much as possible, but it's a craft rather than a science. And the output of this process still needs to be turned into XSD, which isn't entirely trivial. (Of course, the model could also be mapped to relational tables and object representations as well -- a relational E/R diagram could as easily be turned into a class diagram without methods.) The choices we make in deciding how to "containerize" the XML version of the model might reflect a path through, or view into, the data. This might make a difference particularly when it comes to dynamic assembly, but even in the meantime, it would be important to capture why each choice was made. It would be possible to avoid association by containment to a very large degree (a series of independent XML elements, associated only by linking). If we did this, we might not be leveraging XML technology in the way that our guiding principles suggest, since a higher-level application layer would have to do all the association work. However, it would be taking the rest of our work to its logical conclusion, and that's interesting and may be productive when we get to dynamic assembly. Rough reaction: Eve and Mike feel that Tim's paper is a good way to proceed and will result in high-quality XML. Jon notes that he likes the tone of discussion, but cautions that the people who *use* what we come up with will need very simple descriptions. Mavis thinks it jells, but wants to study the notes a bit more and cautions that the devil is in the details. Tim suggests that people work through their own examples and see how well it hangs together. - Next steps ACTION: Tim agreed to put together a draft position paper that all can review before the F2F (including ubl-comment!), with the plan that we will resolve all outstanding containership issues at the F2F. We won't continue to meet jointly next week. 3. NDR-only session begins: Acceptance of minutes of previous meeting 4 September 2002 http://lists.oasis-open.org/archives/ubl-ndrsc/200209/msg00008.html Deferred until we have quorum. 4. Schedule planning - Do we want to publish the NDR document before the F2F, or after? (Mavis gives regrets for the next two NDR meetings.) We don't see an imperative to get a new snapshot out very soon, although there are good reasons to do so very soon after the meeting. We will take that as our goal (unless we decide otherwise at the F2F). - Do we still want to skip the September 25 meeting? No! We'd rather meet on the 25th than on October 9th! So let's do it. - What items do we consider high-priority right now? Let's decide this next week, on the assumption that we'll consider late November to be our last chance to deliver new work. Below is our current plan of record; it's subject to heavy change. A+ Containership IN PROGRESS A+ Embedded documentation NEARLY DONE A Code lists DONE A Dates and times IN PROGRESS A Nested supplementary components IN PROGRESS A Identifier references and whether to pass content by reference A- Local vs. global elements B Updating guiding principles B Modnamver URN/schema location B Referencing of content, e.g. for attachments C Facets C Wildcards/open content C Nillability C Aggregation of similar information for XPath V1.0 addressing 5. Review open action items Let's reassess all these items when we decide what the top priorities are next week. Gunther: - Write content referencing paper. IN PROGRESS - Send date/time NDR snippets to Mavis. IN PROGRESS - With Arofan, prepare samples of how to handle second-tier attributes. IN PROGRESS - Bring the donkey to Burlington! Bill: - Update modnamver paper by September 11. - Start an email thread proposing a schema location solution. - Start a thread on RTs in aggregates and possible NDR document bugs in this area. Arofan: - NEW: Update the embedded documentation writeup. 6. Adjourn Adjourned z:25. -- 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