Hi Tom and Dave, I took a homework assignment of farther study on if we should update referenced spec in BP 1.0 or not. After due consideration with Andreas, We arrive at a conclusion. Well, our short answer is "yes, OGSA-WG should." Here is our long answer. (1) We believe that our current definition of "emerging institutional standard (EIS)" needs some work. The main distinction at the moment is that "a specification of this status type must have an externally stable reference to the specification." But to some extent this is already a requirement of all specifications referenced by a profile (section 3.1). The main distinction should be instead on whether there is a draft that has been approved as a 'stable draft' by some process of that standards organization; including satisfying the intellectual property considerations of that standards body. (For example, it would be inappropriate for an EIS to refer to a "Draft specification" with unclear IPR.) So, for example, an OASIS committee draft (CD) would be a EIS. (But a WD would not.) So would a GGF Grid Working Draft (GWD-R.P), since it has been approved as a draft by the GFSG. A problem with the above definition is that a GGF WG draft that has not been submitted to the GGF Editor has no suitable status. At this moment, we have plenty of such documents, e.g. OGSA WSRF BP 1.0, JSDL 1.0, and RNS 1.0. So we'd also propose adding a new "status type" something like "draft institutional standard." Otherwise, we cannot include the above mentioned draft specs in the OGSA Roadmap tables. (2) We should add one more restriction to "recommendation profile as proposed recommendation." The additional restriction would highlight that the set of specifications in a profile should be consistent. In other words, if a specification is referenced directly or indirectly (transitively) by different specifications in a profile then the same version should be referenced. Please have a look to modifications proposal to profile definition attached to this email. (3) Let's assess the OGSA WSRF BP 1.0 referring specs and profiles based on the above two criteria. Currently the WSRF BP 1.0 refers to a) WS-Addressing (2004-08-10) b) WSRF 1.2 working drafts c) WSN 1.2 working drafts d) WS-I BP 1.1 and BSP 1.0 (a), (b), and (c) run into problems with criteria (1) and (2). For example, the WS-Addressing reference fails criterium (1) (intellectual property considerations since it refers to ws-policy). WSRF 1.2 refers to a newer version of WS-Addressing so it causes an inconsistent set of references. (The referenced WSRF 1.2 version is also a working draft not a committee draft.) For (a) and (b) new versions that satisfy the proposed criteria exist. But an appropriate draft for (c) is not available yet. (WSN spec series 1.2 refer to WS-addressing member submission dated 2004-08.) So we should update the WSRF BP 1.0 to the following versions before submission: - WS-addressing 1.0, 2005-03-31. - WSRF spec series 1.2 committee draft - WSN spec series 1.3 committee draft (not available yet) - WS-I BP 1.1 and BSP 1.0 Good news is WSN-TC will move 1.3 to CD early July. We only need to wait for one or two weeks and then finalize our WSRF BP 1.0. -- Hiro Kishimoto Andreas Savva wrote:
OGSA Teleconference - 8 June 2005 ================================= * 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.