 |
 |
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/ > > >