ubl — archive

[ubl] Fwd: [ubl-ndrsc] Minutes for 2 January 2002 UBL NDR meeting

From: Eve Maler
To: [email protected]
Date: Wed, 02 Jan 2002 13:23:00 -0000

If you care about tag names and "modnamver" (modularity, namespaces, and versioning), you should take a look at the NDR subcommittee's latest minutes below. You can find all relevant position papers on our portal: http://www.oasis-open.org/committees/ubl/ndrsc/ >Date: Wed, 02 Jan 2002 13:02:39 -0500 >From: "Eve L. Maler" <[email protected]> >Subject: [ubl-ndrsc] Minutes for 2 January 2002 UBL NDR meeting >To: [email protected] >List-Archive: <http://lists.oasis-open.org/archives/ubl-ndrsc> > >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