W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2002

RE: Open Content Model

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 26 Apr 2002 15:15:45 -0700
Message-ID: <330564469BFEC046B84E591EB3D4D59C05C0630F@red-msg-08.redmond.corp.microsoft.com>
To: "Christopher Ferris" <chris.ferris@sun.com>, "Glen Daniels" <gdaniels@macromedia.com>
Cc: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>
In re-reading WSDL 1.1 more carefully, I think I've been using
wsdl:required incorrectly as a synonym for mustUnderstand.  (Replace
mustUnderstand for wsdl:required in
http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0150.html, for
instance.)

WSDL 1.1 implies that wsdl:required is only defined on extension
elements which describe bindings, and affects the semantics of those
bindings.  This sounds a lot different than mustUnderstand, which is
used to mark behavior-changing language extensions.

For the purposes of the extensibility/open content model discussion,
mustUnderstand seems the more relevant concept.  SOAP provides for such
a marker (soap:mustUnderstand) PLUS it details a processing model which
uses this marker.  Similarly, XSLT provides a marker
(extension-element-prefixes) and a processing model which uses the
marker.

If we allow behavior-modifying extensions to WSDL, a mustUnderstand
mechanism is a good way to increase interoperability because it only
allows processors to have two outcomes - a result as specified in WSDL
and all the required extensions, or an error.

Perhaps we should add clarification of wsdl:required separately to our
issues list.

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Friday, April 26, 2002 8:59 AM
> To: Glen Daniels
> Cc: 'Sanjiva Weerawarana'; 'www-ws-desc@w3.org'
> Subject: Re: Open Content Model
> 
> Glen,
> 
> I think we're saying the same thing, but my point is that
> there are two perspectives; sender and receiver. 'required'
> applies to sender, 'mustUnderstand' applies to the receiver
> (at least SOAP:mustUnderstand is defined in that manner).
> I'm not saying that there is fixed/static content, and of
> course there is some degree of "understanding" involved in
> incorporating a given SOAP header block, but the semantics
> are different. On the one hand, you're saying "if you don't
> send this header, I will complain" and on the other you're
> saying "and by the way, when I send my response, you'd better
> be prepared to SOAP:mustUnderstand" this SOAP header block.
> 
> Using the same term for each of these I think makes for confusion.
> I'd prefer if there were two semantics that could be clearly
> distinguished. It may have value. Just using one of either
> 'required' or 'mU' makes things a little less clear, at least
> from my perspective.
> 
> Cheers,
> 
>   Chris
> Glen Daniels wrote:
> 
> > Hi Chris!
> >
> >
> >>wsdl:required is instructing a *sending* SOAP node to include
> >>the required header block. I don't think that it is necessarily
> >>the case that the sending SOAP node understand (in the SOAPish
> >>sense) the header block it inserts in a message destined for
> >>another SOAP node.
> >>
> >
> > Really?  Then what would be the point of bothering to have the
header in
> there in the first place?  Why would I ever put in my description
> something that says "you need to send me a SOAP header that contains
the
> integer '7', with such-and-such a QName"?  If everyone who uses this
> service is going to do that, why waste the bandwidth - I could just
assume
> that that data was there at the receiving end on all calls, no?  The
same
> would be true of any constant headers (which may be the only ones that
> could be sent without understanding the semantics, I think).
> >
> > If the header values are NOT constants, then I would posit that the
> sender should in fact understand what they're doing - i.e. if you're
> supposed to send a header with a public-key certificate in it, you had
> better understand how to get one of those from an appropriate place if
you
> hope the interaction to succeed.
> >
> >
> >>Where mU would come into play might be the case of a service
> >>endpoint that intends on including some SOAP header block
> >>in a response message (in the case of request-response)
> >>and it would be indicating in this case that the originator
> >>of the request message had better be capable of understanding
> >>(in the SOAPish sense) the response header block.
> >>
> >
> > There is certainly a case to be made for "up-front" descriptions of
> headers which might be sent on a response message, but I still think
this
> could be captured with a single attribute.
> >
> >
> >>Ergo, I think you may need both wsdl:required and
wsdl:mustUnderstand,
> >>required for inbound messages and mustUnderstand for outbound
> >>response messages.
> >>
> >
> > I'm still not yet convinced that they aren't the same thing.
> >
> > --Glen
> >
> >
> 
Received on Friday, 26 April 2002 18:16:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:19 GMT