“The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submission to the standard.”

The key point of contention is around the meaning of "should remain compatible". What does it mean to " remain compatible"? Clearly this phrase doesn't mean "wire-level compatible" since
(a) the later mention of a "smooth migration path" implies that there will be some differences, (b) it is well-known that the standard versions of WS-MEX, et. al. will have different namespaces than submission versions,  and (c) "wire-level compatible" is well-known term of art and we have to assume that, if this was what the authors meant, this is what they would have said. So the "compatible" we are talking about lies somewhere between "wire level  compatible" on one end and and "incompatible" (whatever that is) on the other.

Microsoft seems to be taking the position that "compatible" means "minimum number of changes to XML" and/or "minimum amount of code changes" but there isn't anything in the charter to support this particular interpretation. I could just as easily claim that "remain compatible" meant nothing more than that we had to continue to use SOAP and, as far as the charter goes, my claim would be equally valid.

In reality I think "remain compatible" should be interpreted from a use-case level; any use case supported by the submission versions of WS-MEX et. al. should be supported by the standard versions and, by "supported", I mean "should be capable of being implemented without major convolutions and/or hackery". IMO none of the proposals around the use of WS-MC, the removal of the "Delivery" element, etc. have violated this definition.

- gp

Josh Cohen wrote:

Thank you Doug,

 

As to Tom's last comment, the WSMan WG did agree to this as
documented in their public charter:
http://www.dmtf.org/about/committees/WS-Management_Charter_2.1.0.pdf
"The WG has decided that a version of WS-Management shall be created that re-uses the work of the W3C WSResourceAccess WG."

 

[JoshCo] yes, but one issue with Tom’s comment:


> While I am a member of the ws man wg, this is not an official position
> of the wg.   However,
> there is a strong expectation by ws-man members that the ws man v2 would
> be based on the w3c recs which will result from this w3c ws-ra group and
> other ws-* standards from oasis.

 

[JoshCo] While the group has set a direction(as indicated in the charter) to produce a future version of WSMAN based on the RA recommendations of the technologies we currently reference/use in WSMAN 1.0 and WSMAN 1.1, the highlighted part is not actually the groups official position.  It is a personal statement from Tom.

 

@gil:  I support Asir’s request for clarification on the nature of Tom’s comments.  Tom’s initial comments did not clearly articulate who he was speaking on behalf of, and his statement about the WSMAN decisions was partially wrong as shown above.

Furthermore the comment below is sufficiently vague when it could easily have been made more clear, as Doug has shown. 

 

TOM: The next version of WS-Man will have available ws-rm, ws-make

connection, and the new features of ws-eventing

[JoshCo] I reviewed these comments with Asir, and we could not figure out if he meant it as Doug stated it or if he was implying that WSMAN will use WSRM, MC, or new eventing features.  The latter would be inappropriately speaking on behalf of the WSMAN group, hypothetical as WS-Eventing new features are not yet defined, or revealing DMTF confidential information.  The intent of this statement can only authoritatively be revealed by Tom, not the WSMAN WG. So I could not give Asir the answer.  Since I haven’t seen any objection to Doug’s clarification, I will assume that Tom agrees with Doug’s articulation.

 

 

[JoshCo] Putting the communication issues aside, the WSMAN group evaluated the statements in the charter of the WSRA WG and decided to set the aforementioned deliverable as a goal. (public information)

As it is now known, we (Microsoft) initiated and support this goal.

 

One key factor which motivated me to support this goal is the following text from the WSRA charter:

“The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submission to the standard.”

 

For me, this is really the crux of the issue at hand on this thread.  Given those words in the charter, I am concerned about the implications of the suggested change to the event delivery mode extension point, the “re-imaging” of pull as MakeConnection, and what other subtle effects that may cause.  I am also unclear about the severity of the redundancy and what the justification is for making such a change. As I’ve said before, it’s premature to make a final judgment here until a concrete proposal emerges which allows us to analyze the cost this change will impose on WSMAN.   I am eagerly awaiting that as I am sure the WSMAN WG is.

 

However if the resulting specifications change enough that it is no longer consistent with the expectations set by the WSRA charter with respect to compatibility and smooth migration, that will make it necessary to revisit my level of enthusiasm for the aforementioned deliverable.   While I cannot speak for anyone else, my prediction is that other vendors who have implemented the WS-Management Standard may have interest in this as well.

 

It’s important that there be close collaboration and communication between the WSRA and WSMAN WGs to ensure that this does not happen.  Since it is not feasible, especially in today’s economy, for everyone to participate day to day in both WGs, a written down set of liaison contacts, information exchange and review events, periodic guest participation as needed, and defined expectations would be helpful here.

 

 

 

 

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Thursday, April 02, 2009 1:10 PM
To: public-ws-resource-access@w3.org
Subject: Re: [Bug 6692] New: Remove Mode from the specification

 


(resending with proper reference.  I inappropriately referenced a
private DMTF document, when I should have just pointed to the public
charter rather then the meeting minutes)

Tom wrote:
> >> The next version of WS-Man will have available ws-rm,
> >> ws-make connection, and the new features of ws-eventing
> >>    

Asir wrote:
> > We assume that these are personal statements and not official
> statements on behalf of the DMTF WS-Management WG. Please advise if
> we misunderstood.

Then Tom wrote:
> While I am a member of the ws man wg, this is not an official position
> of the wg.   However,
> there is a strong expectation by ws-man members that the ws man v2 would
> be based on the w3c recs which will result from this w3c ws-ra group and
> other ws-* standards from oasis.

To clarify something. What Tom first wrote is technically accurate and a fact,
not personal statements.  The WSMan WG will _have available_ to it all of
the specs Tom mentioned. Whether they choose to do use them is a different
question.

As to Tom's last comment, the WSMan WG did agree to this as
documented in their public charter:
http://www.dmtf.org/about/committees/WS-Management_Charter_2.1.0.pdf
"The WG has decided that a version of WS-Management shall be created that re-uses the work of the W3C WSResourceAccess WG."

thanks,
-Doug