[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 13 February 2002 UBL NDR meeting
1. Roll call
Doug Bunting and Mike Rawlins are no longer voting members.
Lisa Seaburg is now a full voting member.
Bill Burcham YES
Dave Carlson
Mavis Cournane YES
Mark Crawford YES (x:17; reached quorum)
Fabrice Desré YES
John Dumay
Matt Gertner
Arofan Gregory YES
Phil Griffin
Eduardo Gutentag YES (left y:50)
Eve Maler YES
Dale McKay YES (x:50; left y:50)
Joe Moeller YES
Sue Probert YES
Ron Schuldt
Lisa Seaburg YES (x:22)
Gunther Stuhec YES (x:58)
Paul Thorpe YES
Marion Royal YES (y:22; observer; left x:55)
Quorum not reached as of x:06. We decided to start informally. We
reached quorum at x:17.
2. Acceptance of minutes of previous meetings
6 February 2002 telecon:
http://lists.oasis-open.org/archives/ubl-ndrsc/200202/msg00020.html
Eduardo noted that he was volunteered for something inappropriately.
It was pointed out that the action was to *ask* him to do something,
not for *him* to do something. :-)
Minutes accepted once quorum was reached.
3. Adoption of agenda
4. Planning for March 11 deadline
- Feb 7-13: Finish tag structure/data dictionary issues and code
lists
- Feb 14-20: Finish elements vs. attributes and Empty Elements
- Feb 21-27: extension and MODNAMVER and Top Level Element Naming
- Feb 28-Mar 6: Qualified vs unqualified and Name/Type Sharing
- Mar 7-9: Final NDR document/position paper edits
We need to properly document the decisions we've made to date, and
make sure it works for the LC SC. The NDR document needs new content
reflecting our "tag structure/local vs. global/relationship to CC"
work.
New 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.
New ACTION: Eve to take over the writing of the code list material.
5. Action item review
ACTION: Mark to update tag structure position paper. Now an action
for Arofan and Mark both.
ACTION: Sue and Maryann to do some use case brainstorming offline.
Action dropped because it's been overtaken by events.
New ACTION: Eve to ask Dave if he wants to drop back to observer
status.
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 (till y:15)
The ur-issue is: Should code lists be validatable? Some are, but
some aren't. For example, we might not want to validate zip codes
or location codes, but then they're not enumerable in practical
terms. A potential candidate for enumeration (by whatever means)
needs to have a closed set of codes, where the set might change
only every few months. However, this would include zip codes, and
we still don't think it's reasonable to enumerate zip codes.
Are most SMEs are going to be using more than a limited subset of
most code lists in their document creation process?
What are the costs of letting a "bad code" get through to the
application? Considering that the application has to know about
a code in order to take the appropriate action on encountering it,
what is the real consequence of letting applications do their own
validation?
It's possible to get "partial validation" in XSD by just doing
pattern matching. In this case, extension and subsetting is a lot
less complicated procedure, and "code list identification" wouldn't
be needed.
The use of XSD validation is only one thing standing in the way of
people who want to abuse the ability to make their own codes. They
will still do "code abuse."
xCBL has what may be a good starter set of code lists. We could draw
the dividing line there, or much sooner (fewer lists). There is a
considerable cost for each "internal" code list because we have to
maintain it, track its mapping to external ones, etc., so perhaps we
should minimize the creation of internal code lists.
Would it be possible to ask external organizations to produce and
maintain schema modules that define enumerated types for their codes?
The UN is the primary one. If they get around to doing this, at that
time we could consider using them for run-time validation.
Mark's proposal: We should use external code lists as much as
possible, and in those cases leave validation and subsetting up
to the application (except perhaps for pattern matching). We
should create our own validatable code lists sparingly. This is
a short-term solution. In the long term, we would have the option
to use validatable forms of the external code lists provided by
external organizations.
Formal vote: Arofan votes no, Bill and Lisa abstain.
We noted that, in the few cases where UBL does need internal code
lists, we should try to start with xCBL's. This needs to be discussed
further.
Identifiers for a whole code list:
==================================
- Requirements:
. Refers unambiguously and uniquely to one list
. UBL can assign (for internal code lists)
. Others can assign (for external code lists)
. Extension designers can assign without clashing
UBL needs a list of code list identifiers. The items in the list
need to be unique and unambiguous. But they can be mapped to the
formal names of the relevant external code lists (e.g., the ISO
ones) -- they don't have to be identical to the ISO one.
If we define enumerated types, these types are in some XML namespace.
We could play games with defining such types in a variety of different
namespaces. We could "version" the types by putting attributes in
the schemas somehow.
- Options:
1. URI reference as a "code list namespace name", not necessarily
resolvable on the web
2. Ad hoc (e.g., ISO number, UBL descriptive keyword, etc.)
3. Let people use whatever names their system recognizes
4. Other
We didn't discuss any of the other code list issues below.
Versioning a whole code list:
=============================
- Requirements:
. Need to keep the identifier the same when version changes?
- Options:
1. Put version in identifier
2. Keep identifier the same over time but provide separate
version info in markup
Maintenance of external code lists:
===================================
- Requirements:
. UBL will need "machine-readable" form of these
. Can UBL afford to maintain?
. Are there legal issues around this?
- Options:
1. UBL maintains
2. External groups maintain, through arrangement if necessary
3. No machine-readable form of these
4. Other
Provision of a code in markup:
==============================
- Requirements:
. Ideally can be checked to be a valid code
. Can fully but succinctly document the code's meaning
. Do users ever need the "zz" escape hatch capability?
. Possible codes should be subsettable based on context
. Do codes need to be extensible based on context?
. Possible codes should be extensible by extension designers
. Performance requirements in validation?
. Performance requirements in processing?
- Options:
1. Enumerated list of string values
a. With "zz" option
b. Without "zz" option
2. Unrestricted string
3. String with pattern-matching restrictions
4. One unique UBL element per code
5. String from code list validated at run time
6. Other
Style of code naming:
=====================
- Requirements:
. Ideally should match the prevailing industry code list usage?
. Needs to be compact and concise?
. Needs to help instance readability?
. Needs to provide semantic clarity?
Options:
1. Alphanumeric
2. Numeric
3. Full spelling
4. Combination
5. Ad hoc
6. Other
7. Tag structure (till y:50)
Position paper:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-Crawford-tagstructure-01.doc
- Getting the tag structure decisions documented and bought into
Other issues:
- Oxford English
We should rubber-stamp this next time.
- Delimiters between portions of a name
These may be needed only in the dictionary and not in the tag names.
If there's ever a situation wherein there are two dictionary entry
names that could resolve (once delimiters are removed) into the
same tag name, we may have to reexamine it. Then again, it may be
possible to deal with these on a case-by-case basis and not have to
add delimiters to tag names in a blanket fashion. This issue is
currently being examined by the LC SC folks.
- Acronyms, abbreviations, and truncations
We may want to discuss selectively allowing a few acronyms (like
"ID" instead of "Identifier"!). But "PO" for purchase order is
not good practice.
- Non-letter characters
Is "enumeration" (like AddressLine1, AddressLine2, etc.) a good
practice? It would be nice to really restrict numbers.
- Singular and plural
- Articles, prepositions, etc.
These are probably pretty good rules.
- Recommendation for maintenance of RT list
Not discussed.
8. Next steps
We will try to finish "tag structure" (the big picture) and code lists
next week. We will need to examine proposals in email.
9. Adjourn
Adjourned z:04.
--
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