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

Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt




On 3/18/07, Joe Gregorio <joe@xxxxxxxxxxxxxx> wrote:
That seems rather fragile, is there any reason
not to have the server implementation look for the
first link in the content if no alternate link
is present? Any reason to not make the
first link in the content, or a microformat,
the primary way of adding a bookmark?

Of course it could be done this way, but at the moment it isn't and
that's not the point.

There are numerous bookmarking services [1] that would benefit from a
"standard" bookmarking API.  AtomPP is a natural fit for this, but
bookmarking is a particular AtomPP application.  The expected behavior
for "bookmarking" atop AtomPP has yet to be agreed upon and documented
and that's the point :)

As a couple of examples, we have different approaches to "bookmarking"
atop AtomPP and I don't agree with the way Google did Calendaring [2],
[3].

So I don't want to get into the semantics of how a particular
application for AtomPP should work. Instead, I want to ask if the
group sees value in defining additional application specific specs
e.g. Bookmarking, Calendaring and, dare I say it, Blogging.

Additionally, I wonder whether the core specification should provide a
means for a client to discover the AtomPP applications the server
supports?

Rob

[1] http://en.wikipedia.org/wiki/Social_bookmarking
[2] http://code.google.com/apis/calendar/gdata.html
[3] http://robubu.com/?p=14