Re: Idioms

[Joe Gregorio <joe.gregorio@xxxxxxxxx>]

On Sun, 10 Oct 2004 13:00:38 -0400, Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:
> Joe Gregorio wrote:
> 
> >
> > I've seen thoughts on this divide down into two
> > basic camps, those that believe if it's a list we
> > should use the Atom Syndication Format, and
> > there are those that believe we can use other
> > formats if the nature of the list diverges too far
> > from that of a list of 'entries'.
> >
> > Questions:
> > 1. Do others see the same pattern?
> 
> Almost. I see one resource where you see two. That is, the FeedURI and
> the PostURI are the same thing.

Agreed, they could certainly be the same.

> 
> I also think the "list" idiom is inappropriate, because there isn't much
> justification for a given sequence, especially for users, templates, and
> other non-entry resources. They are not ordered collections.

Indeed, you may want to browse entries by category or 
by alphabetical order of the titles. Maybe "Set Management"
or "Collection Management" idiom is a better name?
> > 3. Do we need to reach a concensus on the reuse
> >     of the syndication format before moving forward
> >     on the rest of the items so we don't end up
> >     rehashing the same arguement for every part of the
> >     protocol that falls into the List Management idiom?
> 
> Well, let's face it. There are really only two games in town. There's
> the feed format, and there's WebDAV collections. Otherwise, we are
> inventing something entirely new, and we are unlikely to be very
> successful.

I whole-heartedly disagree. If we follow your logic to it's conclusion
then our publishing protocol would end up using RSS and OPML.

While an admirable attempt to frame the discussion as Atom vs.
WebDAV I believe that creating our own format is a viable solution
and it is still on the table. 

While what we may come up with may not be perfect, I would
hardly point to WebDAV as unable to be improved upon. For 
example I think we could do better than:
 
   xmlns="DAV:"

And while you admit that WebDAV may not be a perfect fit for the
APP I see you failed to mention one area where WebDAV and the 
APP diverge dramatically, in the area of constraining the paths
for resources. From the WebDAV spec[1]:

" A collection is a resource whose state consists of at least a list
of internal member URIs and a set of properties, but which may have
additional state such as entity bodies returned by GET. An internal
member URI MUST be immediately relative to a base URI of the
collection. That is, the internal member URI is equal to a containing
collection's URI plus an additional segment for non- collection
resources, or additional segment plus trailing slash "/" for
collection resources, where segment is defined in section 3.3 of
[RFC2396]."

The APP has always carefully avoided such constraints, first
because they are not needed to make the protocol work, and 
second, because they are an unneeded constraint that would  
only make it more difficult for 'bob' to implement.
 
> So, an Atom Collection might be WebDAV Collection, but that would not be
> required. That way, people who want to do complicated things with Atom
> resources (e.g. LOCK them) have a well-tested, widely-deployed way to do
> it. No further Atom work need take place.

That sounds dangerously close to "just use webDAV". I will need to 
review the WebDAV RFCs more closely before I comment on the
rest of your mail.

   -joe

[1] http://asg.web.cmu.edu/rfc/rfc2518.html#sec-5.2
 
-- 
Joe Gregorio        http://bitworking.org