Thanks to Mark for chairing the meeting and taking the minutes!
Eduardo, please note the ACTION below that the SC hoped you would take
on. Can you positively acknowledge this?
Mike, are you able to take an action to revise the code list position paper
to reflect the additional issues that have been raised so far on the list
and in the recent calls?
We need to make sure our position papers etc. are kept up to
date. Otherwise, our decisions won't mean anything to people who are not
on the SC...
Thanks,
Eve
Call convened by Mark Crawford at 11:00 EST on 6 February 2002.
1. Roll call (till x:05)
Bill Burcham No
Doug Bunting No (note: has dropped off the NDR SC)
Dave Carlson No
Mavis Cournane Yes
Mark Crawford Yes
Fabrice Desr� Yes
John Dumay No
Matt Gertner No
Arofan Gregory Yes
Phil Griffin Yes (left at y:40)
Eduardo Gutentag Yes (x:09) (left at y:??)
Eve Maler No
Dale McKay Yes
Joe Moeller No
Sue Probert Yes
Ron Schuldt Yes
Gunther Stuhec Yes
Mike Rawlins Yes (feft at x:43)
Paul Thorpe Yes
Quorum reached.
2. Acceptance of minutes of previous meetings (till x:06)
23-25 January 2002 F2F:
http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00050.html
30 January 2002 telecon:
http://lists.oasis-open.org/archives/ubl-ndrsc/200201/msg00052.html
Both adopted.
3. Adoption of agenda (till x:07)
Adopted as amended (added new item #8).
4. Action item review (till x:09)
ACTION: Mark to update tag structure position paper.
Status: Pending.
ACTION: Sue and Maryann to do some use case brainstorming offline.
Status: Pending.
ACTION: Bill and Mavis to champion the URI/URN issue and determine an
approach.
Status: Mavis has done research. Bill incorporating into document
and should be done shortly.
ACTION: Everyone to critique modnamver UML diagram.
Status: All to review diagram this week and provide feedback by email
before next week's call.
ACTION: Arofan, Tim, and Lisa to develop example based on current
thinking in library group and leveraging NDR stuff to see if it can
work. Anticipate certain part of the example will be ready for F2F
presentation. (Was this about modnamver?)
Status: January F2F has obsolesced original effort. Arofan is
working on new version based on F2F and LSC input. Working with
Gunter to incorporate into tools group and code. Should have by end
of this week.
ACTION: Namespace issues need to be raised to library committee for
joint resolution. (Needs owner.)
Status: Ron to contact Eve to clarify what action is.
ACTION: Gunther will finish some modifications to the elements vs.
attributes position paper and will post it by January 31.
Status: Posted 2/5/02.
5. Planning for March 11 deadline (till x:30)
- Feb 6: Start code lists, start elements vs. attributes
- 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
6. Code list discussion (till y:15)
Position paper is at:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-Rawlins-codelists-01.doc
What (very roughly) are our use cases driving our choice of
solutions? See this message for two alternative views:
http://lists.oasis-open.org/archives/ubl-ndrsc/200202/msg00000.html
What are our requirements around these areas, and in each case, do
internal vs. external code lists have different requirements?
- Should we support enumerated code lists
o seems to be general agreement that we support enumeration of some
sort, with some consensus that lists would be in separate
namespace
- Validation of code list values through XSD vs. by other means
o some discussion, but no clear resolution. Must provide a minimum
level of validation at server level, if parsed, option to validate
only that it is a member of an enumerated list, or custom code.
Application validation bears the bulk. Can't do this on field by
field basis.
- Efficiency of expression in the instance
o Open for further discussion
- Extensibility of code lists and when it is allowed/disallowed
o Belong to context group. No disagreement to allow extensibility.
Context group needs make provisions for this.
- Subsetting of code lists
o Belongs to context group. No disagreement to allow subsetting of
code lists. context group needs to make provisions for this.
ACTION: Arofan to liaise with the CMSC on the issue of code list
extensibility and subsetting.
- Inclusion of dynamic sets of code list values
o Arofan proposal for separate namespace supports this. Needs
further consideration.
- Identifying, documenting, and versioning the code list used
o See below.
- Combining values from internal and external code lists
o Maybe handled by custom code list. Can't be "and", must be
either/or. Tied into customization decision.
Additional discussion points:
o Should we offer full blown validation through schema, but also
enable subsetting validation at the application level
o Always the option to support EDI concept of ZZ-Any
o Concern that we cannot do proper subsetting on just a string
without being overly complicated and error prone
o One type of usage in a code list when the encoded data is simply
information passed on to the application. Another class of usage
when the business application keeps track of inventory in units of
each, and I have customers who order by case, I do conversion
routine from unit of 1 to number of case so value of code must be
validated to ensure accuracy and application supportability. One
person thinks that if we do validation, then we can't do strings.
o If you are going to ask why validate codes - then why validate
anything. On the other hand, many in EDI simply turn off code
validation capabilities at the server level.
o Versioning is issue. Possibility is to put enumerated code lists
in separate namespace that does not have versioning. Application
could validate on version of the namespace. Code lists would have
to be taken from other owner lists as well as those developed by
UBL and turned into enumerated lists. Who would pay for this
work, and who would maintain this work? The namespace would not
provide the versioning mechanism (different than our namespace
versioning decision), the enumerated list is versioned. Whose
codes do we use? Combination per xCBL (EDIFACT and X12). Much
discussion on cost and workload and impact on SME's. Much
discussion on what all needs to be done to support concept.
Possibility to work with CRM TC. Arofan believes that we can
maintain with minimal effort through leveraging work of X12 and
EDIFACT and ISO and others. Also if we allow customized code
lists then it will give users flexibility.
o Arofan envisions fewer code lists in UBL than in EDI because you
don't need to use codes to explain what you mean in every
instance.
o Need permanent group to manage code lists.
Stopped discussion at y:21.
7. Element vs. attribute discussion (till y:50)
Position paper is at:
http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-stuhec-elemvsattrib-01.doc
It seems that this decision has a "taste" component as well as sound
technical rationales. Nonetheless, what are the requirements
around:
- Extensibility
o argument that attribute/element pairs is cleaner than containers
for paired elements
o Point that if multiple attributes and there are hierarchical
requirements, the use of attributes breaks this.
- Instance readability
o Gunther believes codes as attributes are more readable
o Eduardo believes value judgment
o Mark, Arofan, and Matt don't agree.
- Semantic clarity (compatibility with the data dictionary
framework)
o Arofan does not believe any difference.
o Eduardo says there is more control of elements.
o Mark argues attributes are not as clear.
- Additional discussion:
o Question - Are we naive that CCT table and its properties are
always one to one. Answer - Don't believe there is/will be a one
to one.
o Gunter has articulated some set of rules for specific attributes
to be used.
o Dale believes that use of attributes at leaf precludes looping.
o Point made that use of attributes precludes extension. I.E.
Boolean used as attribute only enables yes or no, not maybe.
o Architectures may be special case where values in attributes
support accessibility.
o Everyone agreed that if we did decide to use attributes at some
level, we provide specific instances/restrictions where they would
be allowed.
o No disagreement that UID's as attributes would be useful
o No disagreement that presentation type attributes i.e.
accessibility would be useful
o No disagreement that document level attributes would be useful
o Generally no disagreement that using attributes at the leaf level
to restrict extension would be useful. However many reserve
judgment on this.
o Lot of contention around proposal to use attributes at leaf level
to contain supporting properties. Need to have group review
Gunter's latest paper re this, and need champion to build examples
arguing against.
ACTION: Ask Eduardo to create a proposal for using attributes at the
leaf level.
Finished at y:47.
8. Discuss Library Spreadsheet (New agenda item)
Library subcommittee noticed discrepancy in use of naming rules. They
believe we have not provided details. Also concern about need for
separators between name parts.
ACTION: Arofan, Gunter and Ron and Sue to look at LCSC spreadsheet to
determine source of LCSC's concern about naming rules.
9. Action items and next steps (till y:59)
Not addressed.
10. Adjourn (z:00)
Adjourned.
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com