← Prev in month ← Prev in thread
Next in thread → Next in month →

[ubl-ndrsc] Minutes for 12 December 2001 UBL NDR meeting: TAG STRUCTURE

From
Eve Maler
Date
2001-12-12T13:09:00+00:00
ID
Thread
[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
← Prev in month ← Prev in thread
Next in thread → Next in month →