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

[Daniel Chudnov]

Eric Hellman wrote, on Sun, Mar 05, 2006 at 02:35:35PM -0500:
> (resent in plain text at request of list members)

(thank you :)


> 1. silly injunction against non-unAPI parameters
> 
> # requests with non-unAPI parameters or an invalid combination of 
> unAPI parameters (e.g. "UNAPI?format=FORMAT") should return status 
> code 400 Bad Request
> 
> - this prevents me from doing stuff like invoking a test mode in my 
> unAPI server with an additional parameter. in OpenURL we set aside 
> _parameters for this.

It says "should", not "must".  Nothing in how it is written prevents you
from experimenting with new paramaters or a test mode on your own server.


> -makes future versions of unAPI incompatible

Who said anything about future versions? :) 


> 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?


> 3. those response codes
> 
> As for the use of http response codes, the use of http code 300 looks 
> bogus to me- shouldn't that be used for http content negotiation? If 
> someone used an http client stack that supported http content 
> negotiation, wouldn't this break? I admit it's bee a while since I 
> looked at the http spec, but really if this is what is desired, then 
> the unAPI spec needs to explain to the reader why these odd codes are 
> used.

Reviewing the RFC:

  http://rfc.net/rfc2616.html#p61

  "The requested resource corresponds to any one of a set of
  representations, each with its own specific location, and agent-driven
  negotiation information (section 12) is being provided so that the user
  (or user agent) can select a preferred representation and redirect
  its request to that location.

  ...selection of the most appropriate choice MAY be performed 
  automatically."

RFC 2295 specifies transparent content negotation, which we've found to be
(in its entirety) complex and more than what we need.  But, unless I'm
mistaken, nothing in what unAPI specifies so far prohibits the layering
of transparent negotiation over the server-side (using RFC 2295-style
headers, perhaps) or from the client side.

  -Dan


-- 
Daniel Chudnov
Yale Center for Medical Informatics
(203) 737-5789