[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Atlantic UBL TC call 7 September 2005
MINUTES OF ATLANTIC UBL TC MEETING 15H00 - 17H00 UTC WEDNESDAY 7 SEPTEMBER 2005 ATTENDANCE Peter Borresen Jon Bosak (chair) Mavis Cournane Betty Harvey Anne Hendry Zarella Rendon Paul Thorpe Sylvia Webb Note that Mavis will be unable to attend most of the next two weeks. STANDING ITEMS Additions to the calendar: http://ibiblio.org/bosak/ubl/calendar.htm None. Liaison reports AGREED to accept Stephen Green's offer to serve as liaison between the OASIS UBL TC and the OASIS ebBP TC. Subcommittee report: SSC AH: SSC is figuring out a better time to meet; SW has sent out a discussion proposal for how we're going to do Q/A. Team report: Code Lists JB: MartyB sends regrets for this meeting. He has resumed the email discussion with GKH and is working on the code list schema. Team report: Digital Signatures PB: Talked to ThomasL; will send him a suggestion for signature document reference. Review of Pacific and Europe/Asia calls MavisC: Was in the Europe/Asia only briefly, but has a concern about she heard regarding maintanance of our own Specialized DT schemas. NDR team needs to understand this better. Requests that this be put on the agenda for the next Pacific TC meeting. Schedule review: http://lists.oasis-open.org/archives/ubl/200508/msg00167.html Customization MavisC: MikkelB in the Europe/Asia call wondered if we could start the customization discussion and could still put in customization requirements to the NDR doc. Replied that customization should not affect schema generation, but TM said that we must be able to allow changes to affect the NDRs. JB: We're trying to avoid any changes to the NDRs, but that could always happen; if it does, we may have a problem with the schedule, but if it has to happen, then we can't prevent that. "Define a minor versioning methodology" (row 8) AGREED that we will kick off the discussion of minor versioning next week, with MavisC joining for the second hour to guide that. ACTION: MavisC to contact MikkelB regarding his attempt to create a minor version of UBL. "Generate phase 1 schemas" (row 10) SW: DavidK says he did not get feedback on the last set except from SG; so he believes that he has completed all programming for the current NDRs. He can't do additional programming if he doesn't hear feedback. He is requesting addtional info re the code list proposal; he's having a difficult time assessing potential impact of the second proposal based on the exchange between TonyC and MartyB to date. He wants schema examples for what they expect from Edifix. JB: What of the problems reported Monday? SW: All turned out to be human errors in the generatiof of the Common and Procurement spreadsheets; there does not appear to be an EF problem. Will correct these errors manually and reinput to EF to produce a new set of schemas this week. "Define and document representative extended procurement scenarios" (row 30) JB: How is this different from the extended procurement description and which is normative? Add to Pacific TC agenda. (See action item review for more on this) ACTION ITEM REVIEW ACTION: SW to check on implementation of 2.0 NDRs per row 9 of the schedule and report back on Monday. Done. ACTION: PB to begin work on defining and documenting representative extended procurement scenarios per row 30 of the schedule. PB: We are trying to get a contractor to work on this. We need to develop a template for specifying scenarios and a classification scheme for scenarios. We want to align with the OGC descriptions; this is a good way to test the UBL model. We can't progress this item till we have a contractor, but we're still aiming to hit October 24. ACTION: TC members visiting NYC in October or November to check out the Sun facilities and see whether they are suitable for a UBL TC meeting. JB will be coming through in mid-November and will also check then. Pending. ACTION: MarkC to review schema import diagrams in the NDR document and update as appropriate. Pending. This is becoming critical. No one else has the tool to do this (Visio). ACTION: MB to continue code list dialog with GKH. In progress. ACTION: MarkC to send ATG paper on CLs to MB and share it with the list when that becomes possible. Status unknown. ACTION: MikkelB to provide a clear specification of what is required by law in DK regarding CLs by next week. Done. ACTION: MartyB to provide a revised example of the enum version of the currency CL as formerly proposed but without substitution groups, by next week if possible. Pending. ACTION: TonyC to provide a script that will transform a CL instance conforming to the proposed CL schema into a schematron schema by next week. Think this is done but haven't had a chance to review Tony's latest message on this. CODE LISTS JB: What's the difference mechanically between the codes we supply and the ones we don't? For example, how would a user turn off validation of the currency code list to put it back into the unsupplied category? How would the user change to enum form? Do either of these changes require a change to the doc schemas? ACTION: JB to ask in email. JB: I think that these are the issues: 1. Whether we should supply any code lists that we are not completely responsible for defining 2. What to do with ATG-supplied code lists 3. How to include sufficient version info to provide an audit trail of code list changes 4. How to document the two different methods for adding code lists to the set we provide (General agreement that these appear to be the issues needing resolution by the TC.) Issue 1: Whether we should supply any code lists that we are not completely responsible for defining JB: Should we include lists we don't define (setting aside the question of including lists defined by ATG2)? MavisC: No. This should be considered customization. BH: No. What if the code list issuer changes the list and people keep using the version we've supplied. SW: With the exception of lists defined by ATG2, code lists should be left to trading partners, at least for the foreseeable future. We don't see ad hoc transactions without detailed trading partner agreements, even with CPP. If we included these code lists, we would bear the responsibility for maintaining them and informing users of changes. We need to give implementers the greatest flexibility in implementation. AH: No (as stated in the email message that started this discussion). The support and compatibility problems could be phenomenal. ZH: No opinion. PT: No, with the possible exception of country codes. We should be trying to get others to maintain code lists. PB: Would be nice to have in the package, but maybe in a special folder. JB: So these could become part of the informative materials along with the code list documentation. ??: Put them on the web site... PT: It depends on how often a code list could change; if it's "never," then there's no problem with including it. JB: Maybe the ATG decisions will decide this for us. AGREED that we can include in the normative parts of UBL 2.0 any public code lists that ATG takes responsibility for, but not other code lists that we don't maintain. JB: We will continue discussing the remaining issues next week. NDR WORK SESSION ACTION: JB to check whether MikeG and MarkC will be on the call next week so that we can begin work on a minor versioning methodology. Jon Bosak Chair, OASIS UBL TC
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]