Re: proposed revision text for sect 1.5.3

I think the word "expose" is being used backwards.  Usually,
it's programs that *expose* an interface.  Since this is about
descriptions of interfaces primarily, exposure doesn't play.

Also, it may be possible to do without the word "functionality"
altogether: http://www.oreillynet.com/pub/wlg/3189#p7.  It seems
to work for Mr. Ducharme.

Then, thinking about the rich meaning encapsulated in the term
"endpoint", I wondered if anything more complicated than:

    "It also specifies the service endpoints."

was called for.  The excess (?) words in the original version,
and still preserved in Roger's bifurcation of same, are calling to
mind that there is a program running.  But in the name of "service
orientation", we're supposed to stop harping on implementations,
right?

Cheerio,
Walden

----- Original Message -----
From: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
To: "Christopher B Ferris" <chrisfer@us.ibm.com>; "Champion, Mike"
<Mike.Champion@SoftwareAG-USA.com>
Cc: <www-ws-arch@w3.org>
Sent: Sunday, June 01, 2003 3:02 PM
Subject: RE: proposed revision text for sect 1.5.3


>
> I think the sense is OK, but I'm still having trouble with the last
> sentence purely on stylistic grounds.  For some reason I have to read it
> four or five times before the meaning comes through.  Is this just a
> personal blind spot?  Certainly changing "that each expose" to "each of
> which exposes" would help me.  But "to the service functionality
> implemented by the provider agent" is still very difficult for me to
> wrap my mind around.
>
> How about:
>
> It also specifies the set of endpoints each of which exposes a network
> addressable binding of the interface.  These endpoints provide access to
> the functionality
> implemented for the service by the provider agent.
>
> Or something like that.  Splitting it up into more sentences seems a
> good idea to me.
>
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Saturday, May 31, 2003 7:05 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: RE: proposed revision text for sect 1.5.3
>
>
>
> Mike Champion wrote on 05/31/2003 04:44:10 PM:
>
> >
> >
> >
> > > -----Original Message-----
> > > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > > Sent: Saturday, May 31, 2003 10:12 AM
> > > To: www-ws-arch@w3.org
> > > Subject: proposed revision text for sect 1.5.3
> > >
> > >
> >
> > Basically, +1 to Chris' proposal -- I agree with the rationale and
> > think that the proposal is an improvement.
>
> Thanks!
>
> > >
> > > <proposed>
> > > 1.5.3 Service Description
> > > The mechanics of the message exchange are documented in a
> > > Web service description (WSD). (See Figure 1.) The WSD is an
> > > extensible  machine
> > > processable specification of the message infosets and features that
> > > comprise the Web service's interface and the binding(s) of those
> > > message infosets
> > > and features to the serialization format(s) and transfer or
> transport
> > > protocol(s)
> > > supported by the Web service's endpoint(s). It also specifies the
> > > set of endpoints that each expose a network addressable binding to a
>
> > > specific serialization format and transport or transfer
> > > protocol of the
> > > Web service interface to the service functionality implemented by
> the
> > > provider agent.
> > > </proposed>
> >
> > A couple of points.  First, this section 1.5 is the infamous "what is
> > a
> web
> > service" section, so the definition of WSD should be very narrowly
> focused
> > on what the minimally necessary degree of description MUST be to be a
> web
> > service, not  what the criteria  for a good "web services description
>
> Not sure that I follow. I was describing the aspects of WSDL that I
> think are important. And, for the record, I am still very much opposed
> to any
> effort
> to generalize "Web service" for purposes of this architecture document
> that does not have SOAP and WSDL at its core. IMO, interoperability is
> why we are doing Web services in the first place, and you cannot achieve
> interop if there are thirty one flavors of Web service technology
> stacks.
>
> > language" SHOULD be. So, "extensible" is not really necessary here,
> although
>
> Ok, I could live with removing that.
>
> > of course WSDL should be extensible.  Sorry if that is overly pedantic
>
> :-)
> > On the other hand, let's make sure we hit the all  basic points of the
>
> WSDL
> > conceptual model that we really need -- the formal description of a
> set
> of
> > concrete operations, collected into one or more machine-processable
>
> I would not at all be comfortable with the term operation used in this
> context. I much prefer using the language I had which intentionally does
>
> not
> use the term operation.
>
> > interface, bound to a specific network protocol, and associated with
> an
> > addressable endpoint.  Then there's Roger's point about the sentence
> being
> > awkward ...
>
> Upon further review, I agree it could be at least two sentences:)
>
> >
> > So, a proposed further tweak:
> >
> >  1.5.3 Service Description
> > The mechanics of the message exchange are documented in a Web service
> > description (WSD). (See Figure 1.) The WSD is a formal specification
> of
> a
> > Web service's interface: the operations exposed to external users, an
> > interface definition of the XML infosets of the data that is passed to
>
> and
> > from the service, the bindings of the interface onto specific
> messaging
> > protocols, and the set of "endpoints," i,e. associations of the
> interface
> > definitions with the network address of an agent that implements the
> > interface.
> >
>
> <take3>
> 1.5.3 Service Description
> The mechanics of the message exchange are documented in a
> Web service description (WSD). (See Figure 1.) The WSD is an extensible
> machine processable specification of the Web service's interface.
> It defines the messages that comprise the interface and any features
> associated with those messages, such as security and reliability.
> It also defines the binding(s) of those messages and features to
> the serialization format(s), such as SOAP, and transfer or transport
> protocol(s), such as HTTP, supported by the Web service's endpoint(s).
> It also specifies the set of endpoints that each expose a network
> addressable binding of the interface to the service functionality
> implemented by the provider agent.
> </take3>
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
>
>
>
>

Received on Monday, 2 June 2003 10:20:12 UTC