- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Tue, 24 Feb 2009 09:00:21 -0500
- To: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
- Message-ID: <OFBE58956B.11220EB8-ON85257567.00469591-85257567.004CF620@us.ibm.com>
Geoff,
When you say: "As part of the issue resolution, it should be made clear
that BP alignment is made on a case by case basis and that this is a
specific relaxation of Basic Profile requirements for this particular
purpose and not a general relaxation of all BP requirements, either for
this or related specs."
I am puzzled. WS-I conformance is generally a "case-by-case basis" with
each deployed instance considered anew. Tooling and run-time vendor (or
OSS) offerings can claim to be consistent with the WS-I profiles by virtue
of the ability to generate or host deployed instances that conform with
the requirements of a given profile. You cannot claim partial conformance
with a select few requirements at the expense of others. Many runtime and
tooling
offerings allow developers to make choices that violate certain
requirements of the WS-I profiles. In such cases, the deployed instances
will NOT
conform and interoperability is diminished. The WS-I profiles and testing
tools allow people to make informed choices. If interoperability is a key
requirement, then clearly it is in their best interest to deploy instances
of Web service implementations that DO conform with the WS-I profiles.
That said, the point here is that we should not be producing a
specification that increases the potential for non-interoperability by
explicitly violating constraints of the WS-I BP which have been
established by the Web services community as the "ground rules" for
interoperability yet that is what this proposal does.
You write: "Where a soap implementation does not support it, we believe
that Transfer can be implemented in a way that conforms to this
requirement."
I'm baffled. If an implementation does not support SOAP envelopes that
contain multiple child elements of the SOAP body, how is it that you
believe that Transfer can be implemented such that it conforms to the
requirement? Are you saying that the responding endpoint would not send
multiple children
of the SOAP body? Or, are you claiming that the receiver of the response
message will somehow miraculously be granted special powers to circumvent
the previous limitation of its processing capabilities through some divine
intervention? Maybe you can help me understand what you mean by that
statement.
The problem with the argument that says that "some vendors support this"
is the complement to that statement "some vendors do NOT support this".
That is where interoperability issues lurk - in the dark alleyways between
those that do and those that do not. The problem with this proposal is
that it essentially demands that "those that do not" muster the extra
resource to implement that which they do not support if any degree of
interoperability is to be achieved.
Frankly, I can't understand why we would entertain such a proposal when
another much simpler one, that conforms with the WS-I profile requirements
and can therefore be implemented by any runtime/tooling offering that
claims consistency with the WS-I profiles, is on the table.
If I had to choose between "less interoperable and places certain vendors
at an implementation disadvantage" over "interoperable and equitable", I
think I know which I'd choose.
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986
From:
Geoff Bullen <Geoff.Bullen@microsoft.com>
To:
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>,
"public-ws-resource-access-request@w3.org"
<public-ws-resource-access-request@w3.org>
Date:
02/23/2009 10:41 PM
Subject:
Counter proposal for Issue 6398
Sent by:
public-ws-resource-access-request@w3.org
Summary of Counter Proposal
1. The requirements for BP compliant WSDL are relaxed for
WS-Transfer.
2. All 8 WS-Transfer Messages remain as is, i.e. with no wrapper
elements.
3. All RT messages have their outer wrapper elements removed.
4. Transfer Create message changes cardinality to 0 or more.
This proposal avoids disrupting the interoperability of existing Transfer
implementations by remaining compatible with protocols and formats that
depend on it (see charter), provides an efficient protocol for the 8 key
Transfer messages, allows Transfer Create to handle the null constructor
case (and offers a smooth migration path from submission to the standard)
and changes the RT specification to reference Transfer in an appropriate
manner.
Counter Proposal Details
1. The requirements for BP compliant WSDL are relaxed for
WS-Transfer.
Based on the need to create an efficient wire protocol, the WG should
agree that those Basic Profile requirements pertaining to the WSDL
definition, that prevent such a format being specified, are relaxed for
WS-T and WS-RT. These requirements include: R2202, R2712, R2204 and R9981
. As part of the issue resolution, it should be made clear that BP
alignment is made on a case by case basis and that this is a specific
relaxation of Basic Profile requirements for this particular purpose and
not a general relaxation of all BP requirements, either for this or
related specs.
In order for some tools vendors to make progress on this, it may be
interesting to consider using Transfer policy assertions to make the
offending WSDL sections implicit, rather than explicit, thus eliminating
the need to define the WSDL at all. While this may have other
implications, it may be worth discussing this option.
In terms of support for multiple children in the soap body, SOAP 1.2 does
support this concept, and many SOAP 1.2 implementations also support it.
Where a soap implementation does not support it, we believe that Transfer
can be implemented in a way that conforms to this requirement.
2. All 8 WS-Transfer Messages remain as is, i.e. with no new wrapper
elements added.
There are no changes to the spec required to implement this.
3. All RT messages have their outer wrapper elements removed.
In order to maintain alignment with the Transfer specification, all outer
wrapper elements defined in the RT specification should be removed. The
associated RT messages would now look like:
T-GetRequest: RT-GetRequest:
<soap:body> <soap:body>
xs:any * <wsrt:Expression Dialect="xs:anyURI" ...>
xs:any </wsrt:Expression> *
</soap:body> </soap:body>
T-GetResponse: RT-GetResponse:
<soap:body> <soap:body>
xs:any + <wsrt:Result...>xs:any</wsrt:Result> +
</soap:body> </soap:body>
T-PutRequest: RT-PutRequest:
<soap:body> <soap:body>
xs:any + <wsrt:Fragment Dialect="xs:anyURI" ...>
+
</soap:body> </soap:body>
T-PutResponse: RT-PutResponse:
<soap:body> <soap:body>
xs:any ? xs:any ?
</soap:body> </soap:body>
T-DeleteRequest:
<soap:body>
xs:any *
</soap:body>
T-DeleteResponse:
<soap:body>
xs:any *
</soap:body>
T-CreateRequest: RT-CreateRequest:
<soap:body> <soap:body>
xs:any * <wsmex:Metadata ...> ?
<wsrt:Fragment ...> *
</soap:body> </soap:body>
T-CreateResponse: RT-CreateResponse:
<soap:body> <soap:body>
<wst:ResourceCreated> <wst:ResourceCreated>
xs:any ? xs:any ?
</wst:ResourceCreated> </wst:ResourceCreated>
xs:any * xs:any *
</soap:body> </soap:body>
4. Transfer Create message changes cardinality to 0 or more.
In order to support the case of a null constructor, the Transfer Create
message in the schema should be changed from
xs:any +
To
xs:any *
The charter states that WS-Transfer should remain compatible with
protocols that depend on it, and offer a smooth migration path. This can
be achieved here in that if original implementations which do not support
a zero element create would simply fault (t:InvalidRepresentation) anyway.
We should suggest in the migration instructions that this fault should
continue to be used if the implemented code does not support null create
messages.
--Geoff
Received on Tuesday, 24 February 2009 14:01:34 UTC