- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Tue, 16 Jul 2002 12:40:18 +0100
- To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
It seems from the minutes that I have an (implicit) action to summarise the discussion on LC Issues #227/#228. > 227 > Henrik: Wait for Stuart. Just too many emails. > DavidF: Stuart should provide a summary of discussion. > > Postponed. Wait for Stuart. > > 228 > MarcH: related to 227. The thread [0] that arose from my posting [3] is large and in places blossoms into discussion of: extension and layering of protocols; REST and tunnelling; and protocol agnostisism. Many postings are not focussed directly on the LC comments in [3]. Most of the focussed discussion has occurred between Stuart, Mark Baker, Noah and Marc. Other WG members (and former members) have participated in the discussion: Jean-Jacques, Jacek, Mike Champion, Chris Ferris and Glen Daniels. I have tried to offer a fair summary of the main positions held and apologise to anyone who feels that I have unfairly represented their position (or indeed my own) or who feels that have made important points or statements of position that I have failed to capture. Regards Stuart Williams -- Summary of email thread on Web Method Feature [0]. ------------------------------------------------- The bulk of this summary is focussed on positions with respect to Last Call Issue 227 [19]. There seems to be reasonable concensus [8, 10] that the spec. would benefit from further editorial clarification on the dependencies between the Web Method feature and the Request-Reponse and SOAP-Response MEPs, Issue #228 [20] Stuart W: --------- Our framework[1] sets the expectation that users of a binding can make use of the binding provided features that they understand without *having* to use those binding provided features that they don't understand or that they choose not to use. Our HTTP binding, as specified, runs counter to that expectations because it requires (implicitly due to 1st row of table 15 [2]) that the binding user understand and *use* the Web Method feature in order to successfully use either SOAP-Response or Request-Response. The behaviour of the binding is at-best undefined if the feature is not used to initiate a message exchange. The change requested [3] is for Part 2 Table 15 to include defaults of POST and GET for the HTTP method when used in conjunction with the Request-Response and SOAP-Response MEPs respectively *iff* a message exchange is initiated without the Web Method feature being used. These defaults are in line with the narrative in Part 2 Section 6.4.3 [4]. If the Web Method feature is used, it takes precidence in the selection of HTTP method. -- Marc H: ------- Supportive of Stuart's position [5]. Would also like to see http method selection based on MEP and more abstract feature/properties such as the 'safety' expectations of the initiating SOAP node [5,6]. Web Method and MEP are not really othogonal [6]. -- Jean-Jacques and Jacek ---------------------- Have both indicated some support for the change requested by Stuart [16],[17]. -- Mark Baker: ----------- MEP and (web?) method are 'a priori' orthogonal [7] meaning that in principle any (Web?) method may be used with any MEP, however, the act of creating a binding to a particular MEP introduces further constraints specific to that binding[8]. Inference of MEP follows from chosen method (at least for HTTP) .The inference cannot be drawn the other way round [7]. Would support some editorial clarification of the dependencies between MEP and Web Method feature imposed by HTTP binding [8]. Strongly opposes Marc H's position on refactoring Web Method feature as a 'safe' exchange feature [13]. Strong preference to retain the status-quo or even strengthen requirement that the Web Method alway be used in conjunction with the HTTP binding [14]. Cites agreement with Sam Ruby (Apache Axis developer) on this point[14], however, Sam questions whether agreement was in fact reached [21]. -- Noah Mendelsohn: ---------------- Supports Mark Baker's position [9,10] regarding inference of Method from MEP. Preference to maintain the status-quo. "...the design is fine as it stands." [10]. Willing to 'live' with requested change [3] "if and only if it does not risk sending us to last call again." [15] The requested changes really only affect our abstract description and make no really requirements on a typical user [11] [Stuart concurs with this last point[12]]. Would support some editorial clarification on the allowable combinations/dependencies between MEP and Web Method feature. [10] Opposes Marc H's position on refactoring the Web Method feature as a 'safe' exchange feature [18] on the grounds: 1) "I think that "safe" is not what we're trying to say, although it is part of it."; and 2) that it risks going back through last-call. Chris Ferris ------------ Supports Noah's position in opposition to Marc's position on refactoring Web Method as 'safe' exchange feature [22]. -- [0] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/thread.html#0 [1] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew [2] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#tabreqstateinitfields [3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0000.html [4] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#webmethodstatemachine [5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0020.html [6] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0084.html [7] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0016.html [8] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0022.html [9] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0017.html [10] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0026.html [11] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0034.html [12] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0036.html [13] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0122.html [14] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0129.html [15] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0128.html [16] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0125.html [17] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0126.html [18] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0127.html [19] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x227 [20] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x228 [21] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0131.html [22] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0130.html
Received on Tuesday, 16 July 2002 07:40:58 UTC