RE: proposed revision text for sect 1.5.3

I don't think that it is unreasonable to recall to mind every once in a
while that somewhere, sometime, there might be a program running that
actually DOES something.

-----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net] 
Sent: Monday, June 02, 2003 9:24 AM
To: Cutler, Roger (RogerCutler); Christopher B Ferris; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: 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:45:25 UTC