RE: AI 131 - BP requirements that apply to WS-RA's reference to WSDL 1.1

Ø  I've been reviewing Section 4. I can't find a single "MUST" requirement that, if violated, wouldn't cause interoperability problems between our respective stacks.

The problem here is that even if one complies to the requirements in BP 1.1 section 4, there will be interoperability problems between valid WSDL 1.1 implementations. For example, BP 1.1 requirement R2303 that restricts the use of WSDL 1.1 will cause interoperability problems with resource constrained devices that use DPWS.

I acknowledge your point about interoperability and it is important to ensure that the WS-RA specification are interoperable; the key is to identify the right subset of BP 1.1 section 4 requirements that would help achieve this.

Thanks.

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Monday, January 04, 2010 4:20 PM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org
Subject: Re: AI 131 - BP requirements that apply to WS-RA's reference to WSDL 1.1

Ram,

I think you are confusing things here. We have already agreed that "end-user WSDLs are free to comply (or not) with the requirements in Section 4 of BP 1.1 as they see fit." In my mental model, a device that implements the Devices Profile is an "end-user" from the point of view of the WS-RA specs.

For example, you performed a WS-MEX GetMetadata on an endpoint asking for its "application view" and got back a Devices Profile-constrained WSDL that contained solicit-response operations, the web services stack at the endpoint would not have violated any of the WS-RA-defined specs (in this regard). If, on the other hand, you performed a WS-MEX GetMetadata on an endpoint asking for the WSDL of its WS-Eventing implementation and got back a WSDL that, for example, contained a soap11:binding element without the @transport attribute (in violation of BP 1.1 R2701), then the web services stack at the endpoint would be in violation of both BP 1.1 *and* WS-Eventing.

I'm not really concerned with labels like "errata" or "rightful successor"; I want to make sure that our different implementations of WS-Eventing, WS-Enumeration, etc. interoperate. I don't think that merely "encouraging" implementations to conform to specific requirements in Section 4 of BP 1.1 is going to help make that happen. I've been reviewing Section 4. I can't find a single "MUST" requirement that, if violated, wouldn't cause interoperability problems between our respective stacks.

- gp

On 12/31/2009 2:13 PM, Ram Jeyaraman wrote:
For example, Basic Profile (BP) 1.1 R2303 prohibits the use of solicit-response and notification operations, whereas Devices Profile for Web Services [2] relaxes BP 1.1 R2303 for reasons that better serve the needs of the devices community. The use of solicit-response and notification operations in WSDL provides useful description of the device capabilities.

My concern is larger though. While it is true that BP 1.1 profile of WSDL 1.1 is useful, it does not mean that BP 1.1 is an errata or a rightful successor of WSDL 1.1. The fact that DPWS 1.1, though it uses BP 1.1 section 4, overrides BP 1.1 section 4 is evidence that BP 1.1 cannot be used as a replacement or as a required adjunct to WSDL 1.1. WSDL 1.1, BP 1.1, and DPWS 1.1 were developed by different organizations and do not always cover the same exact usage scenarios.

My thesis is that it is sufficient to encourage concrete implementations of  WS-RA WSDL’s to conform to *specific* requirements in BP 1.1 that this WG thinks are reasonable and useful. Such a statement can appear in the conformance section of the WS-RA specifications. Anything beyond that is heavy handed and makes unreasonable assumptions about the applicability of BP 1.1.

Thanks.

[1] BP 1.1 http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Allowed_Operations

4.5.2 Allowed Operations
Solicit-Response and Notification operations are not well defined by WSDL 1.1; furthermore, WSDL 1.1 does not define bindings for them.
R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

[2] Devices Profile for Web Services 1.1 http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-spec-os.html#_Toc228672095

4.3 WSDL

R2004: If a HOSTED SERVICE exposes Notifications, its portType MUST include Notification and/or Solicit-Response Operations describing those Notifications.
R2004 relaxes R2303 in [BP 1.1, Section 4<http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-spec-os.html#bp11section4>].

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Tuesday, December 22, 2009 11:53 AM
To: Ram Jeyaraman
Cc: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>
Subject: Re: AI 131 - BP requirements that apply to WS-RA's reference to WSDL 1.1

You'll have to forgive me, I have a limited imagination. Can you provide some examples of the "valid reasons" an implementation may have for producing/providing a WSDL that violates the one or more of the requirements in Section 4 of BP 1.1? I can't think of any.

- gp

On 12/22/2009 10:14 AM, Ram Jeyaraman wrote:

Comments inserted below.



From: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org> [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz

Sent: Monday, December 21, 2009 11:18 AM

To: public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>

Subject: Re: AI 131 - BP requirements that apply to WS-RA's reference to WSDL 1.1



A large part of this issue is about what it means for one spec to normatively reference another spec. That's a pretty big subject but, in the context of this issue I construe it in the following way:



1.) Except for WS-Frag, the specs produced by WS-RA all include WSDL definitions. These WSDL definitions must comply with the requirements in Section 4, "Service Description", of BP 1.1 [1] which, as far as I am aware, they do.



[Ram Jeyaraman] Agree. This is the minimum due diligence the specifications need to do to ensure that the protocol descriptions are interoperable.



2.) In addition to this, several of our specs discuss or hint at the possibility of implementations that produce/provide WSDLs that are refinements or extensions to the WSDLs defined in our specs. For example, a service that supported WS-Transfer might, if asked correctly, provide a consumer with a WSDL that extends the W3C version of the WS-Transfer WSDL to include a SOAP binding of the "Resource" portType along with a service/port for that service's endpoint. This WSDL must also comply with the requirements in Section 4.



[Ram Jeyaraman] Beyond bullet item #1 above, I think the specifications should encourage, but NOT require, concrete manifestations (that include bindings, et cetera) of WS-RA WSDLs to comply with *specific* requirements in BP 1.1 section 4. This provides the right level of guidance to implementations so they can make interoperable choices. Making it a requirement is too limiting since there may be cases where implementations (endpoints) may choose NOT to do this for valid reasons; this is particularly so since the WS-RA specifications do not define the concrete WSDLs and hence may not anticipate all  the sundry use cases that concrete WSDLs may cover.



3.) End-user WSDLs are free to comply (or not) with the requirements in Section 4 of BP 1.1 as they see fit.



[Ram Jeyaraman] Agree.



[1] http://www.ws-i.org/Profiles/BasicProfile-1.1.html




- gp