Re: Closing AG005 issues - AC003 CSFs

I also better look at these ...

+1 to everything, except these two;

On Tue, Jul 16, 2002 at 10:19:32AM -0400, Champion, Mike wrote:
> I'll deal with the AC003 CSF in this message, and send separate messages for
> the others.
> 
> "D-AR003.1 separates the transport of data or means of access to Web
> Services from the Web Services themselves."  The intent here seems to be
> that web services architecture should be neutral with respect to the
> mechanism by which the producer and consumer of the service exchange data. 
> 
> On the preliminary ballot, there were 12 Y's, 2 L's, and 1 D.  The
> disagreement comes from the REST perspective that stresses the difference
> between "application" and "transport" protocols.  The counter-argument is
> that services may be accessed across protocol bridges, and there is a use
> case for "tunneling" over HTTP even if this is not best practice for the Web
> itself.  This has been extensively discussed, with no resolution in sight.
> I suggest we vote; if a supermajority agrees to keep it in, remove the draft
> status.

Bridging is fine, so long as the bridge respects the semantics of each
end of the bridge.  e.g. a SOAP-enabled HTTP/SMTP bridge must be both a
good HTTP server, and a good SMTP client (yes, this is do-able - I've
built one 8-).

Plus, I suggest that the Web Method feature of SOAP 1.2 changes
how "transport independance" is perceived, and in particular what
the current wording of the requirement suggests.

How about a suggested replacement then;

D-AR003.1 supports multiple transport and application protocols.

i.e. we can say what I think the group really wants to say, but without
saying what I don't want said; that we support lots of protocols, but we
don't *require* that application protocols be tunnelled over (though we
don't preclude it either).

> "D-AR003.6 defines or identifies a base interface that all Web services can
> implement, that permits communication without a priori knowledge of the
> service."  The intent here is to promote a CRUD/REST set of basic operations
> that all web services should support without a formal service description,
> e.g. GET-ing a stock quote service's URI would retrieve something meaningful
> even if it supported all sorts of other methods.
> 
> The balloting on this was 5/1/4/5.  Comments suggested that people didn't
> understand the goal, or that it didn't belong in the
> scalability/extensibility section, or that one couldn't do much of practical
> value without the schema of the data returned by the apriori method.  I
> personally like this CSF, but admit that it has little to do with
> scalability/extensibility except in the sense that "the web is scalable, and
> the web is RESTful, so RESTful web services will be scalable."  Others have
> pointed out the flaws in this syllogism ... ("Socrates is a mortal, Socrates
> has white hair, thus mortals have white hair"), so I'd suggest that we
> either drop it (under the "if in doubt, throw it out" rule) or the
> originator should clarify the rationale and propose it under another goal.

Oops.  There's a namespace maintenance problem here.  The D-AR003.6
you're referring to was never balloted, because it was proposed after
balloting had occured.  The old 3.6 has been dropped.  FYI, it was;

"D-AR003.6 specs that are created in conformance with the architecture
do not have to go through a formal process to be considered conformant"

In fact, we decided on the last conference call to drop the draft status
from this requirement, after deciding to move it under MikeM's new
"supports early and late binding" requirement;

http://lists.w3.org/Archives/Public/www-ws-arch/2002Jun/0238.html

The (un-approved) minutes say;

"ACTION: Editors to incorporate MikeM's proposal for D-AC004 as accepted
save the new top-level CSF, X.3 and X.4"
 -- http://www.w3.org/2002/ws/arch/2/07/11-minutes

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Thursday, 18 July 2002 09:21:20 UTC