[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idioms


Joe Gregorio wrote:
On Sun, 10 Oct 2004 13:00:38 -0400, Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:

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


That's pretty specious. RSS and OPML aren't publishing protocols.

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.

It's not an attempt, it's the fact of the matter. Sure, a new format is still on the table, but that is the path to years of spec work, in my opinion.


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:"


That's just not important. It was a decision they made back before there were widely understood best practices for namespaces. It doesn't hurt interop.

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.



Well, such constraints would prevent 'bob' from defining RPC endpoints. Obviously, the WebDAV group disagreed with your assessment of the need to constrain the URI's form. Also, I fail to see how this makes it harder for 'bob' to implement. Here's an example of a template collection:

http://franklinmint.fm/cgi-bin/templates.cgi/MyTemplates/

"the WG never turned up an authoring client or server
that required a non-hierarchical namespace only those that could operate in the absence of hierarchy because they used a flat namespace."[0]


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.


I suppose it's dangerously close to "use something that was Not Invented Here". WebDAV isn't broken. There is no reason for us to reinvent it.

Robert Sayre

[0] http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html