Re: Completeness

+1!

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 09/28/2002 08:33:34 PM:

> 
> At 04:37 PM 9/28/2002, Mark Baker wrote:
> 
> >On Sat, Sep 28, 2002 at 08:19:49AM -0600, Champion, Mike wrote:
> > > >  Show me a problem that Web services claim to
> > > > solve that the Web doesn't have a solution for.
> > >
> > > The same can be said (proven?) about a Turing machine.  I can 
imagine how
> > > the REST operations can be mapped onto Turings operations, or onto 
Codd's
> > > relational algebra, thus I will believe from my little thought 
experiment
> > > that you can solve any problem with the Web.  Your point is well 
taken.
> >
> >Right!
> >
> > > But uhh, so what?
> >
> >So, if you and David agree with that, I don't see how it can be claimed
> >that the Web is for humans.  If it's complete, then it's complete.
> >This means that all tasks have at least one solution within the
> >constraints of each architectural style.
> 
> All turing equivalent systems CAN be made to do the same thing. It's 
just a 
> small matter of programming :-). The question is how hard is it. And how 

> usable is the end result. In particular, not all computationally 
complete 
> systems have the same performance, storage requirements, etc., 
properties, 
> when applied to a given problem. Your only guarantee is that they will 
> eventually compute the answer.
> 
> The way I interpret David's argument is that screen scraping html pages 
in 
> order to fill in forms, while theoretically achievable by a 
computationally 
> complete system is "too hard" to do today. We do have natural language 
> understanding systems that can be made to do useful things in 
constrained 
> worlds, but I've spent the last 20 years being in the state of having to 

> wait another 3-5 yrs. (Always doing a get is not hard, but figuring out 
> what the bag of bytes you get means so that a program can do something 
> useful with them, is.)
> 
> >The BIG "So what?" here, is that this solution on the Web has the same
> >properties that made the Web succeed, because it respects the
> >constraints of the Web that induce those properties.  Since a Web
> >services solution does not, because it does not follow some of those
> >constraints (specifically, uniform interface) it will not share those
> >same properties.
> 
> Logic foul!!!
> 
> p=respecting all the constraints
> q=success (has the desired properties)
>    p->q most assuredly does not imply ~p -> ~q (except in advertising:-)
> 
> 
> 
> The only way the argument could be correct if it is a tautology.
>   p->q and ~p -> ~q
> which is the same as saying p <-> q
> 
>   Success is achievable iff all the constraints are followed.
> To my mind, this is just a restatement of "the one true way" argument 
and 
> supportable only by the tautological assertion.
> 
> Please note: I am not saying that there is nothing useful to learned 
from 
> REST. Quite the contrary. I am in complete agreement with David, and all 

> the others who point out that there are many useful lessons to be 
learned 
> from it. And it would be quite profitable to incorporate the ones which 
> apply in a web services context. Just like it is quite profitable to 
> incorporate the many other lessons that have been learned from 20+ years 
of 
> distributed computing experience. (Heather pointed out several.)
> 
> I'm just tired of the dogma.
> 
>    jeff
>