[uf-discuss] rel-edit

[Maciej Stachowiak]

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