W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

Re: Comments on the "drop response-only" Part 2 draft

From: David Hull <dmh@tibco.com>
Date: Mon, 30 Jan 2006 15:56:45 -0500
To: David Orchard <dorchard@bea.com>
Cc: noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org
Message-id: <43DE7D8D.8080409@tibco.com>
Dave,

Sorry, I'd meant to ask this sooner (I think it came up earlier as
well).  As I understand it, your current draft has /both/ the SOAPiness
of the response and the response itself optional.  Is this correct?  If
so, why?  This seems to say pretty much nothing about what the
underlying protocol provides:  You can send me a request, and I might
send something back, and it might be SOAP.

If I'm using WSA, I would like to know whether it's safe to use an
anonymous response endpoint.  If the binding in question supports
request-response, then I know that I can use anonymous and the server
can send me a response anonymously.  If I'm using "I might send you
something that might be SOAP", do I still have that guarantee?  If so,
it seems clear that this could not be bound on top of any of the several
one-way protocols that have been mentioned (not that I think it should
be -- as I've said, F&F should be available for such protocols).

As to the question of state machines or no, I'm not sure I care that
much.  As I've said [1], I don't think that MEPs alone capture what
needs to be captured about underlying protocols.  Charter questions
notwithstanding, it would be a shame to concentrate too narrowly on
MEPs, since it appears [1] that much of this is easily and usefully
captured.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html

David Orchard wrote:

>Thanks for the review.  I think that the small amount of comments shows
>how fairly straightforward it is to refactor the spec and how quickly it
>could proceed through the w3c process.  I can certainly live with
>keeping the response-only mep if that would gain people's support.  I
>again assert that the state machines have not served our community and
>have hindered the specification and deployment of new MEPs and bindings.
>
>
>The WG has now spent a fair amount of time examining the refactored MEP
>approach, and we've had some detailed comments.  It seems to me that we
>have largely and well covered the ground.  I thank the WG for the time
>and diligence in examining the options available.  
>
>I think that it's now time to call the question on which approach to
>follow.  We have sufficient information afore us to make a decision and
>proceed.  I'd like to query the WG members to find out who supports the
>state machineless MEP approach for our direction on the
>request-optional-response problem, vs who supports the state machinefull
>(status quo) MEP approach.
>
>Cheers,
>Dave  
>
>  
>
>>-----Original Message-----
>>From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
>>    
>>
>On
>  
>
>>Behalf Of noah_mendelsohn@us.ibm.com
>>Sent: Wednesday, January 25, 2006 7:10 AM
>>To: xml-dist-app@w3.org
>>Subject: Comments on the "drop response-only" Part 2 draft
>>
>>First, thanks again to Pete for providing the diff markup [1]  on
>>    
>>
>Dave's
>  
>
>>draft.  My earlier note pointed out that the diffs don't catch
>>    
>>
>everything
>  
>
>>of significance, but they are very helpful!
>>
>>Last week I took an action to provide detailed comments on Dave's
>>    
>>
>draft. A
>  
>
>>marked up copy is attached.  I started with Pete's diff and added my
>>    
>>
>own
>  
>
>>comments as additions.  The changes I made were:
>>
>>* My comments have a yellow background  and all contain the flag
>>***NOAH*** to make them easy to find.
>>
>>* So I could use yellow for my comments, I change the diff markup to
>>    
>>
>use
>  
>
>>an acqua color for additions.  It should be self evident when you look
>>    
>>
>at
>  
>
>>it.
>>
>>Sorry I didn't get this done earlier, but I hope it will still be
>>    
>>
>useful
>  
>
>>on the call.  This exercise has reconfirmed my personal position on
>>    
>>
>what
>  
>
>>we should and shouldn't do.
>>
>>* Because of its impact on the spec, because I believe the whole point
>>    
>>
>of
>  
>
>>MEPs is to allow applications to identify the differences and the
>>commonalities between what different bindings provide, and because I
>>continue to believe after this week's discussion that one way and
>>    
>>
>req/resp
>  
>
>>are deeply and appropriately different, I am strongly opposed to
>>    
>>
>merging
>  
>
>>request/response with response only.  Keep the two MEPs.
>>
>>* In other respects, I continue to think that the editorial direction
>>    
>>
>of
>  
>
>>dropping the detailed state machines is beyond what we need to do to
>>succeed now, but I'm not against it on technical or editorial grounds.
>>    
>>
>As
>  
>
>>noted in my comments, Dave has kept more detail in the binding than in
>>    
>>
>the
>  
>
>>MEP, and I think if we do decide to drop the full state machines the
>>    
>>
>MEP
>  
>
>>descriptions should at least have detail similar to what's in his
>>    
>>
>binding
>  
>
>>writeup.  Not a big deal I think.
>>
>>Bottom line:  I'd prefer to go with something closer to the draft I
>>    
>>
>sent
>  
>
>>[2].  I think it easily meets the requirements we've been given, and
>>    
>>
>is
>  
>
>>much closer to the minimal needed to declare success.  At this point
>>    
>>
>in
>  
>
>>the life of our workgroup, I think we should take such paths when
>>reasonably possible.  Stability is important, and I'm not convinced
>>    
>>
>that
>  
>
>>the state machines as documented are proving a big barrier to those
>>    
>>
>who
>  
>
>>need to figure them out.  I do agree that they are cumbesome.  I was
>>    
>>
>never
>  
>
>>enthusiastic about them and I'm still not, but they were a compromise
>>    
>>
>we
>  
>
>>made to get consensus of those who joined the group to create SOAP.  I
>>don't think we've had a tremendous amount of "new information" to
>>    
>>
>suggest
>  
>
>>reopenning our status quo on them.  If the group decides to do so, I
>>    
>>
>think
>  
>
>>Dave's editorial style signals a good direction, modulo the specific
>>details mentioned in comments.
>>
>>Note that I will be on the call today, but must send regrets for next
>>week.  Thank you
>>
>>Noah
>>
>>[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0124.html
>>[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
>>
>>
>>--------------------------------------
>>Noah Mendelsohn
>>IBM Corporation
>>One Rogers Street
>>Cambridge, MA 02142
>>1-617-693-4036
>>--------------------------------------
>>
>>
>>    
>>
>
>
>
>  
>
Received on Monday, 30 January 2006 20:57:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT