Fred sent me this off-list, but I think it worth enough for the FAQ.
In this case it is the client at fault NOT the server (and I've advised
Fred that the onus should be on fixing the client, rather than trying a
workaround at the server).
A SOAP client or server should not assume anything about the namespace
prefixes and MUST cope with regarding
<srw:searchRetrieveResponse xmlns:srw="http://www.loc.gov/zing/srw/">
As equivalent to
<randomstring:searchRetrieveResponse
xmlns:randomstring="http://www.loc.gov/zing/srw/">
(this is actually part of the XML spec, rather than SOAP or WS-I, so
equally applies to SRU clients and servers).
It isn't the first time I've seen this sort of mistake (the first time
was in Microsoft code), and I doubt will be the last...
Matthew
> -----Original Message-----
> From: Fred Petter Pedersen [mailto:[log in to unmask]]
> I have now come a step further in the creation of SRW
> Service, but one client that have tested my first
> test-version of my SRW expect SRW to be the prefix in
> SOAP-response, as you can see now it's wn3:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <e:Envelope
> xmlns:e="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:d="http://www.w3.org/2001/XMLSchema"
> xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:wn0="http://www.loc.gov/zing/cql/xcql/"
> xmlns:wn1="http://idoox.com/interface"
> xmlns:wn2="http://www.loc.gov/zing/srw/diagnostic/"
> xmlns:wn3="http://www.loc.gov/zing/srw/">
> <e:Body>
> <wn3:searchRetrieveResponse i:type="wn3:searchRetrieveResponseType">
Etc.
|