[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 12 December 2001 UBL NDR meeting: TAG STRUCTURE
1. Roll call Bill Burcham YES Doug Bunting Dave Carlson Mavis Cournane Mark Crawford YES John Dumay YES Matt Gertner Jack Gager Arofan Gregory YES Eduardo Gutentag YES Eve Maler YES Dale McKay YES (x:29) Sue Probert Gunther Stuhec YES Mike Rawlins YES (x:45) Marion Royal yes (non-voting) Ron Schuldt yes (non-voting) Quorum of 8 not reached as of x:06. We proceeded informally until x:29. 2. Acceptance of minutes of previous meeting: 5 December 2001 meeting: http://lists.oasis-open.org/archives/ubl-ndrsc/200112/msg00012.html Accepted. 3. Adoption of agenda Adopted. 4. Action item review NOTE: There are other outstanding action items that we didn't need to focus on in today's session. ACTION: Arofan/Sue/Lisa to provide the xCBL naming guidelines (and all the other xCBL guidelines!). To be sent today (it's rough). ACTION: Mark to update naming position paper with our suggestions (including email suggestions). Has a dependency on Arofan providing examples and UDEF information. Continued. ACTION: Dale and Sue to work up tag structure examples and examine them in light of the two "PatientParty" circumstances listed in the November 28 minutes. Other interested parties are Mark, Arofan, Eduardo. DONE (by Mark!). 5. Make decisions on tag structure: Current status: Mark matched up the Library Content SC work on OrderSummary with the proposed Option #1 from the tag structure position paper and with the current xCBL names: http://www.oasis-open.org/committees/ubl/ndrsc/input/Tag%20Naming%20Example.doc Because xCBL uses SOX, which equates "types" with elements, it has deep nesting that would go away with the use of XSD. In Mark's sample instance, he did elide the object name in some cases (e.g., ExchangeRateReferenceIdentifier contains ReferenceDetails, not ExchangeRateReferenceIdentifierDetails, and ReferenceDetails contains ReferenceNumber and ReferenceDate). This allows ReferenceDetails to be potentially reusable. If ReferenceNumber and ReferenceDate were just called Number and Date, Mark feels that they become ambiguous and so they need the "Reference" prefix. However, there is a principle behind the choice to elide other prefixes that he feels the Library Content SC can apply as they go about their BIE work. Eduardo noted that ambiguity can be resolved by looking at the ancestry of an element as well as by looking at its name. Some of the tradeoffs: - Do we want the most elegant way to create instance documents? - How much do we care about verbosity? - Do we want a standard vocabulary that eliminates semantic ambiguity? Ron Schuldt introduced himself. He's with Lockheed Martin's IT organization. He has worked with the CommerceOne people in mapping xCBL to the aerospace industry's EDI implementations. He's the co-chair of an industry group that is trying to figure out the metadata that spans/overlaps technical document structures. In the CALS work, the Universal Data Element Framework was developed in the late 80's-early 90's. ISO 11179 was ultimately adopted by UDEF. A DoD specification developed "property words" that ultimately got adopted, approximately, as ebXML's "representation terms", with some becoming quantities. Ron presented UDEF to the people developing MIL-STD-2549, and they adopted UDEF in the mid-90's. At XML 1999, Ron proposed that UDEF be adopted by ebXML. UDEF has objects and properties. The last word is always the property (ebXML representation term). The objects are things like "Enterprise". Many of these map nicely to the ebXML context drivers. There is a documented procedure for applying the UDEF rules. Sometimes you have to have two object words in the name, perhaps because with XML you have complex aggregate structures containing other similar structures. Only leaf nodes have UDEF UIDs (universal identifiers). UDEF appears to be more verbose than our Option #1. The specific proposal being made by Ron is to use UDEF UIDs to identify UBL leaf nodes. He doesn't really think it's necessary for UBL to adopt the very long UDEF names as element names, though putting the modifiers before the property words would make the names a bit more natural. Mark noted that we need to consider the structured UDEF UID issue separately. He was concerned about using a *structured* ID, which has not been adopted by ebXML. (The registry information model spec does address this issue; it says that IDs can't have any semantics baked into them, while a structured ID does have this, and it has to be possible for the registry to generate a random new number.) Mark expressed concerns that adopting UDEF at all would make us incompatible with UN/CEFACT. However, Arofan noted that it's possible to have multiple IDs. Eve pointed out that it's easier to attach IDs (single or multiple) to leaf elements than to attributes. Ron described the benefit of structured IDs as being the ability to keep all the legacy systems and naming conventions as they currently are, while mapping to a "hub" system of intelligent identifiers. Outstanding issues: - Do we use highly structured names (option 1) or slightly structured names (option 2)? - Do we use fully qualified structured names (option 1a) or abbreviated structured names (option 1b)? How much abbreviation do we want to allow? - 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? ACTION: Everybody to discuss this on the list! ACTION: Everybody to review the latest NDR document! http://www.oasis-open.org/committees/ubl/ndrsc/drafts/draft-ublndrsc-designrules-04.doc 6. Adjourn Adjourned at y:06. -- 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