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

"Roy T. Fielding" <>
Sent by:
03/27/2006 06:08 PM
        To:     "Rice, Ed (ProCurve)" <>
        cc:     <>, (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.


Received on Tuesday, 28 March 2006 14:34:28 UTC