Re: Proposed issue; Visibility of Web services

Mark, I understand that you personally disagree with this wording, but I'm 
unclear about the grounds on which you bring this issue to the TAG. I am 
the current editor of that section (Dave Orchard drafted a previous 
version), and we have paid quite scrupulous attention to the TAG's work to 
ensure that WSA meets its chartered obligation to align itself with the Web 
architecture. The current draft of the Architecture of the World Wide Web 
[1] does not contain the word "visibility" or "intermediary" (the whole 
point of "visibility" as I understand it is to be accessible by an 
intermediary), and the word "visible" is used in a different context.

I further note that the reference to REST [2] in the Webarch document is in 
section "8.2. Non-Normative References".  It is also a non-normative input 
into the WSA.  Also, to the best of my knowledge (after searching with 
Acrobat), the strng "XML" does not appear in reference [2].  Thus, I don't 
understand how our argument that the standardization of message envelopes 
and bodies using XML provides "visibility" benefits could be in 
contradiction to the principles of REST even if we were to consider them 
normative constraints on the WSA.

So, could you be specific as to the principle of the Web architecture 
against which you believe that the current WS Architecture document is "in 
error"?

I *assure* the TAG that we have taken (with Mark's help!) the Best Practice 
in Section 5.2 very, very seriously: "Understand REST: Designers of 
protocols SHOULD invest time in understanding the REST paradigm and 
consider the role to which its principles should guide their design."   
That said (and speaking only for myself) I would appreciate the opinions of 
any TAG members who might care to jot down their thoughts on how ...

"statelessness
clear assignment of roles to parties
uniform address spac
limited uniform set of verbs"

...apply in the machine-machine communication environment of Web services 
and in multi-network, legacy application integration usage scenarios. It's 
relatively easy to argue (and I personally agree!) that RESTful approaches 
to Web services have lots of tangible advantages for scenarios such as 
exposing Amazon.com's features to automated agents via HTTP.  It's much, 
much harder to argue that "statelessness" and "limited uniform set of 
verbs" is a practical  constraint when one is exposing features from a 
legacy COBOL program running on a mainframe, or an ERP system in a high 
security environment, to other applications via SOAP interfaces.

[1] http://www.w3.org/TR/2003/WD-webarch-20030326/
[2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

--

Received on Tuesday, 20 May 2003 14:29:40 UTC