rel-edit

Hi, everybody.

** Context **

So, on the tail of RecentChangesCamp Montreal
(http://www.rocococamp.inf
o/), there's an effort to work out some
universal conventions for wiki engines to indicate that a
page is
editable.

The current focus is on an icon next to the "edit this
page" link (or
language equivalent) to indicate that the link activates a
tool
(probably a page with an HTML form, but possibly a WYSIWYG
edit mode)
that will let the user edit the page.

You can follow this discussion here:

        http:/
/www.aboutus.org/UniversalWikiEditButton

The idea is to make something as ubiquitous as the RSS
"orange radio
waves" icon.

** rel-edit **

An icon will be helpful for human beings, but it could also
be very
useful to define a microformat for "the edit
link". This link is almost
universal in the wikisphere. There are several hundred wiki
engines in
active use today:

        http://c2.com/cgi/
wiki?WikiEngines

In terms of pages on the Web, there are literally millions
of pages with
"edit" links on Wikimedia projects alone. Adding
in the thousands of
other wikis on the web, this is a very common link
relationship.

A well-defined microformat would not be limited to wikis; it
would also
be useful for other kinds of editable Web pages or sections
thereof. In
particular, for certain content-management systems, there is
sometimes
an "edit" link (when the current user has rights
to edit the page), as
well as for certain blogging software. If carefully managed,
editable
comments or forum posts could have their edit-links marked,
too.

The microformat would be useful for formatting directives
(for example,
the above-mentioned icon could be placed before or after the
link using
CSS). It could also be useful for smart Web browsers or
browser
extensions; they could use an additional gesture, command
key, button,
or menu input to let the user "edit this page".

I think this microformat would be best defined using the
semantics of
the "rel" attribute of <a> links. For
example, on the "how-to-play" page
on the microformats wiki, this link:

        <a
href="/wiki?title=how-to-play&amp;action=edit"
>Edit</a>

would be changed to:

        <a
href="/wiki?title=how-to-play&amp;action=edit"
rel="edit">Edit</a>

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.

Thanks,

-Evan

P.S. There may be a case to cover all the "CRUD"
actions that can
performed on a page with their own microformats; I'd like to
leave that
out of scope for this discussion.

        http:
//en.wikipedia.org/wiki/CRUD_%28acronym%29

If handled carefully, I think a limited-scope rel-edit would
be
compatible and consistent with any future CRUD
microformats.

-- 
Evan Prodromou <evanprodromou.name>
http://evan.prodromou.nam
e/

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Evan Prodromou wrote:
>...
> I think this microformat would be best defined using
the semantics of
> the "rel" attribute of <a> links. For
example, on the "how-to-play" page
> on the microformats wiki, this link:
> 
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
>Edit</a>
> 
> would be changed to:
> 
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
rel="edit">Edit</a>
> 
> 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.

-John
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Hi Evan,

I like it! This would also be useful for linking to the
editable  
version of data for a REST Service Description.

-enp
On May 25, 2007, at 6:06 PM, Evan Prodromou wrote:

> Hi, everybody.
>
> ** Context **
>
> So, on the tail of RecentChangesCamp Montreal
> (http://www.rocococamp.inf
o/), there's an effort to work out some
> universal conventions for wiki engines to indicate that
a page is
> editable.
>
> The current focus is on an icon next to the "edit
this page" link (or
> language equivalent) to indicate that the link
activates a tool
> (probably a page with an HTML form, but possibly a
WYSIWYG edit mode)
> that will let the user edit the page.
>
> You can follow this discussion here:
>
>         http:/
/www.aboutus.org/UniversalWikiEditButton
>
> The idea is to make something as ubiquitous as the RSS
"orange radio
> waves" icon.
>
> ** rel-edit **
>
> An icon will be helpful for human beings, but it could
also be very
> useful to define a microformat for "the edit
link". This link is  
> almost
> universal in the wikisphere. There are several hundred
wiki engines in
> active use today:
>
>         http://c2.com/cgi/
wiki?WikiEngines
>
> In terms of pages on the Web, there are literally
millions of pages  
> with
> "edit" links on Wikimedia projects alone.
Adding in the thousands of
> other wikis on the web, this is a very common link
relationship.
>
> A well-defined microformat would not be limited to
wikis; it would  
> also
> be useful for other kinds of editable Web pages or
sections  
> thereof. In
> particular, for certain content-management systems,
there is sometimes
> an "edit" link (when the current user has
rights to edit the page), as
> well as for certain blogging software. If carefully
managed, editable
> comments or forum posts could have their edit-links
marked, too.
>
> The microformat would be useful for formatting
directives (for  
> example,
> the above-mentioned icon could be placed before or
after the link  
> using
> CSS). It could also be useful for smart Web browsers or
browser
> extensions; they could use an additional gesture,
command key, button,
> or menu input to let the user "edit this
page".
>
> I think this microformat would be best defined using
the semantics of
> the "rel" attribute of <a> links. For
example, on the "how-to-play"  
> page
> on the microformats wiki, this link:
>
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
>Edit</a>
>
> would be changed to:
>
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
 
> rel="edit">Edit</a>
>
> 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.
>
> Thanks,
>
> -Evan
>
> P.S. There may be a case to cover all the
"CRUD" actions that can
> performed on a page with their own microformats; I'd
like to leave  
> that
> out of scope for this discussion.
>
>         http:
//en.wikipedia.org/wiki/CRUD_%28acronym%29
>
> If handled carefully, I think a limited-scope rel-edit
would be
> compatible and consistent with any future CRUD
microformats.
>
> -- 
> Evan Prodromou <evanprodromou.name>
> http://evan.prodromou.nam
e/
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discussmicroformats.org
> http://microformats.org/mailman/listinfo/microforma
ts-discuss

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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?

-Evan

-- 
Evan Prodromou <evanprodromou.name>

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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

A little testimony: I'm programming a CMS that enables
several links
to edit content. One of these links is to a global
"edit this article"
page ; the other links are for in-context edition
("edit this title").
A click on such a local in-context edit link will call a
little
javascript, that will fetch an edit form via
"ajax", and on and on.

Currently the markup we use for the first link is a
<a>, we could add
rel="edit". No problem here.

For in-context edition, there is no <a>, it's just a
class that's
appended to to the element. Ex:
    <h1 class="crayon
article-titre-34">Titre</h1>
our js script is going to read the page, find the .crayon
elements and
add to them all that's necessary to make hem editable
(event
processing and so on). .article-titre-34 means it's the
title from the
entry 34 in the articles table.

I think the latter example is typical of a tool that could
use
rel=edit stuff. But in this case, how could it be?

-- Fil
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

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/what
wg-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
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On May 27, 2007, at 5:09 AM, Benjamin Hawkes-Lewis wrote:

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

When browsers or extensions expose <link>ed resources,
they generally  
do so for a selected set of <link> types (for example,
<link  
rel="stylesheet"> is not exposed) and often do
so with specialized UI  
(for instance, feed links, those being <link
rel="alternate"> with a  
syndication feed MIME type, or per HTML5 ones with
rel="alternate  
feed" are often displayed

Some link relationships only make sense on one of <a>
or <link>. That  
being said, I think it makes more sense to call a link to a
page with  
editing UI rel="edit", than one with a PUT-able
location for the  
document, I would call the latter rel="writeable".
Since Atom  
Publishing Protocol is only a draft, I wouldn't assume it is
 
unchangeable, and they seem to have take a notion of
"edit" that is  
pretty specific to newsreader applications.

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

My understanding of the proposal is that
rel="edit" is intended for a  
link to edit the current document, as in a wiki. Thus, it
would not  
be appropriate, as proposed, to put on a webmail compose
link, or  
even a webmail reply link, since neither is an example of
editing the  
current document.

Additionally, I think it would be really bad for
interoperability if  
some but not all browsers interpreted rel="edit"
to mean "open in a  
new window". So this idea is unlikely to be
implemented.

> Compare your suggestion of this use-case to the WHATWG
list:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.o
rg/2007-April/ 
> 011098.html

Actually, that suggestion was about links *in* mail messages
that you  
received, which being viewed in a webmail client. And in the
context  
of link targeting. I don't think it is related to the
rel="edit"  
proposal.

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

Sounds to me like rel="compose" would not be a
good way to label the  
"edit this page" link on a wiki page.

Getting back to the proposal, the canonical use for
rel="edit"  
proposed was for "edit this page" links on wikis
and similar. To  
determine if it is useful, I think we need to identify what
things  
web browsers, data mining tools, browser extensions or other
user  
agents might do with the knowledge that some particular link
is an  
"edit this page" or "edit this section"
link.

Regards,
Maciej



_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Maciej Stachowiak wrote:

> When browsers or extensions expose <link>ed
resources, they generally
> do so for a selected set of <link> types (for
example, <link 
> rel="stylesheet"> is not exposed)

It is when you have a series of alternate stylesheets (in
Firefox, 
anyhow), isn't it?

> and often do so with specialized UI (for instance, feed
links, those 
> being <link rel="alternate"> with a
syndication feed MIME type, or
> per  HTML5 ones with rel="alternate feed" are
often displayed
> 
> Some link relationships only make sense on one of
<a> or <link>.

None of that equates to having a single name for two
/different/ link 
relationships.

> That being said, I think it makes more sense to call a
link to a page with
>  editing UI rel="edit", than one with a
PUT-able location for the 
> document, I would call the latter
rel="writeable". Since Atom
> Publishing Protocol is only a draft, I wouldn't assume
it is
> unchangeable, and they seem to have take a notion of
"edit" that is
> pretty specific to newsreader applications.

Agreed.

> My understanding of the proposal is that
rel="edit" is intended for a
>  link to edit the current document, as in a wiki. Thus,
it would not
> be appropriate, as proposed, to put on a webmail
compose link, or
> even a webmail reply link, since neither is an example
of editing the
> current document.

Hmm. Yes I agree there is a distinction between editing the
current
resource and creating a new document. My main point was that
this could 
be used for deciding when to open a new window.

> Additionally, I think it would be really bad for
interoperability if
>  some but not all browsers interpreted
rel="edit" to mean "open in a
> new window". So this idea is unlikely to be
implemented.

Why would UAs behaving differently with respect to
rel="edit" be bad for 
interoperability? UAs already differ when it comes to
opening new 
windows. And rel attributes give users criteria by which to
decide 
whether to open new windows, rather than have it dictated by
authors.

>> Compare your suggestion of this use-case to the
WHATWG list:
>> 
>> http://lists.whatwg.org/htdig.cgi/what
wg-whatwg.org/2007-April/011098.html
>> 
>> 
> 
> Actually, that suggestion was about links *in* mail
messages that you
>  received, which being viewed in a webmail client. And
in the context
> of link targeting. I don't think it is related to the
rel="edit"
> proposal.

Eek, sorry Maciej. I misremembered your WHATWG post and
didn't reread it
carefully enough (I compose emails in a new window and
completely 
confused the two).

>> 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?
> 
> Sounds to me like rel="compose" would not be
a good way to label the
>  "edit this page" link on a wiki page.

Agreed.

> Getting back to the proposal, the canonical use for
rel="edit"
> proposed was for "edit this page" links on
wikis and similar. To
> determine if it is useful, I think we need to identify
what things
> web browsers, data mining tools, browser extensions or
other user
> agents might do with the knowledge that some particular
link is an
> "edit this page" or "edit this
section" link.

A second use-case for rel="edit" (or whatever)
would be to add a Edit 
link to the navigation toolbar. This would provide a more
consistent UI: 
no more searching around for the edit link.

--
Benjamin Hawkes-Lewis
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Has any thought been given to the pre-existing in-the-wild
use of rel=EditURI?

<link rel="EditURI"
type="application/rsd+xml" title="RSD"
href="/xmlrpc.php?rsd" />

-- 
Chris Griego

On 5/25/07, Evan Prodromou <evanprodromou.name> wrote:
> Hi, everybody.
>
> ** Context **
>
> So, on the tail of RecentChangesCamp Montreal
> (http://www.rocococamp.inf
o/), there's an effort to work out some
> universal conventions for wiki engines to indicate that
a page is
> editable.
>
> The current focus is on an icon next to the "edit
this page" link (or
> language equivalent) to indicate that the link
activates a tool
> (probably a page with an HTML form, but possibly a
WYSIWYG edit mode)
> that will let the user edit the page.
>
> You can follow this discussion here:
>
>         http:/
/www.aboutus.org/UniversalWikiEditButton
>
> The idea is to make something as ubiquitous as the RSS
"orange radio
> waves" icon.
>
> ** rel-edit **
>
> An icon will be helpful for human beings, but it could
also be very
> useful to define a microformat for "the edit
link". This link is almost
> universal in the wikisphere. There are several hundred
wiki engines in
> active use today:
>
>         http://c2.com/cgi/
wiki?WikiEngines
>
> In terms of pages on the Web, there are literally
millions of pages with
> "edit" links on Wikimedia projects alone.
Adding in the thousands of
> other wikis on the web, this is a very common link
relationship.
>
> A well-defined microformat would not be limited to
wikis; it would also
> be useful for other kinds of editable Web pages or
sections thereof. In
> particular, for certain content-management systems,
there is sometimes
> an "edit" link (when the current user has
rights to edit the page), as
> well as for certain blogging software. If carefully
managed, editable
> comments or forum posts could have their edit-links
marked, too.
>
> The microformat would be useful for formatting
directives (for example,
> the above-mentioned icon could be placed before or
after the link using
> CSS). It could also be useful for smart Web browsers or
browser
> extensions; they could use an additional gesture,
command key, button,
> or menu input to let the user "edit this
page".
>
> I think this microformat would be best defined using
the semantics of
> the "rel" attribute of <a> links. For
example, on the "how-to-play" page
> on the microformats wiki, this link:
>
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
>Edit</a>
>
> would be changed to:
>
>         <a
href="/wiki?title=how-to-play&amp;action=edit"
rel="edit">Edit</a>
>
> 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.
>
> Thanks,
>
> -Evan
>
> P.S. There may be a case to cover all the
"CRUD" actions that can
> performed on a page with their own microformats; I'd
like to leave that
> out of scope for this discussion.
>
>         http:
//en.wikipedia.org/wiki/CRUD_%28acronym%29
>
> If handled carefully, I think a limited-scope rel-edit
would be
> compatible and consistent with any future CRUD
microformats.
>
> --
> Evan Prodromou <evanprodromou.name>
> http://evan.prodromou.nam
e/
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss