RE: Section 1.6 and REST - Can we make this more clear and useful ?

Frank,

Just to be clear, I'm very happy to include REST and think it would be very beneficial to do so.  But I don't think it's helpful to define two flavors of Web services when we are in trouble of not even gaining consensus on a single definition!

What I'd really like to see is a consensus definition of a Web service, and some compare and contrast between that definition and REST, but I would strongly recommend against creating an alternate definition of a Web service based on REST.  If the two were the same we would not be having these endless debates!

And as I said in reply to Mike I think it would be great to move the discussion to the stakeholders section.

Eric

-----Original Message-----
From: Francis McCabe [mailto:frankmccabe@mac.com]
Sent: Saturday, January 24, 2004 12:23 PM
To: Michael Champion
Cc: www-ws-arch@w3.org; Newcomer, Eric
Subject: Re: Section 1.6 and REST - Can we make this more clear and
useful ?


Mike:
   I think that your suggestion is sound. I *do* think that its fair to 
have a REST-oriented stakeholder section. Even if it is controversial 
-- bring em on.


Frank

On Jan 24, 2004, at 7:00 AM, Michael Champion wrote:

>
>
> On Jan 24, 2004, at 6:42 AM, Newcomer, Eric wrote:
>
>> Mike,
>>
>> I don't think non-rest is object oriented, and I don't think SOAP is 
>> object oriented.  As a CORBA company, we try to make a very clear 
>> distinction between something we consider object-oriented such as C++ 
>> CORBA for example, and something that isn't.  SOAP explicitly 
>> excludes most, if not all, of the characteristics of object based 
>> systems.
>
> It's too bad you've been so busy lately; Iona is exactly the kind of 
> company that has the perspective spanning CORBA, Web services, and SOA 
> that we need to tap here.  I hope we can spend a bit of time at the 
> F2F tightening up what we want to say.
>
>
>>
>> Amazon.com says (Jeff Barr I think, check Doug Kaye's IT 
>> Conversations at www.rds.com) that the majority of their "web 
>> services" users choose the "REST" style, although what they mean by 
>> that is plain XML documents.  A good number use what they call SOAP 
>> style, meaning XML documents in SOAP format.  ...
>
>> We have a problem in our document when we use the term "REST" to 
>> apply to Web services since it's not in our definition of a Web 
>> service.  I think it was a good try, all right, but we probably 
>> should focus on wordsmithing what's there and avoid reflecting the 
>> type of debate that's going on in the email list since it will never 
>> end...
>
> Actually, maybe this belongs in the Stakeholders Perspectives and not 
> the Introduction.  I agree that the Introduction should focus the 
> reader on what we plan to cover in Concepts/Relationships, and that is 
> Web services as we (finally) defined them in terms of SOAP and WSDL.
>
> So, here's what I propose (and it is more in the way of moving text 
> around than changing what we have or -- Heaven forbid -- wallowing in 
> the REST troutpond once again:  Section 1.6 should be a very quick 
> overview of what we understand the meaning of Web, Web services, SOA, 
> etc. to be and a rationale for why we focus only on the 
> concepts/relationships that we do focus on.  The bulk of the 1.6 stuff 
> would go into one or more Stakeholders Perspectives -- after all, "XML 
> over the Web" users are stakeholders in this discussion, even if the 
> formal definition of Web services doesn't really cover them well.  
> People who are promoting SOA [Iona and Software AG come to mind :-) ] 
> are stakeholders in a discussion of how SOA relates to web services, 
> the web, CORBA, etc.
>
> I think that would help balance Eric's concern that the document be 
> definitive, and my desire for the document to capture the "informative 
> and descriptive" position on things we spent so much time talking 
> about and -- at least within the WG -- have come to a majority view 
> on.   I would like to see a future incarnation of a W3C Architecture 
> group address these issues in a definitive way with all the major 
> players at the table, but for now I'm most interested in ensuring that 
> the world can see an "informative" view of what we've more or less 
> agreed on [Hao's dissent is noted!] so that what I think is a 
> pragmatic middle ground doesn't get lost (or laboriously rediscovered) 
> in future debates.
>
> Anyway, if this requires a lot of discussion, we just have to take 
> Eric's advice and toss it.  If so, no big deal, any of us who are 
> interested in documenting the "pragmatic middle ground" for posterity 
> can collaborate on an article or W3C submission or something.
>

Received on Sunday, 25 January 2004 11:49:10 UTC