> Incorrect.  They'll work just fine. It's the clients that try 
> to text process the document that won't work and DDTT applies.

In which case why are we proposing a recommendation which encourages
people to write clients that might break in this way?
 
> > > accepted XML bad practice is SRW good practice?
> 
> Is already broken in Matthew's example by not moving SRW and 
> DIAG onto the SOAP:Envelope element.

Errr no, because I am signing the searchRetreiveResponse section not the
entire SOAP:Envelope (since to do that I'd have to sign the signature,
but to sign the signature I need to know the value of the signature, but
I don't know that until I've signed the SOAP:Envelope....) - I move
namespaces to the root element of the section I'm signing.

> * String packed records MUST have their namespaces embedded 
> otherwise they
>   are not valid.  For SRW, string packing is the default.

Agreed - no problem there...
 
> * We have always erred on the side of making it easier to 
> write clients.

Yes, but this is a first for erring on the side of helping badly written
clients as opposed to easily written clients...

> * Having the namespaces defined on the top level element 
> within recordData
>   doesn't hurt anything, wouldn't be mandatory, and makes it easier to
>   write clients.
>   Eg.  <record>
>           <recordData>
>              <zrx:explain xmlns:zrx="http:.../">

I'm not saying we recommend *not* doing this, just we shouldn't
recommend doing this either (i.e. stay agnostic as XML itself is
agnostic). 
 
> * If the XML gets modified in transit, then that is the 
> client's problem
>   and DDTT for stupid clients definitely applies. No argument.  But if
>   the XML makes it through, then there's a gain. Eg for SRU.

This is a badly written client, rather than stupid!
 
> * All this web service proxy stuff only applies to SRW, not SRU, as it
>   relies on SOAP.  As SRU is the prime candidate for stupid 
> clients, there
>   is no reason not to recommend it.

Not necessarily - as the WebService firewalls (and WS-Security) take on
board supporting REST WebServices as well as SOAP WebServices, it could
well apply to SRU.

Matthew