RE: [R3xx] Requirements Section "4.2 Simplicity and Stability" -- com parison with SOAP1.1.

Hi David,

Thanks for sending this out - a few comments below

> === R307
> 
> It cannot be proven that SOAP1.1 would not address this 
> requirement; however,
> the requirement calls out usage scenarios as tools to prove 
> suitability.
> Since the usage requirements themselves are under 
> consideration, we can only
> suggest that the XML Protocol R307 will help outline 
> requirements which are
> more widely "suitable" than those used in the design of 
> SOAP1.1,  and further 
> suggest that SOAP1.1 might fall short of fulfilling these 
> requirements.
>  
> More specifically, SOAP1.1 has only limited usage scenarios, 
> and as such
> falls short of R307.

More scenarios would definitely help
  
> === R308
> 
> The SOAP1.1 specification succeeded to some extent in 
> supporting modularity,
> especially modularity in terms of unforeseen architectural 
> components which
> can be supported through constructs such as the "Header" and 
> "Body" elements,
> or in SOAP encoding rules.  However, this modularity seems 
> weaker than that
> specified in the XML Protocol requirements.  Further, SOAP1.1 
> doesn't appear
> to have much support for "layering".  Such support arguably 
> requires a 
> clear architecture, promised in XML Protocol requirements 
> (R300) but missing 
> in SOAP1.1.

I am wondering what you mean by "not much support for layering" - is it
because the layering model in SOAP is not explained well enough or is it
that you believe it is not there? I would disagree with the latter by
the way ;)
  
> === R300
> 
> In SOAP1.1, "1. Introduction", SOAP specifically declines to define an
> architecture, abstract or otherwise:  "SOAP does not itself define
> any application semantics... or implementation semantics...; rather it
> defines ... a modular packaging model and encoding mechanisms...".  

I think there is a big difference between not defining any application
semantics and not defining a model. As it absolutely is the intent that
SOAP can be used to solve real world problems (carry application
semantics) one could argue that it is not possible to have a protocol
like SOAP without a model for how application semantics can be added.

At least to me, the protocol binding model in SOAP is definitely a
layering model allowing SOAP to be exchanged in a variety of ways
without tying it to a single environment, no?
  
> The semantics mentioned are some of the key elements in the abstract
> models which are being introduced.

I don't believe it is the purpose of the abstract model for XML Protocol
to define application semantics - I think it is more a question of
defining how the modules fit together: application semantics go here,
transfer semantics go here, etc.

> Since SOAP1.1 defines only a "modular packaging model" and "encoding
> mechanisms",
> conformance with SOAP1.1 can be viewed as "validation" 
> conformance (as in
> DTD or Schema validation).  "XML Protocol requirements" is 
> suggesting a more
> rigorous conformance test which includes semantics defined in 
> in-scope usage
> scenarios, i.e. certain types of behavior.

I don't think the SOAP validation model is only to validate the model -
it is in fact to process the message according to the rules or generate
a fault. I agree that the rules are written in a rather sparse manner
but there certainly are rules for how to process a SOAP message.
  
> === R302
> 
> SOAP1.1 defines a vocabulary with certain types of extensibility.  XML
> Protocol requirements declare a need for extensibility which supports
> "decentralized extensibility without prior agreement".  It's not clear
> whether the types of extensiblity in SOAP are adequate for 
> this requirement.

I would suggest that the key to decentralized extensibility is a
combination of using XML namespaces as well as the optional/mandatory
flags that one can stick on SOAP headers. It is decentralized in the
sense that there need not be central control of a feature in order to
introduce it and any feature can force the failure of a message by
indicating that it must be understood.

Henrik

Received on Wednesday, 31 January 2001 13:06:50 UTC