Re: XML Protocol specification conformance issues

Thank you both for undertaking this analysis.  Figuring out the right way 
to deal with conformance is clearly important. From your proposal:

>> An important aspect is to clearly identify what 
>> parts of the specification are mandatory for an 
>> implementation to be compliant, and what parts 
>> are optional. For example, RPC support might 
>> not be required for a minimal XML Protocol processor.

I have some fundamental concerns regarding this formulation.  First 
of all, it's my expectation that our specification will be for a set of 
formats and protocols;  it will not be a specification for a particular 
style of processor.  Of course, our specification will constrain in 
various ways any implementation that purports to send and receive XMLP
messages.

The test plan proposed seems to be for a general purpose XMLP
processor, which is not something that our specifications are likely
to define.  You can see aspects of our specification manifest on the
wire, and you can see whether an endpoint has rejected something
legal, accepted or generated something illegal, etc. but we are not
specifying in any other respect the implementation of an endpoint.  We
therefore can't and shouldn't provide anything to suggest a
requirement for completeness of implementation, except insofar as
certain bits of behavior are mandated in certain circumstances (e.g.
you shouldn't respond with a "mustUnderstand" fault if the message
contained no "mustUnderstand" headers.)

Yes, there will be quite a bit of "general purpose" XML Protocol
software out there, but nothing in our specification should require
that.  Consider the stock quote example at the beginning of the SOAP
specification.  Lets assume that the "server" does indeed provide
stock quotes, but only stock quotes, through SOAP/XMLP.  It needs no
general purpose SOAP glue.  It can (roughly):

a) check to ensure that the envelope/body/GetLastTradePrice elements 
   are there
b) if there are any headers labeled mustUnderstand, return the 
   appropriate  fault (because our server expects no headers)
c) respond with something that looks like a SOAP response (though 
   strictly speaking, the SOAP spec says nothing about whether a 
   response will in fact be generated in bounded time.

That's it...and lots of implementations will do just this for only the 
service they are providing.  Are they non-conforming?  Absolutely not. 
Nothing in SOAP requires that you have code to process anything other than 

the services you are offering;  I strongly believe that's how it should be 

in XMLP.  Anyone remember Don Box's implementation of a SOAP square-root 
service using only an XML stylesheet (it transformed the input message 
into an output message)?

I suspect that our conformance rules should more be in the form of 
invariants that must always be observed:  e.g. no message generated may 
have more than a single BODY element; every response must have a 
correlation ID that matches some earlier request, etc. 

I don't think our charter mandates a test suite.  To build a test suite, 
one would need to specify the characteristics of the endpoints.  Yes, it 
would be very useful for someone to do an additional specification called 
"Specification for a General Purpose XML Protocol Processor";  I think you 

could implement a test suite for that.  I don't think it's necessarily the 

job of our WG, nor should it be in our critical path to recommendation. 

I do think we should aim for the "two interoperable implementations" 
standard suggested by our charter.  To do so, we would need to itemize 
features of our specification that we believe need testing (e.g. support 
of headers that are understood, support of headers that are not 
understood) and demonstrate at least two suitable pieces of software that 
compatibly implement these features in context and with reasonable 
generality.  For that specific purpose, I can see developing a test suite, 

but it should not be a suite that is used to test yet other 
implementations for "conformance";  it should only be used to prove that 
we have done reasonable coverage testing of our specification.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Tuesday, 10 April 2001 19:48:23 UTC