- From: Rice, Ed (ProCurve) <ed.rice@hp.com>
- Date: Tue, 28 Mar 2006 08:23:47 -0800
- To: <noah_mendelsohn@us.ibm.com>, "Roy T. Fielding" <fielding@gbiv.com>
- Cc: <www-tag@w3.org>
Thanks, I can appreciate that a SOAP message/reply can stand on its own. However, if I'm use the WSDL to discover and then use the service.. And the service doesn't match the WSDL my assumption is that its broken (as opposed to ignoring the WSDL because its least authoritative). While its tempting to debate the details of the SOAP model, the question really just ties back to the document that's in front of the TAG today. If we craft a document that ignores SOAP and xml then it seems to me that we cannot complain about the SOAP team not following the architecture. We either need to include SOAP in the document or else we need to explicitly spell out which types of documents this finding applies to. My 2c. -Ed -----Original Message----- From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] Sent: Tuesday, March 28, 2006 6:34 AM To: Rice, Ed (ProCurve); Roy T. Fielding Cc: www-tag@w3.org Subject: Re: Review of Authoritative Metadata Combining responses to a number of statements in this thread: Ed Rice wrote: > I believe by definition the WSDL is THEauthoritative source as to the > format of the doc when it comes to web services (please correct me if > I'm wrong). Absolutely not. The meaning of a SOAP message is completely defined by the SOAP Recommendation, and the specifications to which it delegates. For example, the SOAP Recommendation delegates the interpretation of particular SOAP headers to the specifications for those headers. WSDL doesn't enter into that picture at all. The message means what it means. Now, >if< you are using WSDL (which SOAP does not require), then the WSDL Recommendation and associated SOAP binding establishes the expectation that the messages will in fact be consistent with the WSDL, but the WSDL is not in any sense changing the meaning of a given message. If the WSDL tells you to expect something different, then there is an error, because that message isn't what you were expecting. The message still means the same thing. Furthermore, while it's certainly common practice for those using Web Services for WSDL to be employed equally at both ends of the connection, that's not required by SOAP architecture either. It's perfectly reasonable for the sender, for example, to use WSDL to help prepare code that sends a message. The receiver might have been written in a scripting language and might have been written without explicit reference to the WSDL. The SOAP Recommendation plus associated specifications for header and body should be enough for the receiver to either correctly interpret the message, or else to reliably determine that it cannot in fact understand the message. Perhaps a better example of a not fully self-describing document would be an XML instance to be validated with a DTD or Schema that supplies defaults for some element or attribute value. In that case, there is at least some sense in which you can't discover the full meaning of the document without reference to external descriptions. Still you want it to be the case that you can follow your nose from the document to get its authoritative meaning. The ability to explicitly name external DTDs and Schemas helps. XML's ability to state standalone="no" also helps to warn you of cases in which you may get the wrong interpretation if you don't find the external metadata. Still, you need to be very careful when defaulting values from a DTD or schema (the classic example is defaulting the units for some currency value; if you don't get hold of the right DTD or schema, you may incorrectly interpret the document as conveying, for example, dollars vs. pesos). Often it's a bad idea to use defaults. Roy Fielding wrote: > In any case, SOAP messaging has no connection to the Web, AFAICT, and > certainly doesn't adhere to Web architecture, so I have a hard time > caring whether or not it fits the finding (even when it does). I would buy the criticism that many Web services deployments ignore Web architecture, e.g. by failing to assign URIs to all resources that should have them, to interact with them using HTTP properly, etc. I don't think I buy the criticism as stated. I believe it is possible to use SOAP in a manner that's perfectly consistent with Web architecture. Care has been taken to assign and use sensible media types for SOAP envelopes, to enable support for GET, and to make it possible to use HTTP in the intended manner. If you take the trouble to assign URIs where you should, and to correctly choose between WebMethod=GET vs. POST (or PUT or DELETE for that matter), I don't see any way in which SOAP doesn't provide for first class use of the Web. Indeed, if you want to provide stock quotes in SOAP, you can serve them up as application/soap+xml envelopes from an Apache server responding to GET, and everything will work fine. If you put digital signatures in SOAP headers with those quotes, the media type description for application/soap+xml will point you to the SOAP Recommendation, which will tell you how to (follow your nose to) interpret those headers. You could in principle update those quotes using POST or PUT, and benefit from the SOAP header architecture, mustUnderstand processing, etc. All of this sounds pretty good to me. Roy Fielding wrote: > The XML Protocol Working group has never been subject to the TAG. TAG > recommendations are heartily disregarded by most of XML services, and > the fact that XML is completely unsuitable for a network protocol > isn't going to stop them either. Again a bit strong. In fact, the "RESTful" support in SOAP mentioned above was crafted in direct response to a request from the TAG, and was approved by the TAG. It took some real work and time to do that, and my impression is that everyone concerned felt that it was a pretty good example of constructive interaction between the TAG and a workgroup that had initially been set to misuse Web architecture. Now, if what you're saying is that such successes are too rare, and that too many of the workgroups doing Web Services have failed to work with the TAG in that spirit, or to take sufficient care to integrate with Web architecture, I would agree completely. I just think that in pointing to XML Protocols in particular you picked a bad example. Still, it certainly is the case that too many deployments of Web Services do ignore Web Architecture. My worry is less that the workgroups and specifications ignore the TAG and Web Arch, but rather that some of them do the minimum to get "past" us in the specs, then ignore those agreements when implementing. I think the marketplace is starting to tell them that's a mistake. We'll see. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- "Roy T. Fielding" <fielding@gbiv.com> Sent by: www-tag-request@w3.org 03/27/2006 06:08 PM To: "Rice, Ed (ProCurve)" <ed.rice@hp.com> cc: <www-tag@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: Re: Review of Authoritative Metadata On Mar 27, 2006, at 2:23 PM, Rice, Ed (ProCurve) wrote: > Yes, however, the WSDL is used in discovery as well. So the web > service > and the description can be 'discovered' which then points to the > existing web service. I don't see how that differs from looking at HTML anchors and img elements to discover Web resources. The context and content of the next request may change (e.g., the HTTP Accept headers will differ based on why the HTML engine is making the request). Nevertheless, each request is self-descriptive and independent of the prior context. The previous discovery action influences the next request, but doesn't define it. >> If the SOAP message is well-formed but incorrect, then the fact >> that the message >> references the WSDL allows the processor to determine that the >> message is incorrect. It does not change the meaning of the >> message. This would be in contrast to a SOAP message >> that doesn't reference the WSDL at all -- the request may succeed >> or fail, but the message >> is assumed correct because there is nothing (aside from the SOAP >> messaging format) to >> measure its correctness against. > > Ah, but isn't that my point? If the 'message is incorrect' based > on the > WSDL, but looking just as the xml document itself it looks ok.. Then > your making an external file the authority to determine if its correct > or not? Doesn't that go against section 3? No, because "determining if it is correct" is not related to the bit that is authoritative: determining what it claims to be. What the message claims to be may be wrong. Nevertheless, if the message claims to be one thing and isn't actually that thing, then the message is deemed incorrect. If the message were not authoritative in stating what it means, then processors would be compelled to run the request just in case the result might have its own idea of what is correct. What the message claimed would therefore not be relevant at all. >> In any case, SOAP messaging has no connection to the Web, AFAICT, >> and certainly doesn't >> adhere to Web architecture, so I have a hard time caring whether >> or not it fits the >> finding (even when it does). > > Interesting.. So web services have nothing to do with the web? Does > that > mean the XML Protocol Working Group is not subject to the TAG > then? ;) The XML Protocol Working group has never been subject to the TAG. TAG recommendations are heartily disregarded by most of XML services, and the fact that XML is completely unsuitable for a network protocol isn't going to stop them either. The W3C works on what the W3C members want to work on. > Seriously, I think the web is more than just HTML and since the TAG is > also being asked questions on things like XML versioning, semantic > web, > privacy, mobility etc.. We should either include them in our > discussion > or explicitly exclude them from the finding. I think the Web is the interconnected set of resources and the technologies that make that possible. SOAP is neither interconnected nor enabling of connectedness -- in fact, it is actively destructive. If people want to build IIOP with angle brackets, that's fine, but it shouldn't mean we need to water down the architecture to be inclusive. ....Roy
Received on Tuesday, 28 March 2006 16:24:02 UTC