[gcs-pcs-list] more comments (plain text)

[Xiaoming Liu]

On Sun, 5 Mar 2006, Daniel Chudnov wrote:

> Eric Hellman wrote, on Sun, Mar 05, 2006 at 02:35:35PM -0500:
>> (resent in plain text at request of list members)
>
>
>> 2.  modality of response to UNAPI?uri=URI requests.
>
> Your point about how a URI 404 should have a body like this:
>
>    <formats>
>        <uri>info:sid/example.com/12345</uri>
>    </formats>
>
> Is a good one.  I'll flag it for a vote.
>
> But:
>
>> When I build an client for an XML service, I delegate the message
>> handling to an XML Processor (usually with XSLT doing most of the
>> work). The processor will throw an exception if the response is not
>> well formed xml; this is usually because a service is broken. If I
>> have to listen for a 404 response just in case there are no available
>> format for an item, or if the item is unknown, then I can't handle
>> that inside the XML processor.
>
> I hear you, but there's a deeper issue:  the XML modality is layered over
> the HTTP modality.  HTTP is the common modality across all of unAPI;
> some responses are XML, not all (indeed responses can be any type).
> So your client should start by watching HTTP status codes, then handing
> off to the XML processor, no?
>

If we agree on natural language reponse for error message, and "best 
practice" for error code, I think an appropriate way of error processing 
is checking status code first, if any error (http 400-500 range), a client
may log or prompt these errors, but the client may not expect a machine 
readable error message (such as the XML snippet proposed above).

xiaoming