RE: Review of Authoritative Metadata

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