1. Roll call (till x:05)
Dave Carlson is no longer a voting member. (This isn't reflected on
the portal yet.)
Bill Burcham
Mavis Cournane YES
Mark Crawford
Fabrice Desr�
John Dumay
Matt Gertner YES
Arofan Gregory
Phil Griffin
Eduardo Gutentag
Eve Maler YES
Dale McKay
Joe Moeller YES
Sue Probert YES
Ron Schuldt YES
Lisa Seaburg
Gunther Stuhec
Paul Thorpe
We didn't achieve quorum, but we did achieve critical mass, and began
by discussing the code list position paper.
2. Acceptance of minutes of previous meetings (till x:06)
13 February 2002 telecon:
http://lists.oasis-open.org/archives/ubl-ndrsc/200202/msg00057.html
Deferred.
3. Adoption of agenda (till x:07)
Accepted by default (though we bounced around a lot).
4. Planning for March 11 deadline (till x:15)
ACTION: Arofan and Mark have to make progress on the tag structure
writeup as soon as possible! (Arofan, hope you feel better soon!)
- Feb 21-17: Ratify code lists, finish tag structure (relies on
Mark/Arofan update), sharing tag names/types
- Feb 14-20:
- Feb 21-27:
- Feb 28-Mar 6:
- Mar 7-9:
Remaining work (how to fit it into the weeks?):
Elements vs. attributes
Empty elements
modnamver
Sharing names when types are shared
Final edits
5. Action item review (till x:20)
Discussion of these was deferred.
ACTION: Arofan to join Mark in writing the tag structure material.
It needs to be written in a "normative" way (i.e., as instructions
ready to be put into the NDR document). Due February 20.
ACTION: Eve to take over the writing of the code list material.
ACTION: Bill and Mavis to champion the URI/URN issue and determine
an approach. Arofan suggested talking to Kelly Schwartzhoff about
this problem. In progress.
ACTION: Arofan, Tim, Gunther, and Lisa to develop example and code
with LC SC. This example should grow to illustrate the modnamver
proposal. To be sent to both LC and NDR SCs.
ACTION: Arofan to liaise with the CMSC on the issue of code list
extensibility and subsetting. In progress.
6. Code lists
Subsetting: It may be possible to subset code lists by reference to
an externally defined subsetting in some cases, e.g. in certain
industries. But in addition we might need to allow for subsetting
of an external code list by raw enumeration. Both of these, if
determined as actual requirements, will probably need to be accounted
for explicitly in the design of the context rules language.
Handling new versions of code lists: Very rarely, it does happen that
an old code gets defined to have a different meaning in a new version
of the code list. In these cases, the text in Section 3.1 of the
position paper would apply, but we probably don't have to worry too
much about backwards incompatibilities in external code lists.
Extension: What if we allowed the regular code field to contain anything
you want, and then have an additional field that's a boolean "custom
flag"? That way, you only have to check the one field for the actual
desired value, and if you case that it's custom or not, you can check
the flag.
Further regarding extension: Is it ever legitimate to extend a code
list by adding an ad-hoc custom value, when the code list itself doesn't
give "permission" for this? Can you do "un-premeditated extension"?
It appears that most, if not all, code lists will build in the escape
hatch, so maybe this isn't a concern. Sue notes that the escape
hatches are usually in order to cover legacy data. Should we force
all custom codes to somehow point to their own documentation, e.g.,
with a URI reference? The use of XML "namespace prefixes" here would
not be consistent with good XML practice, but it's intuitively quite
appealing.
Code lists and their management are sort of a "societal" problem. UBL
has the opportunity to help make the extension and growth of code lists
more tractable, but it has to avoid being swallowed up in the process.
New ACTION: Eve to update the code list position paper to reflect the
ideas brought up in the 20 Feb discussion, and disseminate it to the
LC SC before their meeting on 21 Feb.
7. Tag structure
- Oxford English (deferred, but we plan to support it)
- Delimiters between portions of a name (LC SC is looking at it)
- Non-letter characters (deferred)
- Singular and plural
- Articles, prepositions, etc. (deferred)
- Acronyms, abbreviations, and truncations:
We think we have the answer to this from last time. However, we
think that there may be some exceptions that really do creep in,
e.g., DUNS ID and UNDG (UN Dangerous Goods Number). And we'll
have to decide how to spell these: DUNSID or DunsId? We'll have
to keep a library of all these exceptions. We're leaning towards
spelling these all uppercase; of course the dictionary entry will
indicate the "parts" of the names in order to make everything
clear. This potentially has the same problem with ambiguity as
the decision to avoid delimiters in the markup names; we'll just
have to keep an eye on this.
- Top-level tag names
Matt's argument against a representation term of "Document" on the
top-level elements is that it's unnecessary. These elements are
distinguished as document elements in several ways: They're uniquely
at the top and they're global. Thus, OrderDocument could be just
Order.
"Document" has a technical meaning in XML. So even if you're
exchanging "enterprise" data or "person" data, it's still conveyed
in an XML document. In discussing the idea of a "Document"
representation term, do we mean it in the XML sense or in the
sense of a top-level business transaction document (which perhaps
isn't always the case)?
Ron is concerned that some transactions might involve partial
documents, e.g. asking a party for its identifying information and
having them respond with just a "party" block that isn't a whole
UBL document. Sue points out that there is a "master data"
exchange that involves a sharing of metadata, so that subsequent
transaction can just say "the usual, please" :-) without having
to specify the particulars by value.
The current list of planned UBL documents doesn't include these
"partial-document" document types. Do we have a problem with
exchanging instances of parts of the core library without a
governing document type? Or alternatively, should UBL be defining
more of these generic, small document types?
New ACTION: Ron to write up a description of the "partial document"
use case by next Monday for review by the NDR SC and LC SC. Sue
to forward Ron's NDR mail on this to the LC list.
We will try and resolve this before Barcelona.
7'. Sharing tag names/types and the "role" proposal
We briefly discussed Bill's role proposal. There was somewhat
of a sense that tag names should directly reflect facts about
the structural type, since making tag names match because of
"role" similarities is a much more subjective process. Also,
there was some resistance to and confusion about saying that a
header in an order has a "header" role. The concept of a "role"
is overloaded and possibly risky.
We briefly discussed whether it's a good idea to give "role"
semantics to the same element depending on its position (e.g.,
the first Party element in an order is the buyer and the second
Party element in an order is the seller). It's considered bad
XML practice to do this. It may be necessary sometimes to have
an attribute that allows you to set the desired role (e.g.,
<OtherParty Role="BillTo">...). But this still distinguishes
the role syntactically.
It was suggested that this need to allow for "extensible roles"
may need a design rule. We suspect that it's better to lock
down the role as a property term qualifier if you can, because
this gives you more validation power. But when you can't know
the role in advance, we may want a design pattern to solve this.
New ACTION: Matt to do a writeup on the "document design time"
(fixed vs. varying) assignment of roles.
8. Next steps
- Feb 21-17: Ratify code lists, finish tag structure (relies on
Mark/Arofan update), sharing tag names/types
9. Adjourn
Adjourned at y:43.
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com