Re: AtomPubIssuesList for 2005/02/22

[Joe Gregorio <joe.gregorio@xxxxxxxxx>]

A couple further thoughts on PaceSliceAndDice:

1. Should we spell out that the server is expected to include
    an Accept-Ranges: header with a value of "updated" in 
    response to a GET? And additionally that is should 
    include a Content-Range: header in the case of a 'partial' result?

2. Should we make the range units 'atom-updated' instead of 
    just 'updated'? I don't think so, since we can differentiate 
    outselves from other uses of 'updated' based
    on the mime-type. That leads to the next question:

3. What is the mime-type of the Collection Document? I 
    believe it should be 'application/atom+xml'.

    Thanks,
    -joe


On Thu, 24 Feb 2005 15:56:01 -0800, Ezra Cooper <ezra@xxxxxxxxxxxx> wrote:
> On 2/24/05 11:00 AM, "Joe Gregorio" <joe.gregorio@xxxxxxxxx> 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.
> 
> Thanks!
> 
> > 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."""
> 
> When I wrote this, I was under a misunderstanding about the benefits it
> would have. I'm not particularly attached to it now. If no one else is
> attached to it, I will remove it, leaving collection and member URLs
> unconstrained.
> 
> > 3. Is the content of a <member/> element a human readable description?
> 
> Ah--thanks for mentioning that; it's not specified.
> 
> I think we should include a description, but I'm leaning toward using an
> attribute like @title. That would leave us open to bubbling some of the
> member's own XML data (in some cases) in the content of the element, if we
> can find a way.
> 
> Any thoughts about that?
> 
> > 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. But since this document is relatively thin, that is,
> >    it only returns URIs (and possibly a human readable description), I think
> >    this is acceptable default behaviour.
> 
> I think this is the behavior I would expect as an implementor: if I do a GET
> on the collection URL with no special headers, I get the whole collection
> (but not its descendants). The "Range:" header is an additional restriction
> that I might apply to save transfering things that I already have.
> 
> > 5. """But when creating a public reference to the same image resource,
> >      the client should use the "hrefreadonly" value."""
> >
> >    Can we add verbage here to state that if 'hrefreadonly' is not given then
> > the 'href' value can be used.
> 
> When this came up before [1], Rob said:
> 
> > >  (b) if no @readonlyhref is given, it defaults to the value of @href, a
> > > required attribute.
> >
> > Maybe they should be made explicitly the same. Some resources (e.g.
> > Templates) may not have public facing URIs. It would be bad to assume.
> 
> I think this is good logic. There may be other ways of accomplishing the
> same, but this one (NOT defaulting "hrefreadonly" to the "href" value) seems
> pretty good.
> 
> Ezra
> 
> [1] http://www.imc.org/atom-protocol/mail-archive/msg00366.html
> 
> 


-- 
Joe Gregorio        http://bitworking.org