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

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

"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?

I believe there might be an error in the minutes; I have no recollection
of volunteering for this. This may be a voice-identification issue.

Talking about confusion, I have a problem with the use of the term "leaf".
For me that refers to a non-branching element, that is an element with
attributes and data, but with no further elements contained in it. Many
people seem to use "leaf" with a rather different meaning. Could someone
explain to me what do they mean by "leaf"?

Eduardo

> 
> 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

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
XML Technology Center          |         Phone:  (510) 986-3651
Sun Microsystems Inc.          |