"Simon Y. Blackwell" wrote:

ugly indeed. no matter which way you take this there are issues of 'ugliness'. on one hand you are faced with developing a library of discrete responses that could be virtually limitless in number if they are to provide usable information to all known test cases. on the other hand, as you point out, application specific responses are likely to require some sort of out-of-band (predefined) understanding of semantics, etc. to react properly to the message (otherwise you are no better off receiving a detailed response vs. 'no. go away'.)

perhaps the middle ground is the development of some generalized semantics based upon the content of the request.

<winging it/> suppose a doc had <balance> as a field, your response above would be a valid message ("balance < ?required-amount"). in other words, responses would be based upon some generic expressions (<, >, <>, =, +/-, etc.) and are limited to those fields presented in the request itself. of course a document could be submitted that is missing necessary information, in which case you would be stuck responding with 'all necessary information not present' or some such, but as mentioned above, it is hard to think of a scenario whereby a valid requestor can be totally ignorant of the recipient's requirements and still be able to act in any meaningful way to the response codes reagardless of their content.