- From: <jones@research.att.com>
- Date: Thu, 22 Aug 2002 09:43:17 -0400 (EDT)
- To: henrikn@microsoft.com, noah_mendelsohn@us.ibm.com
- Cc: distobj@acm.org, jacek@systinet.com, jones@research.att.com, marc.hadley@sun.com, moreau@crf.canon.fr, skw@hplb.hpl.hp.com, xmlp-comments@w3.org
Henryk, MarkB, Stuart, Noah: I like the re-formulation of the resolution text that Noah provided (below). Reading ahead through the subsequent messages sent by MarkB and Stuart, it sounds like there is still a philosophical debate on how specifically aware the sending application (vs. the sending node) must be of the particular webMethod chosen. I agree with Stuart and Noah that we have generally stayed away from being prescriptive about such details and that was not (in my recollection) an issue that was directly in focus in the FTF discussion [else it obviously would have engendered this particular debate at the FTF]. I would suggest closing this issue with Noah's text. MarkB can raise a separate issue if necessary on this particular point, but this will allow us to get past the bulk of 227. Whew... --mark Mark A. Jones AT&T Labs Shannon Laboratory Room 2A-02 180 Park Ave. Florham Park, NJ 07932-0971 email: jones@research.att.com phone: (973) 360-8326 fax: (973) 236-6453 From: noah_mendelsohn@us.ibm.com To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> Cc: distobj@acm.org, jacek@systinet.com, jones@research.att.com, marc.hadley@sun.com, moreau@crf.canon.fr, skw@hplb.hpl.hp.com, xmlp-comments@w3.org Subject: RE: issue 227 Date: Wed, 21 Aug 2002 18:15:14 -0400 Well, I've read the whole thread now, and I'm still most comfortable with analysis I gave at [1]. I was at the FTF, wrote the minutes in question, and am 95% confident of what we decided and why. I think Stuart has signalled his willingness to live with this interpretation, and has heard nobody else object. What possibly remains in question is better resolution text of issue 227. How about: "At it's face to face meeting in Palo Alto (July 31 - Aug 2, 2002), the workgroup agreed to the following resolution of issue 227: * A binding specification MAY require that certain "feature(s)" be used in particular situations when using the binding. In other words, the binding specification may decline to provide any means of operation when such feature is not used. * Whether use of a feature is optional or mandatory (in the sense described above), a feature must always be used correctly when used. In other words, the use by the binding specification must be consistent with the specification for the feature itself. * Issue 227 in particular questions such mandatory use of the webMethod feature by the HTTP binding. The WG has voted to make no change in this mandatory use of the webMethod feature by the http binding. The HTTP binding continues to mandate that a sending node determine the webMethod (e.g. POST, GET) to be used when transmitting a non-Response message. (Note that the entire property-based binding framework is abstract: at no point does the HTTP binding attempt to describe a particular API or implementation structure, so this resolution says nothing about whether method names such as GET would be supplied explicitly or otherwise on some particular API; it merely mandates that the sending node determine the method in some implementation specific manner, and it declines to supply any standard way of inferring the method from other information provided with the message to be transmitted." Does that do it? If so, I'd like to propose that we offer this to the WG and move on. I believe it exactly matches what the WG voted, and clarifies the various ambiguities that have been perceived by participants in this discussion. What think you all? [1] http://lists.w3.org/Archives/Public/xmlp-comments/2002Aug/0063.html ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Thursday, 22 August 2002 09:43:55 UTC