Re: Suggested editorial changes to 2.6.1 The Feature Component

I'm going to be at the JBI and JAX-RPC face-to-face meetings today and
tomorrow, and there is no network access available at Sun.  I will try and
get to this in the next couple of evenings.

--Glen

----- Original Message ----- 
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: "David Booth" <dbooth@w3.org>; <www-ws-desc@w3.org>
Sent: Tuesday, March 09, 2004 11:39 PM
Subject: Re: Suggested editorial changes to 2.6.1 The Feature Component


>
> 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 07:25:21 UTC