W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Re: pls review text added for what "required" means

From: Amelia A Lewis <alewis@tibco.com>
Date: Thu, 29 Jul 2004 10:06:21 -0400
To: David Booth <dbooth@w3.org>
Cc: www-ws-desc@w3.org
Message-id: <20040729100621.5dbc3d8d.alewis@tibco.com>

Ugh, when did we get this awful "requester agent" and "provider agent"
language?  I see it's already in the spec.  bleah.

The node interacting with a service is not always a 'requester'.  The
service is, generally speaking, a provider, but I fail to see the need for
a synonym at the moment.

Sorry to carp.  But <valspeak>gag me with a misapplied paradigm</valspeak>
was my initial reaction.

On Wed, 28 Jul 2004 17:09:54 -0400
David Booth <dbooth@w3.org> wrote:

> 
> Sanjiva,
> 
> Actually, since the processor conformance section only pertains to the 
> requester  agent rather than the provider agent, and this material
> pertains to the provider agent, I think it may make more sense to put it
> in section 6 (Language Extensibility).
> 
> In section 6, I suggest modifying the first sentence of the opening 
> paragraph as follows:
> [[
> In addition to extensibility implied by the Feature and Property
> components described above, the schema for WSDL has a two-part
> extensibility model based on namespace-qualified elements and
> attributes.]]
> 
> Then in section 6.1.1 (Mandatory extensions) I suggest changing the
> second paragraph to:
> [[
> An extension that is NOT marked as mandatory MUST NOT invalidate the 
> meaning of any part of the WSDL document. Thus, a NON-mandatory
> extension merely provides additional description of capabilities of the 
> service.   This specification does not provide a mechanism to mark 
> extension attributes as being required.  Thereore, all extension
> attributes are NON-mandatory.
> ]]
> (The sentence about "Furthermore, any extension that is NOT marked as 
> mandatory and which is NOT understood, MUST be ignored" was unnecessary 
> here, as that is covered in section 8 Conformance .)
> 
> Then after the Note, add:
> [[
> If a WSDL document declares an extension, Feature or Property as
> optional (i.e., NON-mandatory), then the provider agent MUST NOT assume
> that the requester agent supports that extension, Feature or Property,
> _unless_ the provider agent knows (through some other means) that the
> requester agent has in fact elected to engage and support that
> extension, Feature or Property.
> 
> On the other hand, a requester agent MAY engage an extension, Feature or
> 
> Property that is declared as optional in the WSDL document.  Therefore,
> the provider agent MUST support every extension, Feature or Property
> that is declared as optional in the WSDL document, in addition to
> supporting every extension, Feature or Property that is declared as
> mandatory.
> 
> NOTE
> If finer-grain, direction-sensitive control of extensions, Features or 
> Properties is desired, then such extensions, Features or Properties may
> be designed in a direction-sensitive manner (from requester or from
> provider) so that either direction may be separately marked required or 
> optional.  For example, instead of defining a single extension that
> governs both directions, two extensions could be defined -- one for each
> direction.]]
> 
> 
> At 02:58 AM 7/27/2004 +0600, Sanjiva Weerawarana wrote:
> 
> >Hi,
> >
> >In fullfilling the following editorial action item:
> >
> > > ?ED       2004-06-17: Editors to incorporate David Booth's
> > > clarification
> > >                       in section 8.3 about what required means on
> > >                       MTOM feature.
> >
> >I put the following into section 8.3 (of part1):
> >
> >           <note><p>If a WSDL document declares an extension or feature
> >           as optional, then if that extension or feature could apply
> >           to messages sent by the provider agent as well, then the
> >           provider agent MUST NOT send any messages that requires the
> >           requester agent to support that extension or feature. The
> >           requestor, on the othe hand, MAY engage that extension or
> >           feature in messages it sends to the provider.</p>
> >
> >           <p>If finer-grain control of extensions and features is
> >           desired then such extensions and features must be designed
> >           in a direction (from requestor or from provider) sensitive
> >           manner so that any direction may be marked required or
> >           optional.</p></note>
> >
> >I didn't make that MTOM specific because that doesn't make sense in
> >part1 IMO.
> >
> >Comments please.
> >
> >Sanjiva.
> 
> -- 
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
> 


-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Thursday, 29 July 2004 10:06:36 GMT

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