Re: [ubl-ndrsc] Minutes for 6 February 2002 UBL NDR meeting

[Mike Rawlins <mike@rawlinsecconsulting.com>]

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