Re: AtomPubIssuesList for 2005/02/22

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

Joe Gregorio wrote:

> PaceSliceAndDice
>
> +1 In general, but I have some comments
>
> 1. Ezra, I really liked the way you handled the difference between ordered
>   and unordered collections. Its simple and yet handles all the cases,
>    entries, simple resources, categories, and users.

I guess it depends how many simple resources, categories, and users you 
have.

> 2. This line """This URL MUST include the collection 
>    URL as an initial substring, and MUST contain only 
>    one path segment after the collection URL. "Path 
>    segments" are as defined by [[URI RFC]]. This 
>    restriction permits compatibility of the URI space 
>    with that of a WebDAV collection."""
>
>    This seems like a restriction that is un-necessary. IF someone
>    wanted to make their Atom API WebDAV compatible then they
>    would *have* to make this restriction in accordance with 
>    WebDAV, not the APP. 
>    There is no where in the APP that this
>    restriction on the URI space is used. 

Ezra's proposal includes a depth header. I don't see a restriction on 
circular references. URI constraints are an easy way to accomplish that. 
 Any namespace operations would probably get an implicit WebDAV 
collection whether we specify it or not. It's a reasonable thing to want 
to MOVE an image. This means the last path separator will matter, we 
just won't have specified it. The second point is that half the reason 
WebDAV has the restrictions it does is so that clients can expect a 
server to act the same. "Free" URIs look sort of like XSS attacks to me. 
The third point is that there is still no use case for URI freedom, 
while the restriction has many. URI freedom would be more interesting if 
you could remove an entry from one collections without removing it from 
all collections (LINK/UNLINK).

> 3. Is the content of a <member/> element a human readable description?

I'd prefer something that let your basic info in there. 
ID/Title/HREF/Updated. I'd also prefer that <member> have a child 
<description> element, so it can be extended later.


> 4. """If no Range: HTTP header is given in the request, the interval is taken 
>    to be all of time."""
>
>    I was initially taken aback by that, as it seems like an odd default, 
>    which means if I were to hit that URI with a browser, or
>    a robot, I would by default get the largest possible document with
> all the entries
>    in it. 

Most servers will probably just throw an error. Secondly, it's not a 
Range. I don't know what it is, but it's something else. There's no 
unit, and there's no total.

Robert Sayre