[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 2 January 2002 UBL NDR meeting
1. Roll call -- quorum is 9 1a vs. 1b straw poll Bill Burcham YES (x:30) 1b Doug Bunting YES (left y:00) Dave Carlson Mavis Cournane Mark Crawford YES 1a (needs to see rules for 1b) John Dumay YES 1a Matt Gertner YES (y:06) Jack Gager Arofan Gregory Eduardo Gutentag YES 1b Eve Maler YES 1b Dale McKay YES 1a (needs to see rules for 1b) Sue Probert YES 1a (needs to see rules for 1b) Ron Schuldt YES 1a (needs to see rules for 1b) Gunther Stuhec Mike Rawlins Quorum not reached as of x:10; we proceeded informally. We reached quorum at x:30. 2. Acceptance of minutes of previous meeting 19 December 2001: http://lists.oasis-open.org/archives/ubl-ndrsc/200112/msg00049.html Accepted (x:30). 3. Adoption of agenda Agenda adopted. 4. Action item review ACTION: Mark to update tag structure position paper. ACTION: Mark to check with Mike on what the purpose of Section 5.4 is, and follow up with editorial changes as necessary. Mark is waiting for Mike to respond. ACTION: Sue and Maryann to do some use case brainstorming offline. ACTION: Arofan to create a new use case for instance constraint checking. Addition new ACTIONS appear below. 5. Current position paper champions, status, and priorities ACTION: Dale to work on the legal issues text provided by Arofan and give it to Mark for inclusion in the NDR document. 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 (A-priority; goes with modnamver) Mike: - Code (enumerated) lists Dale: - NEW: Legal issues 6. Tag structure position Decision process: Eduardo is concerned that at some level, "naming judgment" is being applied anyway, which means that there is always a place where you make an arbitrary naming decision. He also distinguishes compound names (having multiple words) from structured names (where there are different parts of names with different roles). He wants to ensure that our element names are not too long, and that we don't perpetuate the myth that XML versions of EDI have to replicate the "flatness" of EDI data. All are agreed that reuse of XML elements is desirable, and thus that it's not a good idea to lock down all elements to one "structural context" (i.e., parent element). Ron mentioned the notion of an explicit wildcard for parts of a structured name that have been elided. For example, if you chop off the object class that would have clarified the "thing" that a DeliveryDate applies to, you could name your element <WildcardDeliveryDate> or <AnyDeliveryDate> or something. - Do we use highly structured names (option 1) or slightly structured names (option 2) or unstructured names (option 3)? Option 3: With the caution that some businesses will want to create aliases for canonical names, which is not covered by this decision, we don't support totally unstructured names. Option 2 vs Option 1: With the caution that the choice of strong structure is in service of naming the *semantics* and not necessarily the *elements*, we agree with Option 1. - Do we use fully qualified structured names (option 1a) or abbreviated structured names (option 1b)? How much abbreviation do we want to allow? It's theoretically possible to chop off some representation terms because their function is replicated by datatypes in the schema document that governs the business document. However, no one supports this because we're dubious that the PSVI will always be available. It's just easier to attach this information to the element name. We're more confident about chopping off prefixes, namely, the object class portion. The reason for this is precisely to allow the element to be reused in multiple parent elements, and therefore implicitly take on multiple "object classes". In any case, the simple "ancestry" XPath will always let you address the element in all of its structural contexts. Mark noted that only leaf-level elements have the tripartite structure in his example. However, we think that some leaves are too trivial for this (e.g., ApartmentNumber in an address). Also, Mark is concerned that the "reuse" we desire in doing abbreviation may not be achievable. Option 1a vs. Option 1b: We can't decide until we develop some proposed rules for abbreviation. ACTION: Mark and Eduardo to propose a set of tag naming abbreviation rules before January 9. - Do we use ebXML/11179-style names (option 1E) or UDEF-style names (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? Deferred. 7. Modnamver position See Bill's position paper: http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-burcham-modnamver-01.doc In reviewing this paper, we realized that the local vs. global elements position is intimately tied up with this because if we choose to use all-local elements, the decision about how to handle namespaces might become a lot simpler. Dave owns this paper: http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-carlson-localvsglobal-01.txt We rejected Option 1 and Option 2 because they're too simplistic and have obvious problems. Option 3 results in exactly two levels, while Option 4 allows intermediate levels to be introduced, in order to manage the "crowdedness" of the original two-level namespaces. Option 3 vs. Option 4: This is a little bit like the difference between fully structured names and abbreviated (or slightly structured) names; if you have to make any judgment calls about when to create additional namespaces, we'll need to make rules/guidelines about this in order to retain consistency. An alternative is to allow more than one included schema module file per namespace. Matt noted that the 7 +/- 2 doesn't seem to apply to schema modules as much as to memorizing telephone numbers, and that it seems fine to have (e.g.) a dozen or more types per module. We discussed the "semantic difference" between importing and including modules. Bill's current paper uses "root schema" as shorthand for a schema module that has its own namespace and gets imported (not included). Eve proposed to accept Option 3 provisionally until we start feeling uncomfortable with the "size" of any namespaces/files. At that time, we can decide what to do. We weren't able to decide this yet, but we're making progress. 8. Next steps - Plans for January 9 and 16 meetings ACTION: Eve to make arrangements for these meetings. We will meet for two hours on the 9th and for one hour (starting an hour later than usual) on the 16th. The same phone number from today will be used. Mark will run the meeting on the 16th. Topics for the 9th: Finish tag structure and continue discussing modnamver. - Goals for F2F #2 in Menlo Park At least Ron, Dale, and John won't be at the F2F. At a minimum, we hope to decide on all the position papers we have published so far. 9. Adjourn Adjourned at z:00. Happy new year, everyone! -- 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