UBL Naming and Design Rules SC

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

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

    Posted 02-09-2002 01:30
    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.