> > I agree that it's legal, but for our purposes it's definitely not
> > 'good' because those namespaces definitely are NOT inherited by
> > records packed as _strings_.
> OK - agreed that *if* the xmlns is "opaque" to the XML document (because
> it has been packed into a strings) then the xmlns should be in the
> packed string.
And if they have to do it for strings, then there's practically no
hardship for making it mandatory for non strings as well.
> However, if the record is being passed as XML then there can be no
> guarantees where the namespaces get defined. Even if the SRW server has
> followed some SRW convention, an intermediary might have reparsed the
> XML and moved the namespace definitions elsewhere - for example there
> are now a number of WebService firewalls on the market which might read
> the XML and sign it. They would necessary convert the XML to canonical
> XML (which would move the xml declarations to the root element).
If you're stuck behind such a monster, then use either string packing or
expect that -your client- is going to have such issues. That has nothing
to do with the -server- which can still be legitimately expected to put
namespace definitions where we want it to.
You could have a client behind a firewall that turns the message into
morse code and transmits it via ham radio for all the server and the
protocol specification could care.
> Even if there wasn't an intermediary - I might want to sign my SRW
> responses (which would mean violating any convention to put namespace
> definitions on the innermost element).
Can you explain further the mechanics of 'signing an SRW response'?
As I understand it, you have to wrap the entire thing in a <Signature>
element, then you have another service which checks the signature, unwraps
it and returns the original xml? And this is -required- to return the
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. University of Liverpool
I L L U M I N A T I L5R Shop: http://www.cardsnotwords.com/