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

[Eric Hellman]

basically, we're having this discussion because the relevant section 
of the spec falls on the short side of "as short as possible, but not 
too short"

What I'm observing is that there are two types of requests made to an 
unAPI service
1. request for availability info
2. request for metadata object

What I'm saying is that responses to (1) should ALWAYS return xml if 
the unAPI service is working, and I shouldn't have to care about http 
status codes. Responses to (2) should be possible to delegate to an 
http stack, or to a browser, or whatever.

It's unfortunate IMHO that the spec has  not chosen to make this 
necessary modality explicit, but it should at least explain it better.



At 9:48 AM -0700 3/6/06, Xiaoming Liu wrote:
>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


-- 

Eric Hellman, Director                            OCLC Openly 
Informatics Division
eric at openly.com                                    2 Broad St., Suite 208
tel 1-973-509-7800 fax 1-734-468-6216              Bloomfield, NJ 07003
http://www.openly.com/1cate/      1 Click Access To Everything