RE: Semantics of WSDL vs. semantics of service

Carine,

First, you are right, Web services are for "interoperable" _machine to
machine_ interaction. However, this means such interoperable interaction can
be implemented by different approaches. Dr. Haas, the Team Lead of this
group, has a presentation "Reconciling Web Services and REST Services"
http://www.w3.org/2005/Talks/1115-hh-k-ecows/ in which he said both SOAP and
REST are part of the definition on "Web services". I love and deploy both
approaches, so if someone said I don't like SOAP, that's not true. However,
it is true that we can find an easy way to replace the full functionalities
offered by SOAP and WSDL. As demonstrated in my last email, we can deploy
the same functionality by either SOAP or REST services. Although some people
may not like the OSRR approach, they can ignore it but they cannot deny OSRR
can be used by ALL users other than just programmers to deploy the power of
distributed computing resources over the Internet. My research started from
SOAP/WSDL Web services, but the result makes many people unhappy obviously.
I know not everyone likes the truth in this world and we all know the story
of Emperor's New Cloth.

Secondly, you are right again, a machine is (still) not intelligent enough
to understand which kind of XML document it has to send to the service. So
that's why OSRR design a service description document as detailed guidelines
for users and agents to deploy the service. This XML document is designed by
service provider (supposed you are a provider). If a requester send you a
service request XML document by following your specifications in the service
description templates, can you understand such a request that you have
specified in advance? This means the server machines are waiting for such a
pre-defined XML document as the input command to invoke certain tasks on the
server machine. Thus the server will ignore any other kind of XML documents.
So you do NOT need to care about such issues since the communication between
service providers and service requesters are based on the pre-defined
specifications formulated by service provider. Machine is not intelligent
enough since it cannot understand all kind of XML documents that may be sent
to it, but machine DOES have such intelligence to understand any pre-defined
templates and commands specified by the providers themselves.

At last, I know I said something different from the others. Such as what is
service composition? My definition is different from the so-called
"standard" meaning, but I think it is more realistic and understandable for
all users who are not programmers and AI professionals to consume Web
services. As application developers and service providers, we have to
consider how ALL users can understand and deploy the services. The users are
the customers or consumers and most of them are not programmers. If SWS
people ignore such a fact, the result is obivous since such SWS approaches
cannot be acceptable and understandable to the general community which is
the majority to access and use the Internet. It's not kidding...

Best regards,

Xuan

-----Original Message-----
From: Carine Bournez
To: Shi, Xuan
Cc: 'public-sws-ig@w3.org '
Sent: 3/16/06 3:41 AM
Subject: Re: Semantics of WSDL vs. semantics of service

On Wed, Mar 15, 2006 at 11:48:38PM -0500, Shi, Xuan wrote:
[...]
> 
> Also Carine has a concern in her reply message
> http://lists.w3.org/Archives/Public/public-sws-ig/2006Mar/0048.html
> 
> All such concerns were covered in the paper "Rebuilding the Semantic
Web
[...]
> To deploy the service, you have to compose an XML document as service
> request. First, write the following line in any text editor:

WHAT?! you must be kidding...
Web services are for _machine to machine_ interaction. A machine is
(still) not intelligent enough to understand which kind of XML document
it has to send to the service, so at some point, you need to specify
that 
messages have to follow a given schema. This specification of the
message
format fits into the WSDL.
If you want the *user* to use a service, just use XForms, don't bother
about descriptions.

Received on Thursday, 16 March 2006 16:37:18 UTC