Robert Sanderson wrote:

>>>And even if I was, the SOAP toolkit which does this parsing
>>>may or may not respect it and that's not something in my
>>>control. (Mine does, but I obviously make no guarantees about others)
>>>
>>>
>>A SOAP toolkit is also not required to allow the user to control how or
>>where the namespaces are placed in the XML - so insisting that
>>"namespace definitions should be placed on the innermost element that
>>they affect" might cause compatibility problems with some SOAP toolkits.
>>
>>
>
>Even if the tk automatically puts them at the top, the server MUST have
>had them in the record to start with for recordPacking=string.
>For them to not be there when recordPacking=string is simply _wrong_.
>
>
Agreed that when recordPacking is string this is the case. And as far as
I have been thinking this has been the case all the time. When string,
the recordData must be reparsed on the client side. And that's a reparse
of just some string. So it is not related to the SOAP wrapper in any
way. And _no_ security filter should mess with strings.

When recordPacking is xml I would be difficult to justify that
namespaces must obey a more narrow set of rules than they do for XML in
general.

>Secondly, SOAP tks for the client side can afford to be worse than the tks
>used for the servers, as per much prior discussion.
>
>
That's why we have SRU which put a great burden on servers and not on
clients :)

-- Adam

>Rob
>
>--
> ,'/:. Dr Robert Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. 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/
>
>
>