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