mjs at apple.com
Sat May 26 13:30:54 PDT 2007
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
>>> I'd like to gather some feedback on this mailing list.
>> Just FYI: The Atom Publishing Protocol draft spec uses <link
>> .../> 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
> first part ("point from a read-only representation of a resource to an
>> alternative URI that allows for editing operations") sounds
> 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
> 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"
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?
More information about the microformats-discuss