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

Re: Suggested editorial changes to 2.6.1 The Feature Component

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Wed, 10 Mar 2004 10:39:26 +0600
Message-ID: <07cc01c40659$ced4e010$c8d418ac@watson.ibm.com>
To: "David Booth" <dbooth@w3.org>, <www-ws-desc@w3.org>

Hi David,

Can you and Glen merge your proposed changes and commit the stuff
to another branch as with the other changes you're doing? That'll
be the easiest in terms of getting these merged.

Jean-Jacques, can you please track the P&F related changes and
merge them into the editor's draft when its ready (and approved
by the WG)?

Thanks,

Sanjiva.

----- Original Message -----
From: "David Booth" <dbooth@w3.org>
To: <www-ws-desc@w3.org>
Sent: Wednesday, March 10, 2004 10:05 AM
Subject: Re: Suggested editorial changes to 2.6.1 The Feature Component


>
> [Oops, I hit the send button too soon.]
>
> Similarly, for sec 2.7.1 The Property Component I suggest changing:
> [[
> The properties of the Property component are as follows:
>      * {name} A URI as defined by [IETF RFC 2396].
>      * {required} A boolean value.
>      * {value constraint} A type definition constraining the
>          value of the property.
> ]]
>
> to something like:
> [[
> The properties of the Property component are as follows:
>      * {name} A URI as defined by [IETF RFC 2396].  This URI SHOULD be
>          dereferenceable to a document that directly or indirectly defines
>          the meaning and use of the Property that it identifies.
>      * {required} A boolean value.  If the {required} property is true,
>          then the requester agent MUST use the Property that is identified
>          by the {name} URI.  Otherwise, the requester agent MAY use the
>          Property that is identified by the {name} URI.  In either case,
>          if the requester agent does use the Property that is identified
>          by the {name} URI, then the requester agent MUST obey all
semantics
>          implied by the definition of that Property.
>      * {value constraint} A type definition constraining the
>          value of the property.
> ]]
>
>
>
> At 10:53 PM 3/9/2004 -0500, David Booth wrote:
>
> >Re: 2.6.1 The Feature Component:
> >I think the semantics of the Feature Component need a little
> >clarification.  In particular, I think we need to be clear about what
> >obligations are placed on which agent (i.e., on the service or on the
> >requester agent that uses the service).  Also, there is currently a
> >sentence saying:
> >[[
> >Unless otherwise specified, recognizing a feature's URI is assumed to be
> >semantically equivalent to understanding the feature's specification.
> >]]
> >It isn't clear to me what this sentence really means.  I suggest deleting
it.
> >Finally, (following WebArch advice) we should say that there should be a
> >document at the end of the URI, explaining that feature.
> >
> >Section 2.6.1 currently states:
> >[[
> >A feature component describes an abstract piece of functionality
typically
> >associated with the exchange of messages between communicating parties.
> >Although WSDL poses no constraints on the potential scope of such
> >features, examples might include "reliability", "security",
"correlation",
> >and "routing". The presence of a feature component in a WSDL description
> >indicates that the feature is either accepted or required in particular
> >interactions.
> >
> >  Features in the Feature component are identified by their URI. Unless
> > otherwise specified, recognizing a feature's URI is assumed to be
> > semantically equivalent to understanding the feature's specification.
> >
> >The properties of the Feature component are as follows:
> >     * {name} A URI as defined by [IETF RFC 2396].
> >     * {required} A boolean value.
> >]]
> >
> >I suggest changing these paragraphs to something like:
> >[[
> >A feature component describes an abstract piece of functionality
typically
> >associated with the exchange of messages between communicating parties.
> >Although WSDL poses no constraints on the potential scope of such
> >features, examples might include "reliability", "security",
"correlation",
> >and "routing". The presence of a feature component in a WSDL description
> >indicates that the service supports the feature and may require a
> >requester agent that interacts with the service to use that feature.
> >Each Feature is identified by a URI.
> >
> >The properties of the Feature component are as follows:
> >     * {name} A URI as defined by [IETF RFC 2396].  This URI SHOULD be
> >         dereferenceable to a document that directly or indirectly
defines
> >         the meaning and use of the Feature that it identifies.
> >     * {required} A boolean value.  If the {require} property is true,
> >         then the requester agent MUST use the Feature that is identified
> >         by the {name} URI.  Otherwise, the requester agent MAY use the
> >         Feature that is identified by the {name} URI.  In either case,
> >         if the requester agent does use the Feature that is identified
> >         by the {name} URI, then the requester agent MUST obey all
semantics
> >         implied by the definition of that Feature.
> >]]
> >
> >I *think* these changes reflect the intent of the WG.  Do others agree?
> >
> >
> >--
> >David Booth
> >W3C Fellow / Hewlett-Packard
> >Telephone: +1.617.253.1273
>
> --
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
Received on Tuesday, 9 March 2004 23:41:05 GMT

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