OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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



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:

     30 January 2002 telecon:

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

    What (very roughly) are our use cases driving our choice of
    solutions? See this message for two alternative views:


    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

    - 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

    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:

    It seems that this decision has a "taste" component as well as sound
    technical rationales.  Nonetheless, what are the requirements

    - 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

    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)

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC