[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... 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC