[uf-discuss] rel-edit

[Benjamin Hawkes-Lewis]

Maciej Stachowiak wrote:
> 
> 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.

It doesn't make any sense to me. When browsers (e.g. Opera) or 
extensions (e.g. Firefox Link Widgets) properly expose <link>ed 
resources, they are just as visible as anchors. That would work very nicely.

Naming two entirely different things the same invariably produces 
confusion (e.g. some authors don't understand the rather different 
semantics of the cite attribute and the cite element). Making names have 
semantics dependent on context is even worse. Making a new link type 
work differently to other link types by having two sets of semantics is 
also a bad idea IMHO.

> 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?

Browsers could be configured to open webmail compose links in a new 
window. Compare your suggestion of this use-case to the WHATWG list:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/011098.html

Now Atom's semantics may throw a cog in the wheel of rel="edit". But how 
about differentiating rel="edit" from Atom's rel="edit" by using 
rel="compose" instead? Or, alternatively, we could try and get the Atom 
draft changed to use rel="put" since "edit" is rather vague?

--
Benjamin Hawkes-Lewis