RE: Counter proposal for Issue 6398

Doug,
As a profile to enable interop between major enterprise Web service vendors, Microsoft views Basic Profile 2.0 as being very important and we fully support WS-I in this regard.  BP 2.0 correctly profiles an existing spec (Soap 1.2) into a sub-set that is appropriate for that domain of use.  Interop within that domain (and other domains) remains a high priority for Microsoft.

Microsoft does not accept the abstract principle that W3C specification authors must be constrained by WS-I profiles that were meant to guide service developers. WS-I Profiles should be seen by implementers as useful profiles, and as such we actively encourage people to make sure their Web services implementations of various specifications also conform to these profiles, where such conformance makes sense.  To mandate conformance in all specifications, for all implementations of Web services, does not make sense.

For more complete information on our position see:
http://lists.w3.org/Archives/Member/w3c-ac-forum/2008OctDec/0043.html (member only)

--Geoff

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 24, 2009 12:36 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: Counter proposal for Issue 6398


Not really since even your MSFT colleagues in WS-I BP 2.0 agree that to get interop on SOAP 1.2 we should do things like limit the Body to one child.  But I appreciate the insight into MSFT's true thinking that WS-I and BP are not really that important.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com

Geoff Bullen <Geoff.Bullen@microsoft.com>

02/24/2009 03:30 PM

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>

Subject

RE: Counter proposal for Issue 6398







>  So again, I'd like to hear why WS-Transfer _must_ be different, _must not_ adhere to BP, _must not_ adhere to the patterns we see in pretty much all other WS spec, _must_ force some existing soap stacks to change some fundamental design choices to support things like multiple children in the Body?  IMO, the exception needs to be justified, not the rule.

OK Doug, We believe that we have answered the above questions, but let us lay it out more directly for you.

1)     WS-Transfer _must_ be different
Following a pattern, just for the sake of following a pattern is not a good reason.  Follow the pattern because it is a good pattern, yes, but don't follow it because it is there.  SOAP 1.2 shows us that some more recent W3C specs DO NOT follow BP principles, or patterns.  This spec does allow multiple children.  I would prefer to take my patterns from here, to advance our thinking, rather continue to rely on a very old profile, that many think is inadequate for handling today's solutions.  Transfer must be different because it must embrace newer standards that have come out AFTER basic profile and many of the other specs.
2)      _must not_ adhere to BP
See point 1).  BP is a profile.  Once Transfer is done and written in such a way that basic profile conformance is possible, a profile can be written, if desired, to profile Transfer.
3)      _must not_ adhere to the patterns we see in pretty much all other WS spec
W3C Soap 1.2 does not follow this pattern and yet it represents the latest thinking on how soap should progress.
4)      _must_ force some existing soap stacks to change some fundamental design choices to support things like multiple children in the Body
That forcing decision was made by the Soap 1.2 WG, not by this WG.  Soap stacks, if they want to implement Soap 1.2, should support multiple children.  W3C is not responsible for certain tools vendors "design choices".

I hope that helps,
Cheers,
Geoff


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 24, 2009 10:45 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


Hopefully, by the time we have our call later today you'll actually have answers to my questions.  Request #3.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<mailto:dug@us.ibm.com>
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

02/24/2009 01:31 PM


To

Doug Davis/Raleigh/IBM@IBMUS

cc

"public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>, "public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>" <public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>>

Subject

RE: Counter proposal for Issue 6398











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> [mailto:public-ws-resource-access-request@w3.org]<mailto:[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<mailto:public-ws-resource-access@w3.org>; public-ws-resource-access-request@w3.org<mailto: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<mailto:dug@us.ibm.com>
Geoff Bullen <Geoff.Bullen@microsoft.com<mailto:Geoff.Bullen@microsoft.com>>
Sent by: public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>

02/23/2009 10:38 PM




To

"public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>" <public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>>, "public-ws-resource-access-request@w3.org<mailto:public-ws-resource-access-request@w3.org>" <public-ws-resource-access-request@w3.org<mailto: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 Wednesday, 25 February 2009 21:51:33 UTC