- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Tue, 24 Feb 2009 15:00:57 -0500
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: Doug Davis <dug@us.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>, "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: <OF1279033C.8002027C-ON85257567.006DCECE-85257567.006DF987@us.ibm.com>
Oops, typo.
s/Claiming the wrapper element to me "semantically useless" is/Claiming
the wrapper element to be "semantically useless" is/
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:
Christopher B Ferris/Waltham/IBM@IBMUS
To:
Geoff Bullen <Geoff.Bullen@microsoft.com>
Cc:
Doug Davis/Raleigh/IBM@IBMUS, "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/24/2009 02:50 PM
Subject:
RE: Counter proposal for Issue 6398
Sent by:
public-ws-resource-access-request@w3.org
Geoff,
You wrote:
Why is it that you require everyone to conform to a profile that is so old
it does not even work with WS-Addressing?
The profile requirements in question are still applicable in the two
versions of the Basic Profile currently being finalized by WS-I
that are based both on SOAP1.1 and 1.2 and incorporate WS-Addressing:
Basic Profile 1.2 and 2.0.
That point aside, the point that I think you are missing is that what you
are asking for is to change the model by which
WSDL works, in a fundamental manner at that.
The document-literal model of WSDL 1.1 is defined by the WS-I profile,
because the original WSDL spec was so misunderstood
and there was such a variety of "innovation" in the choices that were made
with regards to its use that there was virtually
no interoperability whatsoever.
The Web services community came together under WS-I, Microsoft included as
a leader in the initiative, to establish
the ground rules and a coherent model by which WSDL1.1 and SOAP1.1 could
be interoperably implemented. The model that was
chosen was that the document-literal binding be defined as one in which
the wsdl:part element has an @element attribute,
not a @type attribute and that that @element attribute reference a GED in
a referenced schema.
From my perspective, you have not related a compelling argument that
warrants that that model be changed. Claiming the
wrapper element to me "semantically useless" is a wholly uncompelling
argument to undo many person years of effort that
were expended to bring the Web services community towards
interoperability.
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:
Doug Davis/Raleigh/IBM@IBMUS
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>
Date:
02/24/2009 01:32 PM
Subject:
RE: Counter proposal for Issue 6398
Sent by:
public-ws-resource-access-request@w3.org
Doug,
Here are some thoughts about the things you talk about below:
a) WS-Man is profiling Transfer, which is how it should be. The
WS-Man domain has specific requirements and it should profile all of its
referenced specs to meet those requirements. This is not an argument to
make Transfer “the same as” WS-Man, it is an argument to say that Transfer
must be a “super-set” of the WS-Man requirements. If there is an issue
such that WS-Man cannot profile Transfer in an appropriate way, then the
WS-Man working group should create an issue for us to look at and resolve.
b) WS-Man is not the only community that requires Transfer, there are
others, in other domains, that do use multiple children in the soap body
and other non-BP compliant concepts. Why is it easier to change all these
applications than it is to change a few tools?
c) We opened a place-holder issue such that if the WG consensus was
to include wrappers we would be reminded that there are other places where
wrappers also need to be added (e.g. MEX). Clearly it is not just Transfer
that follows the non-wrapper approach. If the WG decides not to support
wrappers, then this issue would be moot.
d) Many, more modern, soap stacks support more than one child
element. Soap 1.2 supports this concept. Must the standard be restricted
to the lowest common denominator? I suggest that is the exact job of a
profile, not a standard. If older soap stacks are important to a
particular domain, then the people to whom that domain is important should
define a profile of the appropriate standards to support that. The
Transfer standard should definitely not prohibit a group of people from
defining a valid Transfer profile that supports these older stacks.
Similarly, for those people who do not have such restrictions, it should
be similarly possible to use Transfer in a way that suits them.
e) By your reasoning, shouldn’t you also be pushing to have the SOAP
1.2 W3C recommendation reopened and amend it to only support one child
element?
f) Profiles come AFTER the standards they are profiling, not before.
You seem to be trying to create a standard AND profile it at the same
time in the same step.
g) BP compliant tools vendors should be able to build a profile of
Transfer that supports their tools. Implementations that use that profile
will work with those tools, without change to those tools. No one is
forcing tools vendors to update if they do not wish to.
h) We are simply trying to suggest to you that standards are bigger
than any one particular profile. To mandate that Transfer must conform to
BP in this way, negates the ability for others to provide innovative
solutions that do not require this profile (of which there are already
quite a few). Why is it that you require everyone to conform to a profile
that is so old it does not even work with WS-Addressing? Why is it that
this is the “upper bar” you wish to set for all specifications? Why are
the people that need BP more important than the people who don’t? Why are
a few tools vendors more important than many thousands of implementations?
Should we not design for the future, while allowing interoperability with
the past?
i) You seem to infer that being “different” in some way equates to
being “wrong” or “bad”. That it must be carefully explained why something
should be done differently to the way things are done elsewhere. History
has recorded that same vexing question being asked since, well, history
was recorded. Specifications are written at different times, by different
people, for different reasons, under different circumstances. We must
weigh the current set of circumstances and come up with the best Transfer
specification we can based on that input.
So, returning to the main theme, why should we add a semantically useless
wrapper and clutter protocols, restricting innovation by a growing number
of implementations that do not need or want it, just because some design
tools need it? Should we not be trying to build a spec that encompasses
the super-set of both requirements, and create profiles to define the
sub-sets required by each separate domain of usage?
--Geoff
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, February 24, 2009 6:58 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org;
public-ws-resource-access-request@w3.org
Subject: Re: Counter proposal for Issue 6398
Geoff,
The guiding principle of your proposal is that the rest of the WS
community needs to change rather than WS-Transfer. You keep repeating
that the charter talks about trying to maintain backwards compatibility
with existing implementations - but you seem to be ignoring that this
doesn't mean that it needs to be done at the expense of all other WS
activities. Implementations of WS-Transfer will need to change - if
nothing else to pick up the new namespace - that alone opens the door for
other reasonable changes. Given that opening, people will need to decide
for themselves which piece of work is smaller, and more reasonable to
expect of people:
a) while picking up the other WS-Transfer changes, WS-Transfer
implementations will need to deal with the wrapper
or
b) change BP, change all existing BP compliant runtimes and toolings,
allow for these new usage patterns in all future WS work - not just
WS-Transfer, not have WSDL for some usecases (as Geoff points out) and
change RT and its implementations
The answer is obvious to me. However, if you really want to pursue 'b'
you are free to do so by opening new issues in BP. However, since you
seem to like to revisit the charter, let's not also forget that it talks
about us completing our work in a timely fashion. Given that any such
change to BP is not only unlikely (IMO), but would also not be publicly
visible for quite a long time, this WG needs to make its decisions based
on the information/specs/profiles available to us now - and not on some
future piece of work that might or might not happen.
BTW, I'm still waiting for your responses to my questions I asked in a
previous note [1] about why WS-Transfer _must_ be different from pretty
much all other WS specs [2].
[1]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0118.html
[2] http://www.youtube.com/watch?v=tZIvgQ9ik48
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org
02/23/2009 10:38 PM
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>
cc
Subject
Counter proposal for Issue 6398
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 20:02:07 UTC