[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 9 January 2002 UBL NDR meeting
1. Roll call (till x:05) Bill Burcham YES Doug Bunting Dave Carlson Mavis Cournane YES (x:15) Mark Crawford YES (left y:26) John Dumay YES Matt Gertner YES Arofan Gregory YES (left y:43) Eduardo Gutentag Eve Maler YES Dale McKay YES Sue Probert YES (left x:30) Ron Schuldt YES (left y:15) Gunther Stuhec YES Mike Rawlins YES Quorum reached 2. Acceptance of minutes of previous meeting (till x:06) 19 December 2001: http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00001.html Accepted. 3. Adoption of agenda (please send suggestions *before* meeting) (till x:07) Adopted. 4. Action item review (till x:09) ACTION: Mark to update tag structure position paper. Continued until Friday, January 11. ACTION: Mark to check with Mike on what the purpose of Section 5.4 is, and follow up with editorial changes to the NDR document as necessary. DONE. ACTION: Sue and Maryann to do some use case brainstorming offline. Continued until the F2F. ACTION: Arofan to create a new use case for instance constraint checking. DONE. ACTION: Dale to work on the legal issues text provided by Arofan and give it to Mark for inclusion in the NDR document. DONE. He had list problems; will send it to Eve for forwarding to the list. ACTION: Mark and Eduardo to propose a set of tag naming abbreviation rules before January 9. In progress (effectively DONE because we made a decision during this meeting). See also additional new ACTIONs below. 5. Current position paper champions, status, and priorities (till x:10) 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 Mike: - Code (enumerated) lists Dale: - Legal issues 6. Tag structure position Last time we agreed to Option 1: high structure. We are now considering whether to specify fully qualified structured names (option 1a) or abbreviated structured names (option 1b), and Mark and Eduardo have been working on a proposal for this. Here is a rough outline of what they're working on: Make global type declarations, and then local element declarations within those type declarations with names that are named with the property/rep terms and no object classes, and then define global elements that aggregate these local elements and are called xxxDetails. The local elements would "inherit" the object class of whatever aggregate element they're in (we need to get more precise about this). So AddressCity, AddressState, and AddressZip (etc.) would be locally defined in AddressType, and MailingAddressDetails and ShippingAddressDetails (etc.) would be of AddressType. You wouldn't need MailingAddressCity and so on. The plus is reuse. The minus is losing semantic clarity in tag names. We'd still have to decide whether MailingAddress and ShippingAddress are allowed to reuse AddressType as is, or whether they will be required to trivially derive MailingAddressType and ShippingAddressType. But this doesn't prevent us from making decisions on tag naming. This proposal doesn't affect global elements that are other than xxxDetails elements. Those global elements would have to have the object class/property term/rep term construction. One question about this is that it seems to make the most reusable elements local, and the least reusable elements global. Mark feels it's justifiable to drop the object class prefix for local elements, but not to drop it for global elements. "City" elements might be reusable in many locations: airport city, rental car drop-off city, etc. Do we need to be able to reuse a CityName element among address, airport, etc. constructs, or is it good enough to be able to reuse a CityType in constructing AddressCityName, AirportCityName, etc. elements? There is more than one level of abbreviation/reuse opportunity: MailingAddressCity, ShippingAddressCity, HomeAddressCity, RegionalAirportCity, CommercialAirportCity, etc. elements vs. AddressCityName, AirportCityName, etc. elements vs. CityName element There was agreement that CityName is an acceptable property term/ representation term pair, and also gives the most reuse. Arofan is concerned that we'll have too many levels of xxxDetails within yyyDetails. There will be some elements that don't end in representation terms that are, by definition, containers. His proposal is to have a rule for removing "Details" either in all cases but the innermost case of xxxDetails, or in 100% of all cases. However, we didn't adopt this. Mark notes that there may be some elements declared locally that need to have an object class in their name. For example, AddressNumber is better than Number, which is too generic and likely to be misinterpreted. This will be at the discretion of the Library Content SC. Root document elements shouldn't use the Details construction. They should use the Document suffix instead, which is a privileged case of Details. We achieved unanimous consent on adopting this whole proposal. We recognize that input from the Library Content SC or elsewhere may make us change our minds. We will also have the following issues to decide: - Do we use tag names based on ebXML naming conventions (option 1E) or tag names based UDEF's naming conventions (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? Some of these may have been obsoleted in part by the above decision. 7. Modnamver position See Bill's position paper: http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-burcham-modnamver-01.doc See also Mark's schema dependency flowchart: http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00007.html Arofan spoke in favor of Option 3, with the addition of the idea that extensions would explicitly be in a third namespace layer. For most context-driven derivations, we want to strongly encourage only UBL-namespaced elements to be used. Any contextualized schema derived by UBL means will need its own namespace because it will be defining derived types (and possibly new elements etc.). (Note that UBL will not be entirely vanilla; it will have a little bit of context baked into it.) Mike brought up the idea of an Option 0: don't use namespaces. The main technical reason for namespaces is to avoid name clashes. Another reason has to do with performance -- you can use them to do lazy loading of individual namespaces. The xCBL experience (without namespaces) has shown that namespaces would have been better, though till now the tools support has been spotty. There are two places you could put version information: in the namespace name and in-band (in the document instance as, e.g., an attribute on the root element). It should theoretically be possible to map the same namespace URI to successive versions of a schema, but in practice the tools don't support this mapping very well. However, even if we put the version in the namespace URI, it might also be useful to duplicate the version information in-band. Different application levels will benefit from each. We settled on the idea that the core namespace should have a version and each functional area should have a version. At the third ring, extensions can point to whichever versions they want. If the core revs, we're not sure all the functional areas should have to rev. We liked the notion of a major-minor versioning scheme, where a minor revision is backwards compatible (e.g., adding a new optional element) and a major revision is backwards incompatible (e.g., adding a new required element or removing an element, which breaks existing documents, or changing a default value, which changes the legal contract agreed to by trading partners). How would we indicate the compatibility between pairs of the core and individual functional namespaces? We could say that the major number of a functional namespace must be greater than or equal to the core, because any backwards-incompatible change to the core should force a rev of the functional namespace. 8. Next steps (till y:59) The next meeting will start one hour later than usual, and go for one hour. Mark will run the call. We will focus on modnamver and specific goals for F2F #2. Spending about half a day on use cases at the F2F will be a good idea. ACTION: Bill to update the modnamver position paper by Friday, January 11. ACTION: Eve to make the dial-up arrangements for next week's meeting and send out an agenda. 9. Adjourn Adjourned at z:00. -- 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