Subject: 'edit-form' and 'create-form' link relations

From: Jan Algermissen <[email-masked]>
Date: Tue, 16 Oct 2012 20:42:25 +0200

Hi,

http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-08

I think the latest version of the draft is ready to go. I approve the specified link relations.

@Julian, @Mark: I am still lost process wise. What's next?

Jan

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 16 Oct 2012 22:44:22 +0400

Thanks! 

ioseb

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Oct 2012 21:13:48 +0200

On 2012-10-16 20:42, Jan Algermissen wrote:
> ...

The Internet Draft needs to be published as RFC. 
<http://www.ietf.org/tao.html#rfc.section.6.1> has some instructions for 
publishing in the IETF stream.

Alternatively, one can try an individual submission to the RFC Editor, 
see <https://www.rfc-editor.org/indsubs.html>.

Best regards, Julian

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Tue, 16 Oct 2012 23:59:37 +0400

Hi Julian,

Thank you very much!

@Jan

I sent email to [email-masked] with all necessary details listed on this page https://www.rfc-editor.org/indsubs.html.

Best regards,
ioseb

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 17:01:36 -0700

Just some quick feedback based on an initial read of the specification...
Note: I have not had direct implementation experience with this particular
mechanism so please take this feedback for what it's worth...

Several points:

1. In general these seem useful, but I'm concerned that they may make some
unspecified assumptions... seemingly assuming that an html form is always
on the other side of the link without actually coming out and saying so.

2. create-form seems too specific to me at first review. Why not simply
"create" and allow the media type of the referenced resource specify
exactly what kind of thing it is.

For example:

  Link: <http://example.org/atompub/collection>; rel="create";
type="application/atom+xml"

Could potentially be used to tell me where to post new items to an Atompub
collection.

  Link: <http://example.org/html/foo.html>; rel="create"; type="text/html"

Essentially tells me that there's an HTML page presumably with instructions
or a form for editing.

If you went with this approach, the existing "edit" link relation could
similarly be used in place of "edit-form". Note that the definition of the
existing "edit" link relation is that it "refers to a resource that can be
used to edit the link's context"... seems like a pretty good fit to me.

  Link: <http://example.org/html/edit.html>; rel="edit"; type="text/html"

3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are
necessary at all. Nor is the error handling bit in section 3.3.

- James

On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen <
[email-masked]> wrote:

> _______________________________________________
> link-relations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/link-relations
>

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 17 Oct 2012 08:13:51 +0200

Hi James,

On Oct 17, 2012, at 2:01 AM, James M Snell wrote:

> Just some quick feedback based on an initial read of the specification... Note: I have not had direct implementation experience

I do since yesterday :-) Suddenly popped up.

> with this particular mechanism so please take this feedback for what it's worth...
> 
> Several points:
> 
> 1. In general these seem useful, but I'm concerned that they may make some unspecified assumptions... seemingly assuming that an html form is always on the other side of the link without actually coming out and saying so.

I never saw it that way. Why do you think there is an HTML-form assumption?

> 
> 2. create-form seems too specific to me at first review. Why not simply "create" and allow the media type of the referenced resource specify exactly what kind of thing it is. 
> 
> For example:  
> 
>   Link: <http://example.org/atompub/collection>; rel="create"; type="application/atom+xml"
> 
> Could potentially be used to tell me where to post new items to an Atompub collection.
> 

Hmm, I think you are misreading the rels. They are only for finding the form that tells me how to construct what I send to the creation (or update) URI which I know already.

> 
> Essentially tells me that there's an HTML page presumably with instructions or a form for editing.

The question of the form format would be negotiated during the GET form request/response roundtrip. The form could be available in many representations, actually.

> 
> If you went with this approach, the existing "edit" link relation could similarly be used in place of "edit-form". Note that the definition of the existing "edit" link relation is that it "refers to a resource that can be used to edit the link's context"... seems like a pretty good fit to me.

IIRC 'edit' has more the semantic of 'this is the primary URI of a resource where you should turn to to make changes. I agree that you could read atom that way, but seems like unclear wording to me.

> 3. I don't believe the requirements in sections 3.1.1 and 3.2.1 are necessary at all. Nor is the error handling bit in section

Yeah, was thinking the same. OTH, I found it interesting that Ioseb thought of them and I had discussions yesterday that are directly answered by these sections.

Thanks for taking a look.

Jan

> 3.3.
> 
> - James
> 
> 
> On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen <[email-masked]> wrote:
> Hi,
>

---

From: Ioseb Dzmanashvili <[email-masked]>
Date: Wed, 17 Oct 2012 10:24:03 +0400

Hi James, 

Thanks for feedback, i can't add anything to Jan's comments. Similar issues were discussed in the past on this mailing list and i think all of them were clarified and spec was adjusted several times accordingly. 

Best regards,
ioseb

On Wednesday, October 17, 2012 at 10:13 AM, Jan Algermissen wrote:

> > On Tue, Oct 16, 2012 at 11:42 AM, Jan Algermissen <[email-masked] (mailto:[email-masked])> wrote:
> > Hi,
> > 
> > [email-masked] (mailto:[email-masked])

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 23:48:31 -0700

On Tue, Oct 16, 2012 at 11:13 PM, Jan Algermissen <
[email-masked]> wrote:

> > Just some quick feedback based on an initial read of the
> specification... Note: I have not had direct implementation experience
>
> > 1. In general these seem useful, but I'm concerned that they may make
> some unspecified assumptions... seemingly assuming that an html form is
> always on the other side of the link without actually coming out and saying
> so.
>
Just the overall impression I had on my initial read through, really. I
cannot point to anything specific other than, perhaps, the language in
Sections 3.1.1 and 3.2.1... perhaps a simple clarification on this point
would be helpful in a future iteration, just to make it clear that no
assumption is being made as to the type of resource being linked to.

> Hmm, I think you are misreading the rels. They are only for finding the
> form that tells me how to construct what I send to the creation (or update)
> URI which I know already.
>
>
No I got that part; all I was suggesting is that there is a possibly useful
overlap with the more general case i illustrated.

> The question of the form format would be negotiated during the GET form
> request/response roundtrip. The form could be available in many
> representations, actually.
>
>
Like I said, a simple clarification along these lines in the draft would be
helpful :-)

> IIRC 'edit' has more the semantic of 'this is the primary URI of a
> resource where you should turn to to make changes. I agree that you could
> read atom that way, but seems like unclear wording to me.
>
>
Yes.. I agree it's hazy... the point I'm making is that there's a very
fuzzy line between "primary URI of a resource where you should turn to make
changes" and "URI of the form where change can be made". It's just
different ways of editing different types of resources.

Currently, the "edit" link relations semantics are extremely fuzzy for
anything other than atom resources and I have seen occasional instances of
the "edit" link being used within html for exactly the same kind of use
case as edit-form... tho admittedly such examples have been quite rare.

I'm certainly not opposed to have the new link relations, but I would
rather reuse existing ones if at all possible.

> necessary at all. Nor is the error handling bit in section
>
> Yeah, was thinking the same. OTH, I found it interesting that Ioseb
> thought of them and I had discussions yesterday that are directly answered
> by these sections.
>
>
Being thorough is good, but I think it makes too many assumptions about how
the form on the other end of the link is represented and processed. There
may not be a submission URI involved at all, for instance.. it all depends
on what the representation of that form is and it's associated processing
model, neither of which are assumed or defined by the draft. In other
words, the spec is just fine without those sections.

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 17 Oct 2012 00:04:44 -0700

The last thing I will note is that, while it's certainly something that has
fallen out of style, there is some precedence to using "edit" link rels for
this purpose... for historical reference, see
http://universaleditbutton.org/Universal_Edit_Button. It's definitely not
something that is in broad use today, but the same basic concepts were
utilized and the use of the "edit" link relation was one of two main
variations. You can even still find them around if you look hard enough [1]
;-). (It is humorous to note that the Universal Edit Button wiki itself
does not appear to provide support for the Universal Edit Button)

[1] view-source:http://c2.com/cgi/wiki?FrontPage

On Tue, Oct 16, 2012 at 11:48 PM, James M Snell <[email-masked]> wrote:

> No I got that part; all I was suggesting is that there is a possibly
> useful overlap with the more general case i illustrated.
>
>
>>  >
> Like I said, a simple clarification along these lines in the draft would
> be helpful :-)
>
>
>>
>> >
> Being thorough is good, but I think it makes too many assumptions about
> how the form on the other end of the link is represented and processed.
> There may not be a submission URI involved at all, for instance.. it all
> depends on what the representation of that form is and it's associated
> processing model, neither of which are assumed or defined by the draft. In
> other words, the spec is just fine without those sections.
>
> - James
>
>