I mean that the SOAP interface is likely going to work in a fundamentally different way that an interface based on HTTP PUT's, GET's, POST's, etc.3. Making it so we're not trying to describe two different interface strategies within a single doc (which adds complexity and potential confusion)
+1 on that, but using SOAP doesn't mean using a different "interface strategy" ... if I understand you, i.e. a different, non-HTTP interface.
I'd like to wait for the propsoal from Dare and crew before going into further thoughts on this particular aspect.4. Proposes a gateway-oriented architectural approach for the design of the SOAP binding
For the reasons I gave in #3 above, I would need to see a more detailed proposal to understand what is meant by "SOAP gateway" before agreeing with this Pace. If it's, as #3 seems to suggest, intended to define a new, non-HTTP application interface to Atom servers, then I'd be -1; I don't know why that would be desirable.