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