On Tue, 22 Jun 2004, Matthew J. Dovey wrote:
> > DDTT.
> > 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.
[...]
> No - you add a signature digest in the SOAP header but you don't change
> the XML tree (but possibly the serialized XML) of the SOAP:body - that
> way any client can still understand the response but a WS-Security aware
> will be able to check the signature. However part of this process is to
> convert the message part you are signing to (exclusive) canonical form.
> 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*
> This kind of hack has never worked (properly) - in XML you have
> namespaces, Entities and other such references which will break this
> kind of hack - and even when this kind of hack does work then it is
> definitely regarded as *bad* practice (far worse than putting entities
> in the root elements, which is both common practice and canonical form).
I agree that it's a hack, but I reference the other 'hack' clients which
the protocol -actively- supports by including such things as stylesheet,
echoedRequest, nextRecordPosition etcetc.
...
<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?
If sRR can have the namespaces for SRW and DIAG, why can't this be applied
to the recordData as well? We legitimately have XML documents included
inside an XML document, in just the same way that searchRetrieveResponse
is included inside the SOAP wrapper.
> 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; accepted XML bad
> practice is SRW good practice?
Wait wait, we're not talking about SRW servers, we're talking about
clients. An SRW server has no trouble supporting WS-Security. They will
work behind firewalls.
It's the stupid clients that extract records as text rather than as XML
nodes which will have the problem. But given that SRU actively supports
Terminally Braindead clients, let alone just stupid ones, it can easily
support this as well.
The issue is:
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.
It doesn't say that they MUST be ONLY there. It doesn't say that routers
then can't move them, it says that SRW recommends that they're there
UNLESS there's other reasons (such as the above) why they can't be.
EchoedFooRequest isn't mandatory. You can't build a stupid client and
expect it to work with everything, BUT we can certainly make
recommendations that will help such interoperability.
And yes, DDTT definitely applies to text clients, xslt clients and so
forth. But one of the notions we've always held was that clients
should be easy to write.
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/
|