In summary:
Unless the client knows how to process this information, it's useless and
wasting everyone's bandwidth and processing time.
If the client does know how to process this information, it can also be
able to request it.
> I think a server may have the following reasons for including
> extraResponseData that are independent of what the client requests :
> To identify ownership of the data/response.
> To show where the response came from.
> To provide additional data which will help process the response.
All of which can only be processed by a client which knows what the data
means. If the client can process it, it can request it.
> To provide diagnostic information in the response, not necessarily for the
> purposes of the client.
If you need over-the-wire debugging facilities, then the client can
request them. But including all of the information in every response is
just simply bad manners and just plain wrong.
> The client can ignore data it does not require. Why should it "break" the
> processing in the client, unless the client is not conforming to the schema
Because this information comes in the form of arbitrary elements.
A SOAP toolkit that can't handle this will likely just refuse to process
the response, and hence will be unable to use the service at all.
For XSLT based processing, unless there is an XSLT rule to process the
information, it'll end up being dumped into the output stream, potentially
breaking the application.
> While the additional parameter is one way of defining the additional data
> included in the response (http headers might be an alternative) it requires
> the client to know this parameter and that it has a means of setting this
> parameter, either automatic or user driven.
Yes. And, as above, if the client can process the information, it can
request it. The code required to request it is probably one line. The
code required to process it once requested is liable to be many more than
that.
HTTP headers might be an alternative, but they're not the way SRW/U uses.
Notably as SOAP doesn't specify HTTP as a required transport protocol, and
there's no reason why SRW should have to be transported via HTTP.
Rob
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Dept. of Computer Science, Room 805
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I
|