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

Re: Suggested editorial changes to 2.6.1 The Feature Component

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Wed, 10 Mar 2004 09:54:43 +0100
Message-ID: <404ED7D3.7080705@crf.canon.fr>
To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Cc: David Booth <dbooth@w3.org>, www-ws-desc@w3.org

Sure, will travel.

JJ.

Sanjiva Weerawarana wrote:

> 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 Wednesday, 10 March 2004 03:55:21 GMT

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