On May 25, 2007, at 8:08 PM, Evan Prodromou wrote:
On Fri, 2007-25-05 at 19:16 -0700, John Panzer wrote:
I'd like to start a draft rel-edit page on microformats.org; but
first
I'd like to gather some feedback on this mailing list.
Just FYI: The Atom Publishing Protocol draft spec uses <link
rel="edit"
.../> to point from a read-only representation of a resource to an
alternative URI that allows for editing operations, and in particular
one which is supposed to support loss-less GET/edit locally/PUT
semantics in the case of Atom resources.
That's interesting, and I'm glad to hear about it. I think at least
the
first part ("point from a read-only representation of a resource to an
alternative URI that allows for editing operations") sounds
compatible
with the proposed rel-edit semantics.
However, for most of the applications I was thinking of (wikis, CMSes,
blog software, forums, comment systems), there's not a RESTful
GET-edit-PUT flow. Instead, the editable representation is
typically an
HTML form, which is POSTed.
Do you think that's a serious conflict -- an existing use of
rel="edit"
that is widespread and has different semantics? Is there a danger of a
real-world clash (e.g., an Atom processor that accidentally stumbles
across a wiki page with a rel-edit link and does the wrong thing)? Do
you think the conflict is important enough to choose a different "rel"
attribute?
I think it would be reasonable to assign slightly different semantics
for <link rel="edit"> and <a rel="edit">. It makes sense that the
former (being invisible) would be aimed at purely programmatic use
and the latter (since it is a visible link) would be for a page that
gives editing UI.
I wonder, though, if marking up the edit link has a real use case.
What kind of tool would make use of it, and in what way?
Regards,
Maciej
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
