RE: Web Service Definition [Was "Some Thoughts ..."]

IMO, we have to mention XML.  Charter is clear.  I've posted a separate
thread on this topic that we can switch discussions to.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of James M Snell
> Sent: Monday, March 04, 2002 9:25 AM
> To: www-ws-arch-request@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
>
>
> IMHO, The definition of a Web service SHOULD NOT be
> restricted to XML on
> the wire, but I would say that the vast majority of
> INTERESTING types of
> web services as far as this working group is concerned will
> involve XML on
> the wire.
>
> - James M Snell/Fresno/IBM
>     Web services architecture and strategy
>     Internet Emerging Technologies, IBM
>     544.9035 TIE line
>     559.587.1233 Office
>     919.486.0077 Voice Mail
>     jasnell@us.ibm.com
>  Programming Web Services With SOAP, O'reilly & Associates, ISBN
> 0596000952
>
> ==
> Have I not commanded you?  Be strong and courageous.  Do not
> be terrified,
>
> do not be discouraged, for the Lord your God will be with you
> wherever you
> go.
> - Joshua 1:9
>
> Sent by:        www-ws-arch-request@w3.org
> To:     "Champion, Mike" <Mike.Champion@softwareag-usa.com>,
> <www-ws-arch@w3.org>
> cc:
> Subject:        RE: Web Service Definition [Was "Some Thoughts ..."]
>
>
>
> Mike,
>
> Good points. Quick question:
>
> 1.      Are we restricting web services to XML on the wire or just
> Internet-protocols and marshalling ?
> 2.      If Yes (i.e. only XML) what about XHTML ?
> 3.      If yes, what about a browser which translates XML to HTML and
> after
> getting the input from a human sends back an XML ?
> Basically, my point is, we do not care if there is human
> interaction or
> not. Just that it is XML in, XML out.
>
> 4.      I agree with your definition, clearly defined
> vocabulary, schema,
> documented payload (with XML Schema or we are Ok with binary
> payload ?),
> defined and described using WSDL (includes interfaces and
> binding at the
> min), ... are all (mandatory) attributes of a web service.
> These all could
> be implied in standard definition and description/interact using
> Internet-protocols.
>
> <soapbox>
> Our definition *should* include what we all think would be in a web
> service. IMHO, we should strive for as specific as possible.
> </soapbox>
> cheers
>
> | -----Original Message-----
> | From: www-ws-arch-request@w3.org
> [mailto:www-ws-arch-request@w3.org]On
> | Behalf Of Champion, Mike
> | Sent: Saturday, March 02, 2002 10:13 PM
> | To: www-ws-arch@w3.org
> | Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> |
> |
> |
> | > -----Original Message-----
> | > From: Gaertner, Dietmar [mailto:Dietmar.Gaertner@softwareag.com]
> | > Sent: Saturday, March 02, 2002 4:23 PM
> | > To: 'jasnell@us.ibm.com'
> | > Cc: 'www-ws-arch@w3.org'
> | > Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> | >
> | >
> |
> | > Take for example the stockquote "service", which we all
> know and love
> | > returning, a plain HTML page. It can be implemented as an
> | application or
> | > component, identified by an URI
> | > (e.g. http://www.stockquote.org/quotes?symbol=xzy), can be
> | > described (the URI is enough
> | > of a description, if you wish), can be accessed by software via
> | > internet-based protocols, and the interaction does not
> | necessarily require
> | human
> | > interaction (the client could scrape the HTML).
> |
> | Hi Dietmar,
> |
> | I think this is exactly the kind of question that will clarify
> | what we want
> | to do, and *perhaps* allow a crisper definition of "web service"
> | somewhere
> | down the road.
> |
> | I personally think this is sortof a web service, but I wouldn't
> | dispute that
> | it is not what we want to focus on.  Let's talk about what would
> | make it a
> | web service:
> |
> | a) If the result were HTML with well-documented div/span tags
> | and class/id
> |    attributes to identify the   specific information being
> | returned (to make
> |    "scraping" easier)?
> | b) If the result was XML with the vocabulary clearly documented?
> | c) If the result was XML that matched a specific schema?
> | d) If the result was SOAP with the payload documented in
> human-readable
> | form?
> | e) If the result was SOAP and the payload documented with WSDL?
> | f) If URI encoded a SOAP invocation message and the result was
> | SOAP with the
> |
> |    payload documented with WSDL.
> |
> | OK, NOBODY would dispute that f) is a "web service", right?
> | Likewise, e) is
> | pretty clearly a "web service" under our charter; to insist that the
> | invocation is a SOAP message rather than a "human readable"
> URI would be
> | unacceptable to a signficant number of people in the W3C,
> | probably including
> | the Director (as I read his various musings on the Web Architecture,
> | anyway).
> |
> | d) is also a "web service" in what I take to be the consensus of
> | the WG as
> | expressed on teleconferences and the mailing list.  I doubt
> if very many
> | people here would vote against c) either.
> |
> | b) is getting fuzzy for most of us, I'll bet ... and a) is
> | really fuzzy.  I
> | personally would say that both are within our scope so long as the
> | documentation of the result is unambiguous enough to be
> used by ordinary
> | programmers to write the code to "scrape" the result into
> the calling
> | application's data structures.  To insist that the documentation
> | has to be a
> | schema or WSDL, I believe, leads to the "it's turtles all
> the way down"
> | problem, i.e., sooner or later, the documentation, code or schema or
> | whatever has to be sensible to a human being.  See Clay Shirky's
> | article at
> | http://www.xml.com/pub/a/2001/10/03/webservices.html ... and the
> | "turtles"
> | reference is explained at
http://www.the-funneled-web.com/Hawking.htm
|
| Nevertheless, I wouldn't insist on a) or b) being "web services"
| if that's
| what it takes to move forward.
|
|
|
|

Received on Monday, 4 March 2002 20:32:45 UTC