OGSA Teleconference - 8 June 2005 ================================= * Participants Mike Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Apologies: Andrew Grimshaw Minutes: Andreas Savva * OGSA co-chair nomination Tom has received approval from management. * Document review process With three documents nearing completion the group discussed how best to complete the review process. 1. Put a clean copy with all changes accepted on gridforge (today or as soon as possible). Turn on line numbers (by 5 lines by page) for these versions to make it easier for people to refer to specific places in the text. 2. Assign people to go through entire document and do an overall check for consistency, with a special view on the flow of the text, completeness, etc. (Everyone is welcome to contribute to this effort.) 3. Assign people to verify (specific) trackers that are currently in the fixed state (One person per tracker; and maybe more than one tracker per person) The group also discussed how to do comments. There were two proposals: 1. Comments in the document and send document to the list 2. Send text email to the list pointing to the location in the document that needs revision. The overall preference was for the second option (text emails) rather than sending documents around. Partly for bandwidth reasons and partly due to issues of serialization and merging multiple document versions. But if a reviewers decide that a lot of editing is required then they should ask for, or take the pen (by sending an email to the list) and make the changes in the document. The deadline for completing the review is Monday, June 13. ** Basic Profile review volunteers - Proofreading (overall) - Dave Snelling (Tom to ask) - Jay Unger - Mike Behrens - Hiro Kishimoto - (And other people that Tom has asked already) - Tracker verification - Andreas Savva ** Profile definition review volunteers - Proofreading (overall) - Tom Maguire - Andreas Savva - Mike Behrens - Tracker verification - Not needed. All artifacts are closed. ** Roadmap review volunteers - Proofreading - Hiro Kishimoto - Takuya Mori - Tracker verification - Tom Maguire * WSRF Basic Profile (BP) review ** Should the referenced specs be updated? The WSRF BP is referring to an old (2004), somewhat inconsistent, set of specs for WS-Addressing, WSRF and WS-N. (Ref. WS-Addressing discussion). A number of recent developments might offer an opportunity to fix this: - WS-Addressing specs (last call) - The OASIS WSRF TC has a ballot closing at the end of this week (Sat., June 11 (1pm Eastern)) to send out the WSRF set of committee draft documents for public review - The WS-N group is planning to release committee drafts of the Base Notification specification (perhaps July 1) and also of Topics (and maybe also brokered notification). So it looks like there will be an updated, consistent set of documents to refer to. The problem is whether, and how, to keep the deadline for submitting the document to the GGF Editor (next week) and also make sure that the WSRF Basic Profile can be updated to use these specs when they come out. At the very least the changes required to the BP would be to the References, Namespaces and links to imported schemas. - For the WSRF and WS-Addressing specification these are (almost) known. - But the WS-N ones are not completely fixed yet. A number of scenarios were discussed: 1. Wait for the new versions to come out, update the BP and submit 2. Submit the document as-is and then put a public comment that it should be updated with the new WSRF+ set of specifications when they come out. 3. Put a comment in the document that it will be updated with the new WSRF+ set of specs and submit it as-is. - Scenario (3) was rejected since it clearly bends the rules too much. - Scenario (1) is the safest one but it keeps the BP queued and waiting for the updated specifications. - Scenario (2) follows the GGF process---the editors/authors are also encouraged to submit comments. But if there is a delay in the release of the referenced specs then the BP goes through as-is; or if there is a need for more changes than anticipated then a second round of public comment would be required. The remaining issue about scenario (2) was whether we are relaxing the submission rule as defined by "Profile Definition". The key point is whether the current draft of the BP, referencing old WS-Addressing, WSRF and WS-N drafts, qualifies for submission to the GGF Editor. In other words are the references used 'stable' and could the BP proceed to R-P status, potentially without any of the above changes. It was argued that the definition of 'stable' is that specifications must be at least 'committee drafts'. And that the existing referenced specs, even if they are not called 'committee drafts' have been through a similar process and are therefore of an equivalent level. In particular, it was proposed that the new OASIS type of "working draft" is equivalent to a "committee draft" since there is a vote by the TC to make such documents public. There was no consensus, however. The preference on the call was for scenario (2) and (1) in that order. The 'stable' reference rule needs more clarification, however. Action: Hiro to follow up on the definition of 'stable' and whether the specifications in question satisfy that rule. Also, if the group decides to go with (2) then the group has to discuss and agree on what the public comment should say. ** Section 4.1.1: ResourcePropertiesNames Defines syntax of resource properties, but there is no explanation of the meanings of most of these, what their values may be and why. Action: Tom will add an appendix with pseudo schema (mini spec) and additional text for each property. (A definition along the lines of R0415 and R0416.) ** Appendic C: Basic profile schema - There is a duplicate definition. - The definitions are incomplete (see above) Action: Tom will add cardinalities; perhaps add these in the mini-spec. ** Section 4.3: Serialization of XPath 1.0 response The mini-schema was defined to avoid the ambiguity in the XPath spec. But why did not other people try to solve it, already? The WSRF TC, for example, is aware of this problem but decided that it did not have the authority to fix this. (Out of scope.) The W3C, which has the authority to address this problem, also has not done anything. But the W3C does not mandate XPath 1.0. In the WSRF BP 1.0 XPath 1.0 is mandated so a solution had to be provided. Action: Tom will add explanation to the BP on the necessity of defining the XPath 1.0 response serialization. ** Numbering of R & E statements Numbering is inconsistent. Some numbers are based on section numbers; some on subsection. Action: Tom will make them consistent; suggestions welcome. ** Appendix A There are three references to UDDI specs. Agreed that the list needs cleanup. Action: Tom to clean up list and in particular remove the UDDI binding template reference. ** Appendix B Also needs cleanup. * Roadmap review Jem has done some work on how to keep tables consistent. Tom has also independently done some work on this. They seem to have arrived to the same solution. - Use an excel spreadsheet for the master table and produce separate smaller tables in separate sheets for each specific spec. These smaller tables refer to row/column in the master sheet. Considered linking the spreadsheets directly to the Roadmap using OLE but rejected this during the call since it is not a platform-neutral method. (People using Macs could not use the Word document.) Therefore it was agreed that the master table and sub-tables should be done in Excel. And a 'view' or 'image' of the sub-tables should be provided for use in the Word document.