> > As the client and server have no control over what might happen to
> > the literal XML in transit. XOP routers, XML over morse routers etc

> > We could take the DDTT approach - but do we want to position SRW in a
> > way that means

> >SRW servers have trouble supporting WS-Security;
> > SRW servers wo'n't work behind WebService firewalls;

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

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


> Yeah, OK, you've persuaded me.  Sorry, Rob.

My points, in a nutshell:

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

* We have always erred on the side of making it easier to write 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:.../">

* 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.

* 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.

Have I convinced you back the other way? :)

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/