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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
