> > And if you are using something like XOP (optimised binary 
> transmission 
> > of XML), something like this may indeed be happing. But such a thing
> 
> Optimised Binary Transmission of XML ... You mean, kinda like, BER?
> *hides*


Errr, yes - some of us cynics predicted that this would happen (and even
looked into rendering XML via XER/BER etc.) last millenium!

I've said this before and I'll say it again - a lot of this is just a
marketing exercise. Most of the WebService concepts aren't new and
previously existed under other names/technologies. But if you are
selling something (e.g. a standard) WebServices etc. are the buzzwords
to use; BER and ASN1 are the words that will lose you the audience.
 

>  <SOAP:Body wsu:Id="myBody">
>     <SRW:searchRetrieveResponse 
> xmlns:SRW="http://www.loc.gov/zing/srw/"
> xmlns:DIAG="http://www.loc.gov/zing/srw/diagnostics/">
> ...
> 
> Why are SRW and DIAG defined -here- not on the SOAP:Envelope element?
> Surely Envelope is the top level for this XML?

Because in this case I'm signing the SOAP:Body so I move all namespaces
defined under SOAP:body to the searchRetrieveElement.

If I signed the Envelope then I would have to move the namespaces up to
the SOAP:Envelope element (although that would be difficult because of
the recursion caused by trying to sign the signature).

Basically excluded canonical form means that I move all namepsaces up to
the root element of the fragment being signed.
 
> If sRR can have the namespaces for SRW and DIAG, why can't 
> this be applied to the recordData as well? 

I can't have namespaces defined in recordData if I'm signing an ancestor
element of recordData - I could sign only the recordData section in
which case the namespacing would be as you'd want to recommend.

> Wait wait, we're not talking about SRW servers, we're talking 
> about clients. 

No - we're talking about SRW servers since you then say:

> Should SRW recommend (note it would only ever be a 
> recommendation) that *servers* respond with the namespace 
> mapping for embedded records such that they're on the record 
> nodes, rather than the protocol nodes.
[My emphasis]

> It doesn't say that they MUST be ONLY there.

I'd missed that distinction. 

However, I'm still not happy about this recommendation. Since

A) all the other recommendations can be implemented by an SRW server
with an off-the-shelve WS-I compliant SOAP toolit. An WS-I compliant
toolkit needn't guarantee anything how it creates namespace definitions
in the serialized XML, (unless it is doing signing in which case it
would be canonical). So in the general case this recommendation may not
be implementable with standard toolkits.

B) it is indeterminate - i.e. let us say we had a client which required
an SRW server to follow this recommendation. For other such
recommendations if the server software is not modified, the client will
work or wo'n't work. For this recommendation, there is no guarantee that
given a server implements this recommendation that the client will work.
It might work one day, but break the next because the routing topology
has changed!

C) The other recommendations are for supporting "brain-dead" clients.
This one encourages "badly-coded" clients.

Matthew