This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Its not clear which of the WSRA specs have implicit vs explicit operations. In other words, which operations would appear in the WSDL for a service? IMO MEX is clearly a infrastructure spec - I don't think we expect any client to actually write those operations or have their wsdl->code tooling generate stubs for those. The others are not as clear to me. I suspect that some people might think they're infrastructural and some might consider them to be more like an application. I believe the impact of this will be: - implicit ops will _not_ appear in service's wsdl - we'll need to figure out how to express implicit op's QoS/policy - we'll need to figure out how to advertise which optional implicit ops are supported (probably thru policy) - explicit ops will appear in a service's wsdl along with user-defined ops - no need for policy to describe which ones are optional - wsdl does this - we'll need to figure out how to express the op's QoS/policy - probably just attaching policy No clear proposal right now, but it seems to me that a question to ask is whether or not we expect end-users to actually generate and fill-in the code for any stubs generated from explicit ops that appear in WSDL? With this in mind I'm having a hard time seeing how any of these specs should be explicit. hmmm, maybe that was a proposal :-) note: I'm not talking about things like events - I think those will need to generate stubs - but the Subscribe() doesn't seem like something an end-user should be forced to code up.
Action-66
RESOLUTION: (directional) everything is implicitly defined with WS-Policy assertions, optionality of operations to be indicated by assertions or some other appropriate WS-Policy mechanism. In addition the wsdl will be in the specs
This is possible text for inclusion in the specs that makes it clear that what application developers are likely to find in application WSDLs. "The operations defined by this specification are not intended to be implemented by application developers and therefore MUST NOT appear in application specific WSDL. Endpoints MAY indicate support for these operations through the use of the Policy assertions defined in section X.Y. These operations are expected to be implemented by infrastructure developers and if the WSDL is needed by those developers then it can be retrieved at the URL specified in Appendix C."
Asir, Doug, and Dave have come up with the following language. It is less proscriptive than my last pass, but makes it clear what implicit ops are and how that affects what people see. "An endpoint MAY indicate that it supports WS-Eventing, or any of its features, by including the WS-Eventing Policy assertion(s) within its WSDL. By doing so the endpoint is indicating that the corresponding WS-Eventing operations will be supported by that endpoint since they will not appear in the WSDL. " Clearly the spec name needs to be changed for different specs.
Whatever text we choose, as we close down this issue is it fair to assume that this text will appear in whatever Policy section we come up with for each spec? Or, in other words, this isn't part of the main RA specs, it goes where ever we define the policy for each one, right?
"An endpoint MAY indicate that it supports WS-Eventing, or its features, by including the WS-Eventing Policy assertion(s) within its WSDL. By doing so the endpoint is indicating that the corresponding WS-Eventing operations are supported by that endpoint even they do not explicitly appear in its WSDL.
"An endpoint MAY indicate that it supports WS-Eventing, or its features, by including the WS-Eventing Policy assertion(s) within its WSDL. By doing so the endpoint is indicating that the corresponding WS-Eventing operations are supported by that endpoint even though they do not explicitly appear in its WSDL.
this would go in the policy section when created
Please make my changes