RE: What Are the Payoffs for SOAP? (WAS RE: Comments on draft-hol lenb eck-ietf-xml-guidelines-02.txt)

They can be precisely described, but if "unforeseen", then 
the information needed, the payoffs, is still imperfect. 
Of course, one can argue predictability based on memory 
but proving necessity and therefore forecasting payoffs, 
is still unobtainable.

I don't want to push this too far and clog these lists. 
I only want to point out that one side has claimed better 
payoffs for their architecture and that the other has 
yet to do so.  I don't accept that hiding assets behind 
a single point of interface (a single URI) is bad for the 
Web.  It may be bad for the selector of that architecture 
but without the payoffs, that is hard to decide.  As long 
as the URI of the WSDL is a proper URI, caveat emptor unless 
there are other penalties or payoffs.

The fear of SOAP/RPC is for some, predicated on the fear 
of lock-in to an inferior technology.  Given REST, 
if this is "perfect", then this is a third degree path 
dependency and, IMO, the duty of the TAG is as Fielding 
has stated, regardless of the intentions or short term 
payoffs to the W3C members who support REST.  He is right: 
that is why the TAG was formed.

len

-----Original Message-----
From: Jeff Bone [mailto:jbone@deepfile.com]

Sorry to weigh in on a nit but...  non-enumerable doesn't imply
"imperfect" information:  there are sets (such as applications on the
web) which can be discussed in very precise terms by talking about their
characteristics but which cannot be enumerated.

Received on Tuesday, 30 April 2002 17:50:43 UTC