[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-ndrsc] Minutes for 18 September 2002 UBL NDR SC meeting
PLEASE NOTE: We ARE meeting next week! We un-canceled the September 25
meeting. We will try to keep it under ONE HOUR.
Minutes for 18 September 2002 UBL NDR SC meeting
1. Roll call (quorum is 8)
Bill Burcham YES
Mavis Cournane no
Mark Crawford YES (joined y:40)
Fabrice Desré no
Arofan Gregory no
Jessica Glace YES (joined y:40)
Michael Grimley YES
Eduardo Gutentag YES
Eve Maler YES
Sue Probert YES
Lisa Seaburg YES
Gunther Stuhec no
Paul Thorpe YES
Kris Ketels no
Quorum not achieved as of x:42. We proceeded informally. Quorum
achieved at y:40.
2. Acceptance of minutes of previous meeting
11 September 2002
http://lists.oasis-open.org/archives/ubl-ndrsc/200209/msg00032.html
Accepted.
3. Adoption of agenda
Adopted.
4. Schedule planning and prioritizing
We assume that our "proactive" work will conclude by the November
F2F.
We discussed what to do with undone work at the end of the year:
Does the NDR document say "These will be fleshed out in the fullness
of time", or does it say "These will be undertaken in a Phase 2 of
this work next year"?
ACTION: Eve to get this issue on the F2F agenda.
Each of us listed up to five items that we think are most important:
Sue: nested SCs, naming rules wrt CCTS V1.85
Lisa: date/time, code lists, facets, containership, local vs. global
Eduardo: containership, nested SCs, modnamver, referencing strategies,
date/time
Eve: code lists, containership, local vs. global, CCT handcrafting,
incorp'ing all decisions/issues
Bill: CCTS 1.85 alignment, referencing strategies
Michael: containership, local vs. global, code lists, date/time,
embedded doc'n
Paul: local vs. global, nested SCs, code lists, ASN.1 schema
Totals:
CCT module work (includes nested SCs, upgrading to 1.85 ...): 5 votes
Local vs. global: 4 votes
Code lists: 4 votes
Containership: 4 votes
Date/time: 3 votes (lump this in to the CCT module work)
Referencing strategies: 2 votes
Naming rules wrt CCTS V1.85: 1 vote
Facet outreach (helping LC SC): 1 vote
Modnamver: 1 vote
Embedded doc'n: 1 vote
ASN.1 schema: 1 vote
Things that didn't get mentioned that we don't want to lose:
Updating guiding principles
Wildcards
Nillability (Jessica)
Instance constraints (Lisa)
Our new prioritized list:
A Local vs. global
A Code lists
A CCT module work (work on this at the F2F)
A Containership (work on this at the F2F)
B Referencing strategies
B Naming rules wrt CCTS V1.85
C Facet outreach
C Modnamver
C Embedded documentation
C ASN.1 schema
C Updating guiding principles
C Wildcards
C Nillability
C Instance constraints
Bill also noted that it would be helpful to immediately start
submitting CC discoveries to the UN/CEFACT folks. Sue reported
that work is under way to accept such input.
Today we will discuss local vs. global and code lists. Next week
we will plan our F2F agenda and review the NDR document against
previous meetings' minutes.
5. Review open action items
Gunther:
- Write content referencing paper.
- Send date/time NDR snippets to Mavis.
- With Arofan, prepare samples of how to handle second-tier
attributes.
- Bring the donkey to Burlington!
Bill:
- Update modnamver paper. (C)
- Start an email thread proposing a schema location solution. (C)
- Start a thread on RTs in aggregates and possible NDR
document bugs in this area. CANCEL
Arofan:
- Update the embedded documentation writeup.
Eve:
- Suggest new F2F agenda item to Jon, as noted above.
6. Work on top one or two items discussed in agenda item #4
6. a. Local vs. global
We are just waking up this issue now; we'll try to decide it at the
F2F, when Fabrice will be present.
We need to assess the three choices (local unqualified, local
qualified, and global) against XSD derivation and see how the
resulting schemas and instances look.
We need to look at the following resources to help us understand
what's at stake:
Fabrice's position paper:
http://www.oasis-open.org/committees/ubl/ndrsc/archive/p-desre-localvsglobal-01.pdf
Bill's role model paper:
http://www.oasis-open.org/committees/ubl/ndrsc/archive/draft-burcham-rolemodel-04.pdf
Global elements would require that some of our sets of elements with
the same name ("ID") would have to get different names.
6. b. Code lists
Eve's message of last Friday listed several issues we can consider
on the code list draft:
http://lists.oasis-open.org/archives/ubl-ndrsc/200209/msg00035.html
*The need for attributes for the supplementary components
Mark thought that, in practice, it won't be safe to just use the
namespace as a semantically clear indication of the code list being
used. Bill pointed out that we'll have a proliferation of code types
and code elements along the version axis, which may be okay -- it's
sort of like static type checking as opposed to dynamic type checking
(i.e., you have to check the versionID attribute before knowing how
to understand the value).
Sue and Mark mentioned examples of the same code list being published
for pay by ISO and for free by UN/ECE, meaning that they're really
considered different lists and would have different agencyIDs,
versionIDs, etc.
Our decision on this issue is to RETAIN the current structure, with
attributes being required.
*Whether to encourage/require foreign inner code elements
We had originally rejected the possibility of using foreign code
elements because of our local unqualified element decision. But
since we're importing someone else's type, they can define their
own foreign (to us) subelements anyway, and we would *have* to use
them in namespaced fashion (assuming they're namespace-qualified,
of course!).
Eve's motivation in bringing up this idea is that it would make the
code list schema module more "saleable" to all consumers, not just
UBL (which is unusual in trying to define a standard vocabulary with
unqualified elements).
Sue noted that unit of measure codes and currency codes are the ones
on which Commerce One receives the most inquiries.
Bill and Eduardo were in favor of not telling code list agencies to
define elements in addition to types, Eduardo on the grounds that if
popular application support for elements grows, then UBL won't be
able to take advantage of that software in its use of the types
only. Bill's reasoning was that we shouldn't rehash our local vs.
global decision, and it's consistent with that decision to require
only code types.
In the absence of support for reopening this, our decision is to
RETAIN the current understanding that we just want code list agencies
to define types. However, it's okay for the code list document to
mention the non-normative possibility of defining elements as long
as it doesn't send mixed messages to people who are striving for
conformance to our spec.
*Inner vs. outer code elements
Eve decided, after all, not to champion this issue, so we dropped it.
An outer code element is needed for XSD reasons (the neat and clean
extension of its type by trading communities) and for ebXML reasons
(it represents the true BIE; the inner code elements are just XML
"mechanism").
7. Adjourn
Adjourned at z:20.
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 883 5917
XML Web Services / Industry Initiatives eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC