Folks,
I missed enough of the discussion on the call, and got far enough behind on the e-mail
discussion that I feel challenged to do an adequate job to update the code list
position paper. If there's anyone who wants to take it over, I'll be glad to do a
handoff. If not, I'll see what I can do to update the paper next week based on my
limited understanding of some of these points in the minutes.
Cheers,
Mike
"Eve L. Maler" wrote:
> 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
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com