From jan.algermissen@nordsc.com Mon May 7 11:26:46 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A33E21F86D4 for ; Mon, 7 May 2012 11:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aok2M4NLkiYm for ; Mon, 7 May 2012 11:26:45 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6280E21F86D0 for ; Mon, 7 May 2012 11:26:45 -0700 (PDT) Received: from [192.168.2.103] (p548FB2E0.dip.t-dialin.net [84.143.178.224]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M0v6Z-1S9nnq0XHj-00v48H; Mon, 07 May 2012 20:26:41 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2012 20:26:39 +0200 Message-Id: <9E76E002-D90C-445A-B664-B2D70A65469C@nordsc.com> To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:+IxA5GJzylAPAhWBcXBDgdwBnZCj8TdjIwghvwS02Ii jKmkxoUcTigGvnL1729qBjoRgJzW3tkMde7uo3ikrTn8ye7+Le fLpTg7M5llMFuokuhK9aMSEEfoYrY1LP5oXReIUtYbY36pgTuR QnxFZotbBjS802vQdO3sSZbR/ti40f1rmk25Z+rZWg3NDqXlSM r+XvosT0nc12OOLN4fB35ArST0s/XOU9U3D2/brABOSflSUEVD RgjKMATisJoC/gMOKzzmoSCmJ0F5zPypmpVAFjA0JLU/9p+YcV xE8ODNKgErF/lMV+RY3sGtSbOFT3U7ckeoEwraJx6WnTG0zII4 lkUMi5A+wIjnQvqqM01ANU6g+SkDoasUaOxD39h8whl/HDTMYl bONoxgFCUhVLw== Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:26:46 -0000 Hi Ioseb, I have just looked at your draft[1] and have a couple of questions: You mention two link relations, but so far I can only see one ('form'). = Which is the other one you are going to define? What is the exact purpose of the 'form' link relation? AFAIU the client = would do a GET on the link target and interpret the response body as a = form for adding entries. Can you explain a bit, what the use cases are you have in mind for this? = Does it make sense to define such a relation in a general manner? Why? = Do you envision the specification of certain media types for the forms = to be returned? Then you mention the use of 'form' to edit single member entries. I find = this to be problematic because the meaning of the returned form (that = is, the effect of submitting the form, depends on the context in which = the form has been found. In one case it will be 'add a member' in the = other it will be 'update a resource'. Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found.=20 ..... Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on = that approach for your purpose? Jan [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt [2] http://www.markbaker.ca/2003/05/RDF-Forms/= From ioseb.dzmanashvili@gmail.com Tue May 8 01:21:43 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4948521F864C for ; Tue, 8 May 2012 01:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr2Y1+41mnVH for ; Tue, 8 May 2012 01:21:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 179F121F8645 for ; Tue, 8 May 2012 01:21:40 -0700 (PDT) Received: by bkty8 with SMTP id y8so5264460bkt.31 for ; Tue, 08 May 2012 01:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Qk1FjQLEnVXgyUswNB5CwaadfQx0WRUxH3Ue0/t3ooE=; b=g2PUdjmCk86S5jvTm/UKSfCOb0H5J4hMsEt0wB4OogPZwxiXbzqvDpBV0rVfmhQy1Q BOu6FdnlDxH/YohQWqwIWCYT0i/pmbIXqHgCYxWR2EFOBOX0Z/4muIbvpcQs4eL/IKs0 5mFdhb8+iY6Uay7I2/HBq86L5dYKODO9MaCQ9BJDRtxdD0GKY25+z1vHyJaralhfHh+2 3zxogVqWvr9tKQVCvvmCg6fEdAFT+Isecrhi8W6Ftv681/1N380Rv2N/zdP9DG/kUrzO u4SXGurlrNG3GAtqWwIbccnM7kPCkLCAp2MreS0Q4p1RhuyFsretYQsKKpziQrI9O9ve dbjg== MIME-Version: 1.0 Received: by 10.204.153.199 with SMTP id l7mr6310093bkw.86.1336465300022; Tue, 08 May 2012 01:21:40 -0700 (PDT) Received: by 10.204.112.75 with HTTP; Tue, 8 May 2012 01:21:39 -0700 (PDT) Date: Tue, 8 May 2012 12:21:39 +0400 Message-ID: From: Ioseb Dzmanashvili To: link-relations@ietf.org Content-Type: multipart/alternative; boundary=0015175d075e76663d04bf8213f8 Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 08:21:43 -0000 --0015175d075e76663d04bf8213f8 Content-Type: text/plain; charset=ISO-8859-1 Hello Jan, Thanks for the questions! > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. Exactly. > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? As i see it i believe it makes total sense. I use it for several purposes and i'm finding it really useful in lot of cases: - When *read* representation of the resource is different and doesn't contain enough informations about resource properties(which property is editable, which is not, which is required which is optional etc..) - When using different media types, for example if resource is represented in media format which lacks write semantics i use this link relation with type attribute, dereferencing of target URI returns resource representation which describes writing/editing requirements. - When have a long list of editable items and it's not reasonable to include write forms alongside with items - When have an API which most of the time is used for reading purposes but also offer write capabilities. - When building self describing APIs which may guide clients through write process without need in any additional information. (for additional information here is the thread related to this relation: http://www.ietf.org/mail-archive/web/link-relations/current/msg00313.html) > Do you envision the specification of certain media types for the forms to be returned? Any media type which offers "form" semantics can be used. There was no specific media type on my mind when i was thinking about it. What i can say from my practice i was always using XHTML forms(application/xhtml+xml) and some custom JSON formats for such purposes. Recently i heavily started to use: - Collection+JSON: http://amundsen.com/media-types/collection/format/ (application/vnd.collenction+json) and it's extension(which i authored) - Collection.next+JSON: http://code.ge/media-types/collection-next-json/(application/vnd.collection.next+json) Both are registered media types and both offer *forms*. > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. As i noted above i use media types which already offer *form* capabilities, additionally Collection.next+JSON offers *method* attribute which can be successfully used for indicating this distinction(IMHO of course). I do not see problems with dedicated media type, though i do not think it's an ideal solution. As i understand this will create dependency on media type. > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? I'm aware of RDF Forms, but i do not see it as a solution for everything and especially for simple cases where JSON interaction works really well. Below is the simple example use case: ==Request== | GET /users HTTP/1.1 | Host: service.org | Accept: application/vnd.collection.next+json ==Response== | HTTP/1.1 200 Ok | Content-Type: application/vnd.collection.next+json | Content-Length: ... | {"collection": { | "version": "1.0", | "href": "http://service.org/users", | "items": [ | { | "href" : "http://service.org/users/john-doe", | "data" : [ | {"name": "name", "value": "John Doe", "prompt": "Full name"}, | {"name": "email", "value": "john@doe.com", "prompt": "Email"}, | {"name": "website", "value": "", "Prompt": "Website"} | ], | "links" : [ | { | "href": "http://service.org/users/john-doe/form", | "rel": "form", | "type": "application/vnd.collection.next+json" | "prompt": "Edit user" | } | ] | }, | {...}, | {...}, | {...} | ] | }} ==Request: dereference the form resource== | GET /users/john-doe/form HTTP/1.1 | Host: service.org | Accept: application/vnd.collection.next+json ==Response== | HTTP/1.1 200 Ok | Content-Type: application/vnd.collection.next+json | Content-Length: ... | {"collection": { | "version": "1.0", | | "template": { | "method": { | "options": [ | {"value": "PUT", "prompt": "Replace Entry"}, | {"value": "PATCH", "prompt": "Modify Entry"} | ] | }, | "data": [ | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, | {"name": "website", "value": "", "prompt": "Website", "type": "url"} | ] | } | }} ==Request: submit the modified form element== | PATCH /users/john-doe HTTP/1.1 | Host: service.org | Content-Type: application/vnd.collection.next+json | Content-Length: ... | {"template": { | "data": [ | {"name": "website", "value": "http://john.doe.com"} | ] | }} Best regards, Ioseb > ---------- Forwarded message ---------- > From: Jan Algermissen > To: link-relations@ietf.org > Cc: > Date: Mon, 7 May 2012 20:26:39 +0200 > Subject: [link-relations] Review of > draft-ioseb-dzmanashvili-link-relation-00 > Hi Ioseb, > > I have just looked at your draft[1] and have a couple of questions: > > You mention two link relations, but so far I can only see one ('form'). > Which is the other one you are going to define? > > What is the exact purpose of the 'form' link relation? AFAIU the client > would do a GET on the link target and interpret the response body as a form > for adding entries. > > Can you explain a bit, what the use cases are you have in mind for this? > Does it make sense to define such a relation in a general manner? Why? Do > you envision the specification of certain media types for the forms to be > returned? > > Then you mention the use of 'form' to edit single member entries. I find > this to be problematic because the meaning of the returned form (that is, > the effect of submitting the form, depends on the context in which the form > has been found. In one case it will be 'add a member' in the other it will > be 'update a resource'. > > Have you considered using media type semantics instead of link relations? > It would in my opinion be better to define a form media type and make the > distinction between add and edit part of the type, not of the context in > which a link is found. > > ..... > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that > approach for your purpose? > > Jan > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > > -- Ioseb Dzmanashvili Lead Architect Picktek LLC 24b Khazbegi ave. Tbilisi, 0177, Georgia T (+995 32) 39.58.56, F (+1 202) 315.3934 picktek.com code.ge github.com/ioseb twitter.com/iosebi --0015175d075e76663d04bf8213f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Jan,=A0

Than= ks for the questions!=A0

> You mention two link= relations, but so far I can only see one ('form'). Which is the ot= her one you are going to define?

I'm not sure regarding this, i never mentioned anot= her link relation type. I only created draft for form?=A0

> What is the exact purpose of the 'form' link relation?= AFAIU the client would do a GET on the link target and interpret the respo= nse body as a form for adding entries.

Exactly.

>=A0Can you explai= n a bit, what the use cases are you have in mind for this? Does it make sen= se to define such a relation in a general manner? Why?

As i see it i believe it makes total sense. I use it for several purpo= ses and i'm finding it really useful in lot of cases:

- When *read* representation of the resource is different and doesn= 't contain enough informations about resource properties(which property= is editable, which is not, which is required which is optional etc..)
- When using different media types, for example if resource is represe= nted in media format which lacks write semantics i use this link relation w= ith type attribute, dereferencing of target URI returns resource representa= tion which describes writing/editing requirements.=A0
- When have a long list of editable items and it's not reasonable = to include write forms alongside with items
- When have an API wh= ich most of the time is used for reading purposes but also offer write capa= bilities.=A0
- When building self describing APIs which may guide clients through w= rite process without need in any additional information.=A0

<= /div>
(for additional information here is the thread related to this re= lation:=A0http://www.ietf.org/mail-archive/web/link-relations/cu= rrent/msg00313.html)

>=A0Do you envision the specification of certain med= ia types for the forms to be returned?

Any media t= ype which offers "form" semantics can be used. There was no speci= fic media type on my mind when i was thinking about it.=A0

What i can say from my practice i was always using XHTM= L forms(application/xhtml+xml) and some custom JSON formats for such purpos= es. =A0Recently i heavily started to use:

- Collec= tion+JSON:=A0http://amundsen.com/media-types/collection/format/=A0(application/vnd.= collenction+json)

and it's extension(which i authored)

=
- Collection.next+JSON:=A0http://code.ge/media-types/collection-next-json/= (application/vnd.collection.next+json)=A0

Both are registered media types and both offer *forms*.= =A0

>=A0Have you considered using media type se= mantics instead of link relations? It would in my opinion be better to defi= ne a form media type and make the distinction between add and edit part of = the type, not of the context in which a link is found.

As i noted above i use media types which already offer = *form* capabilities, additionally=A0Collection.next+JSON offers *method* at= tribute which can be successfully used for indicating this distinction(IMHO= of course). I do not see problems with dedicated media type, though i do n= ot think it's an ideal solution. As i understand this will create depen= dency on media type.=A0

>=A0Have you looked at Mark Baker's RDF Forms[2]= ? Maybe you can build on that approach for your purpose?

I'm aware of RDF Forms, but i do not see it as a solution for ev= erything and especially for simple cases where JSON interaction works reall= y well.

Below is the simple example use case:

=3D=3DRequest=3D=3D

| GET /users HTTP= /1.1
| Host: service.org
=
| Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

| HTTP/1.= 1 200 Ok
| Content-Type: application/vnd.collection.next+json
| Content-Length: ...

| {"collection&q= uot;: {
| =A0 "version": "1.0",
| =A0 "href= ": "http://service.org/users= ",
| =A0 "items": [
| =A0 =A0 {
| =A0 =A0 =A0 "href" : "http://service.org/users/john-doe",
| =A0 =A0 =A0 "data" : [
| =A0 =A0 =A0 =A0 {"= name": "name", =A0 =A0"value": "John Doe"= ;, =A0 =A0 "prompt": "Full name"},
| =A0 =A0 = =A0 =A0 {"name": "email", =A0 "value": "= john@doe.com", "prompt":= "Email"},
| =A0 =A0 =A0 =A0 {"name": "website", "value&= quot;: "", =A0 =A0 =A0 =A0 =A0 =A0 "Prompt": "Webs= ite"}
| =A0 =A0 =A0 ],
| =A0 =A0 =A0 "links&q= uot; : [
| =A0 =A0 =A0 =A0 {
| =A0 =A0 =A0 =A0 =A0 "href": =A0 "http://service.org/users/john-doe/form&q= uot;,=A0
| =A0 =A0 =A0 =A0 =A0 "rel": =A0 =A0"form= ",
| =A0 =A0 =A0 =A0 =A0 "type": =A0 "applica= tion/vnd.collection.next+json"
| =A0 =A0 =A0 =A0 =A0 "prompt": "Edit user"
<= div>| =A0 =A0 =A0 =A0 }
| =A0 =A0 =A0 ]
| =A0 =A0 },
| =A0 =A0 {...},
| =A0 =A0 {...},
| =A0 =A0 {..= .}
| =A0 ]
| }}


=3D=3DRequest: dereference the form reso= urce=3D=3D

| GET /users/john-doe/form HTTP/1.1
| Host: service.org
| A= ccept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

| HTTP/1.= 1 200 Ok
| Content-Type: application/vnd.collection.next+json
| Content-Length: ...

| {"collect= ion": {
| =A0 "version": "1.0",
|
| =A0 "template": {
| =A0 =A0 "method": {
| =A0 =A0 =A0 "options": [
| =A0 =A0 =A0 =A0 {= "value": "PUT", =A0 "prompt": "Replace E= ntry"},
| =A0 =A0 =A0 =A0 {"value": "PATCH", "prompt&= quot;: "Modify Entry"}
| =A0 =A0 =A0 ]
| =A0 = =A0 },
| =A0 =A0 "data": [
| =A0 =A0 =A0 {&qu= ot;name": "first_name", "value": "John",= "prompt": "First name", "required": true},
| =A0 =A0 =A0 {"name": "last_name", =A0"value= ": "Doe", =A0"prompt": "Last name", =A0&= quot;required": true},
| =A0 =A0 =A0 {"name": &quo= t;website", =A0 =A0"value": "", =A0 =A0 "prom= pt": "Website", =A0 =A0"type": =A0 =A0 "url&q= uot;}
| =A0 =A0 ]
| =A0}
| }}

= =3D=3DRequest: submit the modified form element=3D=3D

<= div>| PATCH /users/john-doe HTTP/1.1
| Host: service.org
| Content-Type: application/vnd.collection.next+json
| Conte= nt-Length: ...

| {"template": {
| =A0 "data": [
| =A0 =A0 {"name": "we= bsite", "value": "http:= //john.doe.com"}
| =A0 ]
| }}

Best regards,
Ioseb

=A0
---------- Forwarded message ----------
From:=A0Jan Algermissen <jan.algermissen@nordsc.com>= ;
To:=A0link-relations@ietf.o= rg
Cc:=A0
Date:=A0Mon, 7 May 2012 20:26:39 +0200
Subject:=A0[link-relati= ons] Review of draft-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draft[1] and have a couple of questions:

You mention two link relations, but so far I can only see one ('form= 9;). Which is the other one you are going to define?

What is the exact purpose of the 'form' link relation? AFAIU the cl= ient would do a GET on the link target and interpret the response body as a= form for adding entries.

Can you explain a bit, what the use cases are you have in mind for this? Do= es it make sense to define such a relation in a general manner? Why? Do you= envision the specification of certain media types for the forms to be retu= rned?

Then you mention the use of 'form' to edit single member entries. I= find this to be problematic because the meaning of the returned form (that= is, the effect of submitting the form, depends on the context in which the= form has been found. In one case it will be 'add a member' in the = other it will be 'update a resource'.

Have you considered using media type semantics instead of link relations? I= t would in my opinion be better to define a form media type and make the di= stinction between add and edit part of the type, not of the context in whic= h a link is found.

.....

Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on th= at approach for your purpose?

Jan


[1] http://www.ietf.org/id/draft-ioseb-dzmanashvili= -link-relation-00.txt
[2] http://www.markbaker.ca/2003/05/RDF-Forms/

_______________________________________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations


--
Ioseb Dzmanashvili
Lead Architect<= br> Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T (+995 32) = 39.58.56, F (+1 202) 315.3934
--0015175d075e76663d04bf8213f8-- From jan.algermissen@nordsc.com Thu May 10 14:13:42 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C18411E8085 for ; Thu, 10 May 2012 14:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-1.344, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU7Cbx6vOmsY for ; Thu, 10 May 2012 14:13:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACDD21F8624 for ; Thu, 10 May 2012 14:13:41 -0700 (PDT) Received: from [192.168.2.103] (p548FAF8C.dip.t-dialin.net [84.143.175.140]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MDCnY-1SKrSZ3MKa-00Grgu; Thu, 10 May 2012 23:13:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Thu, 10 May 2012 23:13:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> References: To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:tyd0zEXy3EIa+Ap07SDGDQUBjDVFM9YJtwtTKRLcAsd RoM0Zz8tOksnYNTB+cd6ZpNrY8SIyEhpkqYE8FzemdAixzL2Ma kTkpc7FhKswrWTamF0KFZ4Rku84C/MNW8SO4K4YFai2TC4/28v ybPhxc5vV7MtsJqhU1bJrAc1I/ZnDBZIUqSoPnF7Acoej5LNSH s/AIAsOZePC3tEki7VVT/gxmVNhheBF/jH2fqfCOhHQ5vmH5lX 7XtpcNOJk9GiOhDEg1SZHvE5PVEK/abaoPLpdjnL8PD5jBXf24 htQcdbpI6kfYgFvkaWNuNWQzv2Xp2Yli6EUU8j/12l9/6Kk0I0 sADYpYVwzCX8ys5TOFlvjQbWk1dHXdbWOMpLo3rlUdJE5NWaJW 2Sh7dB2mObbGA== Cc: link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 21:13:42 -0000 Ioseb, On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > Hello Jan,=20 >=20 > Thanks for the questions!=20 >=20 > > You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >=20 > I'm not sure regarding this, i never mentioned another link relation = type. I only created draft for form?=20 Your draft says: "This specification defines a pair of reciprocal link = relation types" - I took 'pair' to mean 'two' , no?=20 >=20 > Below is the simple example use case: >=20 > =3D=3DRequest=3D=3D >=20 > | GET /users HTTP/1.1 > | Host: service.org > | Accept: application/vnd.collection.next+json >=20 > =3D=3DResponse=3D=3D >=20 > | HTTP/1.1 200 Ok > | Content-Type: application/vnd.collection.next+json > | Content-Length: ... >=20 > | {"collection": { > | "version": "1.0", > | "href": "http://service.org/users", > | "items": [ > | { > | "href" : "http://service.org/users/john-doe", > | "data" : [ > | {"name": "name", "value": "John Doe", "prompt": "Full = name"}, > | {"name": "email", "value": "john@doe.com", "prompt": = "Email"}, > | {"name": "website", "value": "", "Prompt": = "Website"} > | ], > | "links" : [ > | { > | "href": "http://service.org/users/john-doe/form",=20 > | "rel": "form", How do I know the meaning of 'form' here? Will this add a new entry? Jan > | "type": "application/vnd.collection.next+json" > | "prompt": "Edit user" > | } > | ] > | }, > | {...}, > | {...}, > | {...} > | ] > | }} >=20 >=20 > =3D=3DRequest: dereference the form resource=3D=3D >=20 > | GET /users/john-doe/form HTTP/1.1 > | Host: service.org > | Accept: application/vnd.collection.next+json >=20 > =3D=3DResponse=3D=3D >=20 > | HTTP/1.1 200 Ok > | Content-Type: application/vnd.collection.next+json > | Content-Length: ... >=20 > | {"collection": { > | "version": "1.0", > | > | "template": { > | "method": { > | "options": [ > | {"value": "PUT", "prompt": "Replace Entry"}, > | {"value": "PATCH", "prompt": "Modify Entry"} > | ] > | }, > | "data": [ > | {"name": "first_name", "value": "John", "prompt": "First = name", "required": true}, > | {"name": "last_name", "value": "Doe", "prompt": "Last name", = "required": true}, > | {"name": "website", "value": "", "prompt": "Website", = "type": "url"} > | ] > | } > | }} >=20 > =3D=3DRequest: submit the modified form element=3D=3D >=20 > | PATCH /users/john-doe HTTP/1.1 > | Host: service.org > | Content-Type: application/vnd.collection.next+json > | Content-Length: ... >=20 > | {"template": { > | "data": [ > | {"name": "website", "value": "http://john.doe.com"} > | ] > | }} >=20 > Best regards, > Ioseb >=20 > =20 > ---------- Forwarded message ---------- > From: Jan Algermissen > To: link-relations@ietf.org > Cc:=20 > Date: Mon, 7 May 2012 20:26:39 +0200 > Subject: [link-relations] Review of = draft-ioseb-dzmanashvili-link-relation-00 > Hi Ioseb, >=20 > I have just looked at your draft[1] and have a couple of questions: >=20 > You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >=20 > What is the exact purpose of the 'form' link relation? AFAIU the = client would do a GET on the link target and interpret the response body = as a form for adding entries. >=20 > Can you explain a bit, what the use cases are you have in mind for = this? Does it make sense to define such a relation in a general manner? = Why? Do you envision the specification of certain media types for the = forms to be returned? >=20 > Then you mention the use of 'form' to edit single member entries. I = find this to be problematic because the meaning of the returned form = (that is, the effect of submitting the form, depends on the context in = which the form has been found. In one case it will be 'add a member' in = the other it will be 'update a resource'. >=20 > Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found. >=20 > ..... >=20 > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on = that approach for your purpose? >=20 > Jan >=20 >=20 > [1] = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations >=20 >=20 > --=20 > Ioseb Dzmanashvili > Lead Architect > Picktek LLC > 24b Khazbegi ave.=20 > Tbilisi, 0177, Georgia > T (+995 32) 39.58.56, F (+1 202) 315.3934 > picktek.com > code.ge > github.com/ioseb > twitter.com/iosebi >=20 From ioseb.dzmanashvili@gmail.com Thu May 10 23:26:06 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897C421F862A for ; Thu, 10 May 2012 23:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLyHRR9cHTiv for ; Thu, 10 May 2012 23:26:05 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9775421F8621 for ; Thu, 10 May 2012 23:26:04 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1640250wgb.13 for ; Thu, 10 May 2012 23:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=al7spoItx8kVK3xhXKNUu7EFmwi4qNHNCuVZCAkjq9c=; b=zJXm8Pv3P3ft4FNdkAZx/CgYGW5T/TtS31yLnz4kKvyVh+sZ8/zDUrac0h9HSv1Ci4 QMvwbENwPDUc35Cdi1cKtbAz/0P8IhWnmPsIMOeUqILeWiDZONj4Et7knBYODffhx10F 5nK6t/2Nw460HN8g7/Hy1Qzra1eHJ3sgu/q6nZAhiyhvFyi14qYuh/QduBFxMGr/aE7C 28WcBC0CU386QTyPPMChJ9fJT0VvG9sHJ2x3hkxE4XgkoMiHykd+Gec51f/7otFXNeam TivWqgOEQf81z+yzQc1P/+lKZIsY/kpHSbmllNm0mCe+Yu9o0htGHUbWp/yAcIT1nZ2j +0NA== Received: by 10.180.101.103 with SMTP id ff7mr4471524wib.6.1336717560341; Thu, 10 May 2012 23:26:00 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id ca3sm8424779wib.6.2012.05.10.23.25.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 23:25:59 -0700 (PDT) Date: Fri, 11 May 2012 10:43:37 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <6442AB1C71774490B05C323008C5CB4F@gmail.com> In-Reply-To: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4facb519_5f94dc03_1745" Cc: link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 06:26:06 -0000 --4facb519_5f94dc03_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > Ioseb, > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > Hello Jan, > > > > Thanks for the questions! > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? Thanks for pointing this, i didn't notice it. You are absolutely correct it's a my mistake. I updated the draft with following text: RFC 5988 [RFC5988] defined the way of indicating resources on the Web. This specification defines a link relation type which may be used to express the relationships between a collection and an input form for adding additional member items to the context collection, or between an item and a pre-populated input form for modifying the context item. http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-01.txt > > > > > > Below is the simple example use case: > > > > ==Request== > > > > | GET /users HTTP/1.1 > > | Host: service.org (http://service.org) > > | Accept: application/vnd.collection.next+json > > > > ==Response== > > > > | HTTP/1.1 200 Ok > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"collection": { > > | "version": "1.0", > > | "href": "http://service.org/users", > > | "items": [ > > | { > > | "href" : "http://service.org/users/john-doe", > > | "data" : [ > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > | {"name": "website", "value": "", "Prompt": "Website"} > > | ], > > | "links" : [ > > | { > > | "href": "http://service.org/users/john-doe/form", > > | "rel": "form", > > > > > How do I know the meaning of 'form' here? Will this add a new entry? Well, in this case link is included within an item which is a member of a collection as defined per spec. It clearly should mean *modify* not *add*. Ioseb > > > > Jan > > > > | "type": "application/vnd.collection.next+json" > > | "prompt": "Edit user" > > | } > > | ] > > | }, > > | {...}, > > | {...}, > > | {...} > > | ] > > | }} > > > > > > ==Request: dereference the form resource== > > > > | GET /users/john-doe/form HTTP/1.1 > > | Host: service.org (http://service.org) > > | Accept: application/vnd.collection.next+json > > > > ==Response== > > > > | HTTP/1.1 200 Ok > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"collection": { > > | "version": "1.0", > > | > > | "template": { > > | "method": { > > | "options": [ > > | {"value": "PUT", "prompt": "Replace Entry"}, > > | {"value": "PATCH", "prompt": "Modify Entry"} > > | ] > > | }, > > | "data": [ > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > | ] > > | } > > | }} > > > > ==Request: submit the modified form element== > > > > | PATCH /users/john-doe HTTP/1.1 > > | Host: service.org (http://service.org) > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"template": { > > | "data": [ > > | {"name": "website", "value": "http://john.doe.com"} > > | ] > > | }} > > > > Best regards, > > Ioseb > > > > ---------- Forwarded message ---------- > > From: Jan Algermissen > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > Cc: > > Date: Mon, 7 May 2012 20:26:39 +0200 > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > Hi Ioseb, > > > > I have just looked at your draft[1] and have a couple of questions: > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > ..... > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > Jan > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > -- > > Ioseb Dzmanashvili > > Lead Architect > > Picktek LLC > > 24b Khazbegi ave. > > Tbilisi, 0177, Georgia > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > picktek.com (http://picktek.com) > > code.ge > > github.com/ioseb (http://github.com/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > --4facb519_5f94dc03_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan,
=20

On =46riday, May 11, 2= 012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

= On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so far I can only see= one ('form'). Which is the other one you are going to define=3F

I'm not sure regarding this, i never mentio= ned another link relation type. I only created draft for form=3F

Your draft says: =22This specificati= on defines a pair of reciprocal link relation types=22 - I took 'pair' to= mean 'two' , no=3F

<= div>
Thanks for pointing this, i didn't notice it. You are absol= utely correct it's a my mistake.  I updated the draft with following= text:

R=46C 5988 =5BR=46C5988=5D define=
d the way of indicating resources on the
   Web. This specification defines a link relation type which may be
   used to express the relationships between a collection and an input
   form for adding additional member items to the context collection, or
   between an item and a pre-populated input form for modifying the
   context item.

 
=

<= br>
Below is the simple example use case:

<= div>=3D=3DRequest=3D=3D

=7C GET /users HTTP/1.1<= /div>
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 O= k
=7C Content-Type: application/vnd.collection.next+json
<= div>=7C Content-Length: ...

=7C =7B=22collection= =22: =7B
=7C =22version=22: =221.0=22,
=7C =22hre= f=22: =22http://service.org/user= s=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C =22dat= a=22 : =5B
=7C =7B=22name=22: =22name=22, =22value=22= : =22John Doe=22, =22prompt=22: =22=46ull name=22=7D,
=7C = =7B=22name=22: =22email=22, =22value=22: =22john=40doe.com=22, =22prompt=22: =22Email=22=7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22=22, = =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22links=22 : =5B
=7C =7B
=7C = =22href=22: =22http://service.org/users/john-doe/form=22,
=7C = =22rel=22: =22form=22,

How do I know the meaning of 'form' here=3F Will this add a new entry=3F=
Well, in this case link is inc= luded within an item which is a member of a collection as defined per spe= c. It clearly should mean *modify* not *add*.

Io= seb




Jan
=


=7C= =22type=22: =22application/vnd.collection.next+json=22
=
=7C =22prompt=22: =22Edit user=22
=7C =7D=
=7C =5D
=7C =7D,
=7C =7B...=7D= ,
=7C =7B...=7D,
=7C =7B...=7D
=7C = =5D
=7C =7D=7D


=3D=3D= Request: dereference the form resource=3D=3D

=7C= GET /users/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.co= llection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: applicat= ion/vnd.collection.next+json
=7C Content-Length: ...
=
=7C =7B=22collection=22: =7B
=7C =22version=22= : =221.0=22,
=7C
=7C =22template=22: =7B
= =7C =22method=22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22PUT=22, =22prompt=22: =22Replace Entry= =22=7D,
=7C =7B=22value=22: =22PATCH=22, =22prompt=22: = =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22: =22first= =5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst name=22, =22= required=22: true=7D,
=7C =7B=22name=22: =22last=5Fname=22= , =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required=22= : true=7D,
=7C =7B=22name=22: =22website=22, =22value=22= : =22=22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D=
=7C =5D
=7C =7D
=7C =7D=7D
=
=3D=3DRequest: submit the modified form element=3D=3D

=7C PATCH /users/john-doe HTTP/1.1
=7C Hos= t: service.org
=7C Conte= nt-Type: application/vnd.collection.next+json
=7C Content-Lengt= h: ...

=7C =7B=22template=22: =7B
=7C = =22data=22: =5B
=7C =7B=22name=22: =22website=22, =22valu= e=22: =22http://john.doe.com=22=7D=
=7C =5D
=7C =7D=7D

Best r= egards,
Ioseb

---------- =46= orwarded message ----------
=46rom: Jan Algermissen <jan.algermissen=40nordsc.com= >
Cc:
Date: Mon, 7 May 20= 12 20:26:39 +0200
Subject: =5Blink-relations=5D Review of draft= -ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draft=5B1=5D and have a couple of que= stions:

You mention two link relations, but so f= ar I can only see one ('form'). Which is the other one you are going to d= efine=3F

What is the exact purpose of the 'form'= link relation=3F A=46AIU the client would do a GET on the link target an= d interpret the response body as a form for adding entries.
Can you explain a bit, what the use cases are you have in min= d for this=3F Does it make sense to define such a relation in a general m= anner=3F Why=3F Do you envision the specification of certain media types = for the forms to be returned=3F

Then you mention= the use of 'form' to edit single member entries. I find this to be probl= ematic because the meaning of the returned form (that is, the effect of s= ubmitting the form, depends on the context in which the form has been fou= nd. In one case it will be 'add a member' in the other it will be 'update= a resource'.

Have you considered using media ty= pe semantics instead of link relations=3F It would in my opinion be bette= r to define a form media type and make the distinction between add and ed= it part of the type, not of the context in which a link is found.

.....

Have you looked at Mark = Baker's RD=46 =46orms=5B2=5D=3F Maybe you can build on that approach for = your purpose=3F

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing lis= t


--
Ioseb Dzman= ashvili
Lead Architect
Picktek LLC
24b Khaz= begi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.5= 6, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20 =20

--4facb519_5f94dc03_1745-- From ioseb.dzmanashvili@gmail.com Fri May 11 01:39:52 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D69C21F8643 for ; Fri, 11 May 2012 01:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHGmedruL6W2 for ; Fri, 11 May 2012 01:39:51 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E162D21F8636 for ; Fri, 11 May 2012 01:39:50 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1705516wgb.13 for ; Fri, 11 May 2012 01:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=PCFtQkxe5PcNrtcfk8yu0ACkHC71fZeQwkn2osU0jew=; b=T2GANL9EKISuTKJoIJBF9GaLTh3ciJr1Kv6wR4O32I6JXtDpnXEh3KiT46ZBAxpj+f zGghKQG60DfYLoekmCTDKs9nv2Wkx2YuZ8hypfjwciyZtpTz/yGBSCvIc/5Y0Fq5Qnvb qHE9iTqQCzDOGAFTjCIIWoDzxc9ExC5BmlLSNX2l/UkKd6DN+s1rek6qKuzxtgAjLMdZ k7LqQhJTdasW1iMdbto4ZT7I100pLlEqqSKIuj4sXOfxza9C6c5WYDZ4hKwQ4R5XUkzh Ca4CJXewFjx/TQfd/bJm6O8IJnBhXYV0Lin6Q5Wk85ZrLcHQQD4S7mW5afthUfOwPFQc jj7Q== Received: by 10.180.80.35 with SMTP id o3mr2995703wix.7.1336725589839; Fri, 11 May 2012 01:39:49 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id bn9sm9122011wib.5.2012.05.11.01.39.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 01:39:48 -0700 (PDT) Date: Fri, 11 May 2012 12:57:26 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4facd476_78070222_1745" Cc: link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:39:52 -0000 --4facd476_78070222_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jan, I was thinking about your question regarding understanding of meaning of *form*. I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: == For collection == | { | "links": [ | { | "href": "http://...", | "rel": "collection form", | "prompt": "Add new entry..." | } | ] | } == For item == | { | "links": [ | { | "href": "http://...", | "rel": "item form", | "prompt": "Edit entry..." | } | ] | } Again, i'm not 100% sure, though i believe it's much clear. P.S. Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 Best regards, Ioseb On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > Ioseb, > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > Hello Jan, > > > > Thanks for the questions! > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > Below is the simple example use case: > > > > ==Request== > > > > | GET /users HTTP/1.1 > > | Host: service.org (http://service.org) > > | Accept: application/vnd.collection.next+json > > > > ==Response== > > > > | HTTP/1.1 200 Ok > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"collection": { > > | "version": "1.0", > > | "href": "http://service.org/users", > > | "items": [ > > | { > > | "href" : "http://service.org/users/john-doe", > > | "data" : [ > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > | {"name": "website", "value": "", "Prompt": "Website"} > > | ], > > | "links" : [ > > | { > > | "href": "http://service.org/users/john-doe/form", > > | "rel": "form", > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > Jan > > > > | "type": "application/vnd.collection.next+json" > > | "prompt": "Edit user" > > | } > > | ] > > | }, > > | {...}, > > | {...}, > > | {...} > > | ] > > | }} > > > > > > ==Request: dereference the form resource== > > > > | GET /users/john-doe/form HTTP/1.1 > > | Host: service.org (http://service.org) > > | Accept: application/vnd.collection.next+json > > > > ==Response== > > > > | HTTP/1.1 200 Ok > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"collection": { > > | "version": "1.0", > > | > > | "template": { > > | "method": { > > | "options": [ > > | {"value": "PUT", "prompt": "Replace Entry"}, > > | {"value": "PATCH", "prompt": "Modify Entry"} > > | ] > > | }, > > | "data": [ > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > | ] > > | } > > | }} > > > > ==Request: submit the modified form element== > > > > | PATCH /users/john-doe HTTP/1.1 > > | Host: service.org (http://service.org) > > | Content-Type: application/vnd.collection.next+json > > | Content-Length: ... > > > > | {"template": { > > | "data": [ > > | {"name": "website", "value": "http://john.doe.com"} > > | ] > > | }} > > > > Best regards, > > Ioseb > > > > ---------- Forwarded message ---------- > > From: Jan Algermissen > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > Cc: > > Date: Mon, 7 May 2012 20:26:39 +0200 > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > Hi Ioseb, > > > > I have just looked at your draft[1] and have a couple of questions: > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > ..... > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > Jan > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > -- > > Ioseb Dzmanashvili > > Lead Architect > > Picktek LLC > > 24b Khazbegi ave. > > Tbilisi, 0177, Georgia > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > picktek.com (http://picktek.com) > > code.ge > > github.com/ioseb (http://github.com/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > --4facd476_78070222_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Jan,

I was thinking ab= out your question regarding understanding of meaning of *form*. I'm not 1= 00% sure, though as far as it's possible to specify multiple link types a= s a value of the *rel* attribute and there are already registered link re= lations of *collection* and *item* types as per R=46C6573 <http://tool= s.ietf.org/html/rfc6573>, in order to signify meaning of the *form* li= nk type in resource representations it's possible to define links this wa= y:

=3D=3D =46or collection =3D=3D
=7C = =7B
=7C   =22links=22: =5B
=7C     =7B=
=7C       =22href=22: =22http://...=22,
=7C       =22rel=22: =22collection form=22,
=7C=       =22prompt=22: =22Add new entry...=22
=7C =     =7D
=7C   =5D
=7C =7D
=3D=3D =46or item =3D=3D
=7C =7B
=7C &nb= sp; =22links=22: =5B
=7C     =7B
=7C  =     =22href=22: =22http://...=22,
=7C     =   =22rel=22: =22item form=22,
=7C       =22= prompt=22: =22Edit entry...=22
=7C     =7D
= =7C   =5D
=7C =7D

Again, i'm not = 100% sure, though i believe it's much clear.

P.S= .
Most recent version of draft: http://tools.ietf.org/html/draf= t-ioseb-dzmanashvili-link-relation-02

Best regar= ds,
Ioseb
=20

On =46riday, May 11, 2= 012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

= On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so far I can only see= one ('form'). Which is the other one you are going to define=3F

I'm not sure regarding this, i never mentio= ned another link relation type. I only created draft for form=3F

Your draft says: =22This specificati= on defines a pair of reciprocal link relation types=22 - I took 'pair' to= mean 'two' , no=3F


Below is the simple example use case:
=3D=3DRequest=3D=3D

=7C GET /users = HTTP/1.1
=7C Host: service.o= rg
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/= 1.1 200 Ok
=7C Content-Type: application/vnd.collection.next+js= on
=7C Content-Length: ...

=7C =7B=22c= ollection=22: =7B
=7C =22version=22: =221.0=22,
=7C= =22href=22: =22http://service= .org/users=22,
=7C =22items=22: =5B
=7C =7B=
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C = =22data=22 : =5B
=7C =7B=22name=22: =22name=22, =22= value=22: =22John Doe=22, =22prompt=22: =22=46ull name=22=7D,
=7C =7B=22name=22: =22email=22, =22value=22: =22john=40doe.com=22, =22prompt=22: =22Email=22= =7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22= =22, =22Prompt=22: =22Website=22=7D
=7C =5D,<= /div>
=7C =22links=22 : =5B
=7C =7B
=7C =22href=22: =22http://service.org/users/john-doe/form=22,
=7C= =22rel=22: =22form=22,

How do I know the meaning of 'form' here=3F Will this add a new e= ntry=3F



Jan
<= div>

=7C = =22type=22: =22application/vnd.collection.next+json=22
<= div>=7C =22prompt=22: =22Edit user=22
=7C =7D=
=7C =5D
=7C =7D,
=7C =7B...=7D= ,
=7C =7B...=7D,
=7C =7B...=7D
=7C = =5D
=7C =7D=7D


=3D=3D= Request: dereference the form resource=3D=3D

=7C= GET /users/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.co= llection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: applicat= ion/vnd.collection.next+json
=7C Content-Length: ...
=
=7C =7B=22collection=22: =7B
=7C =22version=22= : =221.0=22,
=7C
=7C =22template=22: =7B
= =7C =22method=22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22PUT=22, =22prompt=22: =22Replace Entry= =22=7D,
=7C =7B=22value=22: =22PATCH=22, =22prompt=22: = =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22: =22first= =5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst name=22, =22= required=22: true=7D,
=7C =7B=22name=22: =22last=5Fname=22= , =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required=22= : true=7D,
=7C =7B=22name=22: =22website=22, =22value=22= : =22=22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D=
=7C =5D
=7C =7D
=7C =7D=7D
=
=3D=3DRequest: submit the modified form element=3D=3D

=7C PATCH /users/john-doe HTTP/1.1
=7C Hos= t: service.org
=7C Conte= nt-Type: application/vnd.collection.next+json
=7C Content-Lengt= h: ...

=7C =7B=22template=22: =7B
=7C = =22data=22: =5B
=7C =7B=22name=22: =22website=22, =22valu= e=22: =22http://john.doe.com=22=7D=
=7C =5D
=7C =7D=7D

Best r= egards,
Ioseb

---------- =46= orwarded message ----------
=46rom: Jan Algermissen <jan.algermissen=40nordsc.com= >
Cc:
Date: Mon, 7 May 20= 12 20:26:39 +0200
Subject: =5Blink-relations=5D Review of draft= -ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draft=5B1=5D and have a couple of que= stions:

You mention two link relations, but so f= ar I can only see one ('form'). Which is the other one you are going to d= efine=3F

What is the exact purpose of the 'form'= link relation=3F A=46AIU the client would do a GET on the link target an= d interpret the response body as a form for adding entries.
Can you explain a bit, what the use cases are you have in min= d for this=3F Does it make sense to define such a relation in a general m= anner=3F Why=3F Do you envision the specification of certain media types = for the forms to be returned=3F

Then you mention= the use of 'form' to edit single member entries. I find this to be probl= ematic because the meaning of the returned form (that is, the effect of s= ubmitting the form, depends on the context in which the form has been fou= nd. In one case it will be 'add a member' in the other it will be 'update= a resource'.

Have you considered using media ty= pe semantics instead of link relations=3F It would in my opinion be bette= r to define a form media type and make the distinction between add and ed= it part of the type, not of the context in which a link is found.

.....

Have you looked at Mark = Baker's RD=46 =46orms=5B2=5D=3F Maybe you can build on that approach for = your purpose=3F

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing lis= t


--
Ioseb Dzman= ashvili
Lead Architect
Picktek LLC
24b Khaz= begi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.5= 6, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20 =20

--4facd476_78070222_1745-- From jan.algermissen@nordsc.com Fri May 11 02:06:37 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5121F865D for ; Fri, 11 May 2012 02:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxiwqyVb8U6S for ; Fri, 11 May 2012 02:06:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id B541A21F864E for ; Fri, 11 May 2012 02:06:35 -0700 (PDT) Received: from [10.90.131.199] ([87.253.171.218]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MhamE-1SpEMt3Cwk-00M0Rw; Fri, 11 May 2012 11:06:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Fri, 11 May 2012 11:06:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:GV0AR51b1cm/WKTEqDSTZ2ml7kK55bWvZ0j1ofTD0Ae XjFPAUQbQ5z2hrimReAGcDslkKQsFRBONh+zVH9Zrkx6rr7o3p +eBB5BZBA/sY1KHpJhVOfxwoAwUETqMQNE4DpYoZf39dLUtbYI Fa4ckepiIyD3O9+UNL2JE4l5SkT5FN2PnTxD6BDb7xeyX1HXrg 8O/Q+pHD7rmnRPCuUj33vC6Ycx1Ga8MoeNGHp/lcT1iV7B8exS XanJYh0pS2HXlJzi6iyvuabAROjjw8DKrGWDLpl9laNjYOx3t8 KAWYb2Muq/US0YJyu4/5pYcEuBdVlmHOSBlIVzbDCQNSFHUCLW Bvc0texdRdSkHtHPQMXyfxv6b+FxnZ19mmkDmvm228Gm++uQ2L YbHcbAgY1DeCQ== Cc: link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 09:06:37 -0000 On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > Jan, >=20 > I was thinking about your question regarding understanding of meaning = of *form*. What is troubling me is that the meaning of 'form' depends on the = meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec = depends on some other spec that defines what 'collection' and 'item' = means.=20 This in turn means that a client must understand the other specs (the = media type of the context of the 'form' link) to understand which = meaning of form is in effect. I'd rather define two new relations, or, make the form apply to both = cases equally and let the client figure out the submission target URI. = (Who says the form must contain the target?) That way 'form' would mean: 'here is a form that you can use to = construct entry-submissions'. If you intend to edit an entry, use the = form and if you intend to create a new entry use that form too. Send the form to the appropriate target URI. E.g. GET /feed 200 Ok, Link: ; rel=3Dform .... Then GET /feed/entry-form 200 Ok Content-Type: application/myform
Then use the form to construct the payload for the request - to create a new entry and POST to /collection or - to update an entry and PUT to e.g. /entries/665 makes sense? Jan > I'm not 100% sure, though as far as it's possible to specify multiple = link types as a value of the *rel* attribute and there are already = registered link relations of *collection* and *item* types as per = RFC6573 , in order to signify = meaning of the *form* link type in resource representations it's = possible to define links this way: >=20 > =3D=3D For collection =3D=3D > | { > | "links": [ > | { > | "href": "http://...", > | "rel": "collection form", > | "prompt": "Add new entry..." > | } > | ] > | } >=20 > =3D=3D For item =3D=3D > | { > | "links": [ > | { > | "href": "http://...", > | "rel": "item form", > | "prompt": "Edit entry..." > | } > | ] > | } >=20 > Again, i'm not 100% sure, though i believe it's much clear. >=20 > P.S. > Most recent version of draft: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 >=20 > Best regards, > Ioseb > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: >=20 >> Ioseb, >>=20 >> On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: >>=20 >>> Hello Jan, >>>=20 >>> Thanks for the questions! >>>=20 >>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>=20 >>> I'm not sure regarding this, i never mentioned another link relation = type. I only created draft for form? >>=20 >> Your draft says: "This specification defines a pair of reciprocal = link relation types" - I took 'pair' to mean 'two' , no? >>=20 >>>=20 >>> Below is the simple example use case: >>>=20 >>> =3D=3DRequest=3D=3D >>>=20 >>> | GET /users HTTP/1.1 >>> | Host: service.org >>> | Accept: application/vnd.collection.next+json >>>=20 >>> =3D=3DResponse=3D=3D >>>=20 >>> | HTTP/1.1 200 Ok >>> | Content-Type: application/vnd.collection.next+json >>> | Content-Length: ... >>>=20 >>> | {"collection": { >>> | "version": "1.0", >>> | "href": "http://service.org/users", >>> | "items": [ >>> | { >>> | "href" : "http://service.org/users/john-doe", >>> | "data" : [ >>> | {"name": "name", "value": "John Doe", "prompt": "Full name"}, >>> | {"name": "email", "value": "john@doe.com", "prompt": "Email"}, >>> | {"name": "website", "value": "", "Prompt": "Website"} >>> | ], >>> | "links" : [ >>> | { >>> | "href": "http://service.org/users/john-doe/form", >>> | "rel": "form", >>=20 >> How do I know the meaning of 'form' here? Will this add a new entry? >>=20 >>=20 >>=20 >> Jan >>=20 >>=20 >>> | "type": "application/vnd.collection.next+json" >>> | "prompt": "Edit user" >>> | } >>> | ] >>> | }, >>> | {...}, >>> | {...}, >>> | {...} >>> | ] >>> | }} >>>=20 >>>=20 >>> =3D=3DRequest: dereference the form resource=3D=3D >>>=20 >>> | GET /users/john-doe/form HTTP/1.1 >>> | Host: service.org >>> | Accept: application/vnd.collection.next+json >>>=20 >>> =3D=3DResponse=3D=3D >>>=20 >>> | HTTP/1.1 200 Ok >>> | Content-Type: application/vnd.collection.next+json >>> | Content-Length: ... >>>=20 >>> | {"collection": { >>> | "version": "1.0", >>> | >>> | "template": { >>> | "method": { >>> | "options": [ >>> | {"value": "PUT", "prompt": "Replace Entry"}, >>> | {"value": "PATCH", "prompt": "Modify Entry"} >>> | ] >>> | }, >>> | "data": [ >>> | {"name": "first_name", "value": "John", "prompt": "First name", = "required": true}, >>> | {"name": "last_name", "value": "Doe", "prompt": "Last name", = "required": true}, >>> | {"name": "website", "value": "", "prompt": "Website", "type": = "url"} >>> | ] >>> | } >>> | }} >>>=20 >>> =3D=3DRequest: submit the modified form element=3D=3D >>>=20 >>> | PATCH /users/john-doe HTTP/1.1 >>> | Host: service.org >>> | Content-Type: application/vnd.collection.next+json >>> | Content-Length: ... >>>=20 >>> | {"template": { >>> | "data": [ >>> | {"name": "website", "value": "http://john.doe.com"} >>> | ] >>> | }} >>>=20 >>> Best regards, >>> Ioseb >>>=20 >>> ---------- Forwarded message ---------- >>> From: Jan Algermissen >>> To: link-relations@ietf.org >>> Cc: >>> Date: Mon, 7 May 2012 20:26:39 +0200 >>> Subject: [link-relations] Review of = draft-ioseb-dzmanashvili-link-relation-00 >>> Hi Ioseb, >>>=20 >>> I have just looked at your draft[1] and have a couple of questions: >>>=20 >>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>=20 >>> What is the exact purpose of the 'form' link relation? AFAIU the = client would do a GET on the link target and interpret the response body = as a form for adding entries. >>>=20 >>> Can you explain a bit, what the use cases are you have in mind for = this? Does it make sense to define such a relation in a general manner? = Why? Do you envision the specification of certain media types for the = forms to be returned? >>>=20 >>> Then you mention the use of 'form' to edit single member entries. I = find this to be problematic because the meaning of the returned form = (that is, the effect of submitting the form, depends on the context in = which the form has been found. In one case it will be 'add a member' in = the other it will be 'update a resource'. >>>=20 >>> Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found. >>>=20 >>> ..... >>>=20 >>> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on = that approach for your purpose? >>>=20 >>> Jan >>>=20 >>>=20 >>> [1] = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt >>> [2] http://www.markbaker.ca/2003/05/RDF-Forms/ >>>=20 >>> _______________________________________________ >>> link-relations mailing list >>> link-relations@ietf.org >>> https://www.ietf.org/mailman/listinfo/link-relations >>>=20 >>>=20 >>> -- >>> Ioseb Dzmanashvili >>> Lead Architect >>> Picktek LLC >>> 24b Khazbegi ave. >>> Tbilisi, 0177, Georgia >>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>> picktek.com >>> code.ge >>> github.com/ioseb >>> twitter.com/iosebi >=20 From ioseb.dzmanashvili@gmail.com Fri May 11 04:34:15 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEF021F862F for ; Fri, 11 May 2012 04:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57dpXCjU4T8r for ; Fri, 11 May 2012 04:34:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9D21F8463 for ; Fri, 11 May 2012 04:34:12 -0700 (PDT) Received: by werf13 with SMTP id f13so1274822wer.31 for ; Fri, 11 May 2012 04:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=jz1tkfYh1k1CphA8zfasBHfOsjC8wVITP1Tvri2JeFI=; b=VmQbfad3W22+pYrfoGcouT+wRn6hVsNFuleuQOV94/r6o0QW5FyEF715WmmA8o/qkh dOyqJ/UdbKg7HnCXdRjTa+4/hlRuoPWAshJhBq25uOPVc04nGaYbbX5ux9vKUPmhSZsj RY+faGtMHaOREqcc8YWXBGtVL6Y9ANAM0NQuEMzJW4k/vSp79Ri15n+hsVn1YxvJ1ybt CkTwMqxknIiLDqrO3LFigEIwkhwNL9LMS4953JK6yO+muefAo3SIhurgaS3HAkTnc8yn +qCP9g0bP+liM69ZBx/wGWC9eYn067ITczvWlEnmiRkMi1Zxwen+5HPGrz50bI+rvH0j DdnA== Received: by 10.180.95.4 with SMTP id dg4mr6936111wib.2.1336736051751; Fri, 11 May 2012 04:34:11 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id ez4sm9972468wid.3.2012.05.11.04.34.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 04:34:11 -0700 (PDT) Date: Fri, 11 May 2012 15:51:48 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <060632DA3A334DE1A9FAD8E935D09933@gmail.com> In-Reply-To: <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4facfd54_102809e2_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 11:34:15 -0000 --4facfd54_102809e2_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks Jan! > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec > that defines what 'collection' and 'item' means. > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. That's why I was not 100% sure when suggested this approach. I absolutely agree with you. >I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) If i understand you correctly, this means that there can be only one form for creating or updating entry. If this is the case, how it solves the problem when create and update forms differ from each other? or when intent is to offer already pre-populated form? In this case defining these relations separately will work better i believe. I think re-defining the *form* as a generic type with meaning like "here is the form and use it for to construct submissions" and additional type *update-form* with meaning like "here is the entry/record/item and the related *pre-populated* form, use it to modify the entry and construct submission". In other words what i'm trying to achieve is to have the ability to manage both - create and update forms separately and coordinate client interactions. == Retrieve feed == | GET /feed HTTP/1.1 | Host: service.com == Response == | HTTP/1.1 200 OK | Link: ; rel=form; title=Create new entry | | | ... | | | | Does it make sense? Best regards, Ioseb On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > Jan, > > > > I was thinking about your question regarding understanding of meaning of *form*. > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > Send the form to the appropriate target URI. > > E.g. > > GET /feed > > 200 Ok, > Link: ; rel=form > > > > > > .... > > > > Then > > GET /feed/entry-form > > 200 Ok > Content-Type: application/myform > >
>
> > > Then use the form to construct the payload for the request > > - to create a new entry and POST to /collection > or > - to update an entry and PUT to e.g. /entries/665 > > makes sense? > > Jan > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > == For collection == > > | { > > | "links": [ > > | { > > | "href": "http://...", > > | "rel": "collection form", > > | "prompt": "Add new entry..." > > | } > > | ] > > | } > > > > == For item == > > | { > > | "links": [ > > | { > > | "href": "http://...", > > | "rel": "item form", > > | "prompt": "Edit entry..." > > | } > > | ] > > | } > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > P.S. > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > Best regards, > > Ioseb > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > Ioseb, > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > Hello Jan, > > > > > > > > Thanks for the questions! > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > Below is the simple example use case: > > > > > > > > ==Request== > > > > > > > > | GET /users HTTP/1.1 > > > > | Host: service.org (http://service.org) > > > > | Accept: application/vnd.collection.next+json > > > > > > > > ==Response== > > > > > > > > | HTTP/1.1 200 Ok > > > > | Content-Type: application/vnd.collection.next+json > > > > | Content-Length: ... > > > > > > > > | {"collection": { > > > > | "version": "1.0", > > > > | "href": "http://service.org/users", > > > > | "items": [ > > > > | { > > > > | "href" : "http://service.org/users/john-doe", > > > > | "data" : [ > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > | ], > > > > | "links" : [ > > > > | { > > > > | "href": "http://service.org/users/john-doe/form", > > > > | "rel": "form", > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > Jan > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > | "prompt": "Edit user" > > > > | } > > > > | ] > > > > | }, > > > > | {...}, > > > > | {...}, > > > > | {...} > > > > | ] > > > > | }} > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > | Host: service.org (http://service.org) > > > > | Accept: application/vnd.collection.next+json > > > > > > > > ==Response== > > > > > > > > | HTTP/1.1 200 Ok > > > > | Content-Type: application/vnd.collection.next+json > > > > | Content-Length: ... > > > > > > > > | {"collection": { > > > > | "version": "1.0", > > > > | > > > > | "template": { > > > > | "method": { > > > > | "options": [ > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > | ] > > > > | }, > > > > | "data": [ > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > | ] > > > > | } > > > > | }} > > > > > > > > ==Request: submit the modified form element== > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > | Host: service.org (http://service.org) > > > > | Content-Type: application/vnd.collection.next+json > > > > | Content-Length: ... > > > > > > > > | {"template": { > > > > | "data": [ > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > | ] > > > > | }} > > > > > > > > Best regards, > > > > Ioseb > > > > > > > > ---------- Forwarded message ---------- > > > > From: Jan Algermissen > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > Cc: > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > Hi Ioseb, > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > ..... > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > Jan > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > _______________________________________________ > > > > link-relations mailing list > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > -- > > > > Ioseb Dzmanashvili > > > > Lead Architect > > > > Picktek LLC > > > > 24b Khazbegi ave. > > > > Tbilisi, 0177, Georgia > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > picktek.com (http://picktek.com) > > > > code.ge > > > > github.com/ioseb (http://github.com/ioseb) > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > --4facfd54_102809e2_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks Jan=21

> Wha= t is troubling me is that the meaning of 'form' depends on the meaning of= 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on so= me other spec 
> that defines what 'collection' and 'it= em' means.
> This in turn means that a client must understan= d the other specs (the media type of the context of the 'form' link) to u= nderstand which meaning of form is in effect.

Th= at's why I was not 100% sure when suggested this approach. I absolutely a= gree with you.

>I'd rather define two new rel= ations, or, make the form apply to both cases equally and let the client = figure out the submission target URI. (Who says the form must contain the= target=3F)

If i understand you correctly, this = means that there can be only one form for creating or updating entry. If = this is the case, how it solves the problem when create and update forms = differ from each other=3F or when intent is to offer already pre-populate= d form=3F In this case defining these relations separately will work bett= er i believe. 

I think re-defining the *for= m* as a generic type with meaning like =22here is the form and use it for= to construct submissions=22 and additional type *update-form* with meani= ng like =22here is the entry/record/item and the related *pre-populated* = form, use it to modify the entry and construct submission=22. In other wo= rds what i'm trying to achieve is to have the ability to manage both - cr= eate and update forms separately and coordinate client interactions.

=3D=3D Retrieve feed =3D=3D
=7C GET /feed = HTTP/1.1
=7C Host: service.com

=3D=3D = Response =3D=3D
=7C HTTP/1.1 200 OK
=7C Link: </fe= ed/form>; rel=3Dform; title=3DCreate new entry

=7C <feed>
=7C   <entry>
=7C  = ;   ...
=7C     <link rel=3D=22self=22 href=3D= =22/entries/665=22 />
=7C     <link rel=3D=22up= date-form=22 href=3D=22/entries/665/form=22 title=3D=22Update entry=22 /&= gt;
=7C   </entry>
=7C </feed>
=

Does it make sense=3F

Best r= egards,
Ioseb

=20

On =46riday, May 11, 2= 012 at 1:06 PM, Jan Algermissen wrote:


On May 11, 2012, = at 10:57 AM, Ioseb Dzmanashvili wrote:

Jan,

I was thinking ab= out your question regarding understanding of meaning of *form*.

What is troubling me is that the meani= ng of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Eff= ectively the 'form' spec depends on some other spec that defines what 'co= llection' and 'item' means.

This in turn means = that a client must understand the other specs (the media type of the cont= ext of the 'form' link) to understand which meaning of form is in effect.=

I'd rather define two new relations, or, make t= he form apply to both cases equally and let the client figure out the sub= mission target URI. (Who says the form must contain the target=3F)
<= div>
That way 'form' would mean: 'here is a form that you c= an use to construct entry-submissions'. If you intend to edit an entry, u= se the form and if you intend to create a new entry use that form too.

Send the form to the appropriate target URI.
=

E.g.

GET /feed
200 Ok,
Link: </feed/entry-form>; rel=3Dform<= /div>

<feed>
<entry>
<link rel=3D=22edit=22 href=3D=22/entries/665=22/>
= </entry>
....
</feed>


Then

GET /feed/entry-for= m

200 Ok
Content-Type: application/myf= orm

<form>
</form>


Then use the form to construct the paylo= ad for the request

- to create a new entry and P= OST to /collection
or
- to update an entry and PUT to= e.g. /entries/665

makes sense=3F

=
Jan



I'm not 100% sure, though = as far as it's possible to specify multiple link types as a value of the = *rel* attribute and there are already registered link relations of *colle= ction* and *item* types as per R=46C6573 <http://tools.ietf.org/html/rfc6573>, in ord= er to signify meaning of the *form* link type in resource representations= it's possible to define links this way:

=3D=3D = =46or collection =3D=3D
=7C =7B
=7C =22links=22: =5B=
=7C =7B
=7C =22href=22: =22http://...=22,<= /div>
=7C =22rel=22: =22collection form=22,
=7C = =22prompt=22: =22Add new entry...=22
=7C =7D
=7C= =5D
=7C =7D

=3D=3D =46or item =3D=3D=
=7C =7B
=7C =22links=22: =5B
=7C =7B=
=7C =22href=22: =22http://...=22,
=7C =22= rel=22: =22item form=22,
=7C =22prompt=22: =22Edit entry.= ..=22
=7C =7D
=7C =5D
=7C =7D

Again, i'm not 100% sure, though i believe it's much cl= ear.

P.S.

Best regards,
Ioseb
On =46riday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote:
<= div>
Ioseb,
On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:
=

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so far I = can only see one ('form'). Which is the other one you are going to define= =3F

I'm not sure regarding this, i = never mentioned another link relation type. I only created draft for form= =3F

Your draft says: =22This = specification defines a pair of reciprocal link relation types=22 - I too= k 'pair' to mean 'two' , no=3F


Below is the simple example use case:

=3D=3DRequest=3D=3D

=7C G= ET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+js= on

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd.collecti= on.next+json
=7C Content-Length: ...

=7C= =7B=22collection=22: =7B
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://ser= vice.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C =22data=22 = : =5B
=7C =7B=22name=22: =22name=22, =22value=22: =22John Doe=22= , =22prompt=22: =22=46ull name=22=7D,
=7C =7B=22name=22: =22ema= il=22, =22value=22: =22john=40doe.c= om=22, =22prompt=22: =22Email=22=7D,
=7C =7B=22name=22: =22= website=22, =22value=22: =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22links=22 : =5B
=7C =7B
=7C =22rel=22: =22= form=22,

How do I know the me= aning of 'form' here=3F Will this add a new entry=3F

=


Jan


=7C =22type=22: =22application/v= nd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C =5D
=7C =7D,
=7C =7B...= =7D,
=7C =7B...=7D,
=7C =7B...=7D
=7C =5D
=7C =7D=7D


=3D=3DRequest= : dereference the form resource=3D=3D

=7C GET /u= sers/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collectio= n.next+json

=3D=3DResponse=3D=3D

<= /div>
=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd= .collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22: =7B
=7C =22version=22: =221.0=22= ,
=7C
=7C =22template=22: =7B
=7C =22method= =22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22= PUT=22, =22prompt=22: =22Replace Entry=22=7D,
=7C =7B=22value=22= : =22PATCH=22, =22prompt=22: =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22:= =22first=5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst na= me=22, =22required=22: true=7D,
=7C =7B=22name=22: =22last=5Fna= me=22, =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required= =22: true=7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22= =22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D
=7C = =5D
=7C =7D
=7C =7D=7D

=3D=3D= Request: submit the modified form element=3D=3D

= =7C PATCH /users/john-doe HTTP/1.1
=7C Host: service.org
=7C Content-Type: application/= vnd.collection.next+json
=7C Content-Length: ...

=
=7C =7B=22template=22: =7B
=7C =22data=22: =5B
=
=7C =7B=22name=22: =22website=22, =22value=22: =22http://john.doe.com=22=7D
=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- =46orwarded message ----------
= =46rom: Jan Algermissen <jan.algermissen=40nordsc.com>
Cc:
Date: Mon, 7 May 2012 20:26:39 +0200
Subject: =5B= link-relations=5D Review of draft-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draf= t=5B1=5D and have a couple of questions:

You men= tion two link relations, but so far I can only see one ('form'). Which is= the other one you are going to define=3F

What i= s the exact purpose of the 'form' link relation=3F A=46AIU the client wou= ld do a GET on the link target and interpret the response body as a form = for adding entries.

Can you explain a bit, what = the use cases are you have in mind for this=3F Does it make sense to defi= ne such a relation in a general manner=3F Why=3F Do you envision the spec= ification of certain media types for the forms to be returned=3F

Then you mention the use of 'form' to edit single member= entries. I find this to be problematic because the meaning of the return= ed form (that is, the effect of submitting the form, depends on the conte= xt in which the form has been found. In one case it will be 'add a member= ' in the other it will be 'update a resource'.

H= ave you considered using media type semantics instead of link relations=3F= It would in my opinion be better to define a form media type and make th= e distinction between add and edit part of the type, not of the context i= n which a link is found.

.....

Have you looked at Mark Baker's RD=46 =46orms=5B2=5D=3F Maybe you= can build on that approach for your purpose=3F

= Jan


=5B2=5D h= ttp://www.markbaker.ca/2003/05/RD=46-=46orms/

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list


--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia=
T (+995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20 =20

--4facfd54_102809e2_1745-- From jan.algermissen@nordsc.com Fri May 11 04:58:06 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDF521F8569 for ; Fri, 11 May 2012 04:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXsAU+XOfDk3 for ; Fri, 11 May 2012 04:58:05 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBEE21F8469 for ; Fri, 11 May 2012 04:58:05 -0700 (PDT) Received: from [10.90.131.199] ([87.253.171.218]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MPGl6-1SXCCh0NqS-004tSE; Fri, 11 May 2012 13:58:03 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <060632DA3A334DE1A9FAD8E935D09933@gmail.com> Date: Fri, 11 May 2012 13:58:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:KNeApyuPinaG+VmvxU0o2ZAuFiJjPogUc7b+kOEts/i ONRqlyRyJfpySO1keLJaaztZpcLbMdo9hSdhFV36QOL+1oVbkQ RydnZv04xGVUsH9b4SlPuBtXrqZ8R46UqcmscnfWpfHUp19+i5 I+21Zs81NVqAr+wHwllew3rNlxooh9VaJ91gitOSPmVicf4Yne mbJ2vDzT0Wht3j7sLUlwTNJS8uA+i1TuO+dixELutDfmLzIfRb HRo/RkmFZGqeAHQ/guno3PdJpOBFDMlGwzhSCuzcBLdg2mBJ9U WFpsSajdnhKvq1BxNKgJ5WJOF5vYMSYQxFRJuUFT+zYSS8HejO USQK123+KpGRyiFASYwSR09W0DHVELhJ+vMukFZ1e2RY7QRrSb K2MGuvRauiepA== Cc: "julian.reschke@gmx.de" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 11:58:06 -0000 On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: >=20 > If i understand you correctly, this means that there can be only one = form for creating or updating entry. If this is the case, how it solves = the problem when create and update forms differ from each other? or when = intent is to offer already pre-populated form? Ah, sure - you are right. Missed that. > In this case defining these relations separately will work better i = believe. Yes - that would also not be a harm, IMHO. >=20 > I think re-defining the *form* as a generic type with meaning like = "here is the form and use it for to construct submissions" and = additional type *update-form* with meaning like "here is the = entry/record/item and the related *pre-populated* form, use it to modify = the entry and construct submission". In other words what i'm trying to = achieve is to have the ability to manage both - create and update forms = separately and coordinate client interactions. >=20 > =3D=3D Retrieve feed =3D=3D > | GET /feed HTTP/1.1 > | Host: service.com >=20 > =3D=3D Response =3D=3D > | HTTP/1.1 200 OK > | Link: ; rel=3Dform; title=3DCreate new entry >=20 > | > | > | ... > | > | > | > | >=20 > Does it make sense? Yes, feels better. I'll let it circle through my head whether there is = something else to it. BTW, what would the reaction be if I POST to create without form and the = server does not 'allow' that? Should this maybe be mentioned in the spec as a hint? Any = better/additional idea? POST /feed Content-Type: application/order 415 Unsupported Media Type Link: ; rel=3Dform; title=3DCreate new entry Content-Type: text/html .... Use this = form to create a new entry. Jan >=20 > Best regards, > Ioseb >=20 > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: >=20 >>=20 >> On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: >>=20 >>> Jan, >>>=20 >>> I was thinking about your question regarding understanding of = meaning of *form*. >>=20 >> What is troubling me is that the meaning of 'form' depends on the = meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec = depends on some other spec that defines what 'collection' and 'item' = means. >>=20 >> This in turn means that a client must understand the other specs (the = media type of the context of the 'form' link) to understand which = meaning of form is in effect. >>=20 >> I'd rather define two new relations, or, make the form apply to both = cases equally and let the client figure out the submission target URI. = (Who says the form must contain the target?) >>=20 >> That way 'form' would mean: 'here is a form that you can use to = construct entry-submissions'. If you intend to edit an entry, use the = form and if you intend to create a new entry use that form too. >>=20 >> Send the form to the appropriate target URI. >>=20 >> E.g. >>=20 >> GET /feed >>=20 >> 200 Ok, >> Link: ; rel=3Dform >>=20 >> >> >> >> >> .... >> >>=20 >>=20 >> Then >>=20 >> GET /feed/entry-form >>=20 >> 200 Ok >> Content-Type: application/myform >>=20 >>
>>
>>=20 >>=20 >> Then use the form to construct the payload for the request >>=20 >> - to create a new entry and POST to /collection >> or >> - to update an entry and PUT to e.g. /entries/665 >>=20 >> makes sense? >>=20 >> Jan >>=20 >>=20 >>=20 >>=20 >>> I'm not 100% sure, though as far as it's possible to specify = multiple link types as a value of the *rel* attribute and there are = already registered link relations of *collection* and *item* types as = per RFC6573 , in order to signify = meaning of the *form* link type in resource representations it's = possible to define links this way: >>>=20 >>> =3D=3D For collection =3D=3D >>> | { >>> | "links": [ >>> | { >>> | "href": "http://...", >>> | "rel": "collection form", >>> | "prompt": "Add new entry..." >>> | } >>> | ] >>> | } >>>=20 >>> =3D=3D For item =3D=3D >>> | { >>> | "links": [ >>> | { >>> | "href": "http://...", >>> | "rel": "item form", >>> | "prompt": "Edit entry..." >>> | } >>> | ] >>> | } >>>=20 >>> Again, i'm not 100% sure, though i believe it's much clear. >>>=20 >>> P.S. >>> Most recent version of draft: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 >>>=20 >>> Best regards, >>> Ioseb >>> On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: >>>=20 >>>> Ioseb, >>>>=20 >>>> On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: >>>>=20 >>>>> Hello Jan, >>>>>=20 >>>>> Thanks for the questions! >>>>>=20 >>>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>=20 >>>>> I'm not sure regarding this, i never mentioned another link = relation type. I only created draft for form? >>>>=20 >>>> Your draft says: "This specification defines a pair of reciprocal = link relation types" - I took 'pair' to mean 'two' , no? >>>>=20 >>>>>=20 >>>>> Below is the simple example use case: >>>>>=20 >>>>> =3D=3DRequest=3D=3D >>>>>=20 >>>>> | GET /users HTTP/1.1 >>>>> | Host: service.org >>>>> | Accept: application/vnd.collection.next+json >>>>>=20 >>>>> =3D=3DResponse=3D=3D >>>>>=20 >>>>> | HTTP/1.1 200 Ok >>>>> | Content-Type: application/vnd.collection.next+json >>>>> | Content-Length: ... >>>>>=20 >>>>> | {"collection": { >>>>> | "version": "1.0", >>>>> | "href": "http://service.org/users", >>>>> | "items": [ >>>>> | { >>>>> | "href" : "http://service.org/users/john-doe", >>>>> | "data" : [ >>>>> | {"name": "name", "value": "John Doe", "prompt": "Full name"}, >>>>> | {"name": "email", "value": "john@doe.com", "prompt": "Email"}, >>>>> | {"name": "website", "value": "", "Prompt": "Website"} >>>>> | ], >>>>> | "links" : [ >>>>> | { >>>>> | "href": "http://service.org/users/john-doe/form", >>>>> | "rel": "form", >>>>=20 >>>> How do I know the meaning of 'form' here? Will this add a new = entry? >>>>=20 >>>>=20 >>>>=20 >>>> Jan >>>>=20 >>>>=20 >>>>> | "type": "application/vnd.collection.next+json" >>>>> | "prompt": "Edit user" >>>>> | } >>>>> | ] >>>>> | }, >>>>> | {...}, >>>>> | {...}, >>>>> | {...} >>>>> | ] >>>>> | }} >>>>>=20 >>>>>=20 >>>>> =3D=3DRequest: dereference the form resource=3D=3D >>>>>=20 >>>>> | GET /users/john-doe/form HTTP/1.1 >>>>> | Host: service.org >>>>> | Accept: application/vnd.collection.next+json >>>>>=20 >>>>> =3D=3DResponse=3D=3D >>>>>=20 >>>>> | HTTP/1.1 200 Ok >>>>> | Content-Type: application/vnd.collection.next+json >>>>> | Content-Length: ... >>>>>=20 >>>>> | {"collection": { >>>>> | "version": "1.0", >>>>> | >>>>> | "template": { >>>>> | "method": { >>>>> | "options": [ >>>>> | {"value": "PUT", "prompt": "Replace Entry"}, >>>>> | {"value": "PATCH", "prompt": "Modify Entry"} >>>>> | ] >>>>> | }, >>>>> | "data": [ >>>>> | {"name": "first_name", "value": "John", "prompt": "First name", = "required": true}, >>>>> | {"name": "last_name", "value": "Doe", "prompt": "Last name", = "required": true}, >>>>> | {"name": "website", "value": "", "prompt": "Website", "type": = "url"} >>>>> | ] >>>>> | } >>>>> | }} >>>>>=20 >>>>> =3D=3DRequest: submit the modified form element=3D=3D >>>>>=20 >>>>> | PATCH /users/john-doe HTTP/1.1 >>>>> | Host: service.org >>>>> | Content-Type: application/vnd.collection.next+json >>>>> | Content-Length: ... >>>>>=20 >>>>> | {"template": { >>>>> | "data": [ >>>>> | {"name": "website", "value": "http://john.doe.com"} >>>>> | ] >>>>> | }} >>>>>=20 >>>>> Best regards, >>>>> Ioseb >>>>>=20 >>>>> ---------- Forwarded message ---------- >>>>> From: Jan Algermissen >>>>> To: link-relations@ietf.org >>>>> Cc: >>>>> Date: Mon, 7 May 2012 20:26:39 +0200 >>>>> Subject: [link-relations] Review of = draft-ioseb-dzmanashvili-link-relation-00 >>>>> Hi Ioseb, >>>>>=20 >>>>> I have just looked at your draft[1] and have a couple of = questions: >>>>>=20 >>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>=20 >>>>> What is the exact purpose of the 'form' link relation? AFAIU the = client would do a GET on the link target and interpret the response body = as a form for adding entries. >>>>>=20 >>>>> Can you explain a bit, what the use cases are you have in mind for = this? Does it make sense to define such a relation in a general manner? = Why? Do you envision the specification of certain media types for the = forms to be returned? >>>>>=20 >>>>> Then you mention the use of 'form' to edit single member entries. = I find this to be problematic because the meaning of the returned form = (that is, the effect of submitting the form, depends on the context in = which the form has been found. In one case it will be 'add a member' in = the other it will be 'update a resource'. >>>>>=20 >>>>> Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found. >>>>>=20 >>>>> ..... >>>>>=20 >>>>> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build = on that approach for your purpose? >>>>>=20 >>>>> Jan >>>>>=20 >>>>>=20 >>>>> [1] = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt >>>>> [2] http://www.markbaker.ca/2003/05/RDF-Forms/ >>>>>=20 >>>>> _______________________________________________ >>>>> link-relations mailing list >>>>> link-relations@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/link-relations >>>>>=20 >>>>>=20 >>>>> -- >>>>> Ioseb Dzmanashvili >>>>> Lead Architect >>>>> Picktek LLC >>>>> 24b Khazbegi ave. >>>>> Tbilisi, 0177, Georgia >>>>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>>>> picktek.com >>>>> code.ge >>>>> github.com/ioseb >>>>> twitter.com/iosebi >=20 From jan.algermissen@nordsc.com Fri May 11 05:11:54 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B66C21F8624 for ; Fri, 11 May 2012 05:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ4PZFK2P7vo for ; Fri, 11 May 2012 05:11:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9921F8621 for ; Fri, 11 May 2012 05:11:52 -0700 (PDT) Received: from [10.90.131.199] ([87.253.171.218]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MNN9N-1SUliB3ilV-006hvv; Fri, 11 May 2012 14:11:51 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Fri, 11 May 2012 14:11:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> To: Jan Algermissen X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:/dGi3XA9mqrOIKCZBKiVZb3i/8iPmJSrb9tpoJ+ZpYg WueZJvch4x+Pi4A08iY5sUHcXjSKQEHA7CpEk5LxqJ5Qh68VzR cEbrwxKGaEznjfMECUxKrhrSSxs42MB8sT3M+UUbHFwOek6343 t7G5RSHqycJiYP0e8wBe55WF3VMDaJWJBZPEALosyNTzDy/3jB t3GfsgFtfhzry0hpIm26V6MJooqmAY1s8iwJGtBsksn/ckTUGr CvkUB6+ndy9gGT/znqDs8morqyX6XxVOqt9Jp0PcPfBe0KdMTT k0T9C5KA/RDNMT8SNDeQyh4FVZkEe++4QVqoPZ03l8zNpKUlL/ pCIowBKULgssDzTm6z6OdJTfsNM4Tc70l4T09n6D06q8PWldTI pjmAyzUTTWUFg== Cc: "julian.reschke@gmx.de" , link-relations@ietf.org, Ioseb Dzmanashvili Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 12:11:54 -0000 On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: >=20 > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: >=20 >>=20 >>=20 >> =3D=3D Response =3D=3D >> | HTTP/1.1 200 OK >> | Link: ; rel=3Dform; title=3DCreate new entry >>=20 >> | >> | >> | ... >> | >> | >> | >> | >>=20 Interesting thing is that a human targeted user agent could treat the = form-links like HTML links and download the forms right away, = embedding them in the UI directly (maybe hidden of course). A bit like a = 'typed' AJAX request. Cool stuff, actually. Jan >> Does it make sense? >=20 > Yes, feels better. I'll let it circle through my head whether there is = something else to it. >=20 > BTW, what would the reaction be if I POST to create without form and = the server does not 'allow' that? >=20 > Should this maybe be mentioned in the spec as a hint? Any = better/additional idea? >=20 > POST /feed > Content-Type: application/order >=20 > >=20 > 415 Unsupported Media Type > Link: ; rel=3Dform; title=3DCreate new entry > Content-Type: text/html >=20 > > .... Use this = form to create a new entry. > >=20 >=20 > Jan >=20 >=20 >=20 >>=20 >> Best regards, >> Ioseb >>=20 >> On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: >>=20 >>>=20 >>> On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: >>>=20 >>>> Jan, >>>>=20 >>>> I was thinking about your question regarding understanding of = meaning of *form*. >>>=20 >>> What is troubling me is that the meaning of 'form' depends on the = meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec = depends on some other spec that defines what 'collection' and 'item' = means. >>>=20 >>> This in turn means that a client must understand the other specs = (the media type of the context of the 'form' link) to understand which = meaning of form is in effect. >>>=20 >>> I'd rather define two new relations, or, make the form apply to both = cases equally and let the client figure out the submission target URI. = (Who says the form must contain the target?) >>>=20 >>> That way 'form' would mean: 'here is a form that you can use to = construct entry-submissions'. If you intend to edit an entry, use the = form and if you intend to create a new entry use that form too. >>>=20 >>> Send the form to the appropriate target URI. >>>=20 >>> E.g. >>>=20 >>> GET /feed >>>=20 >>> 200 Ok, >>> Link: ; rel=3Dform >>>=20 >>> >>> >>> >>> >>> .... >>> >>>=20 >>>=20 >>> Then >>>=20 >>> GET /feed/entry-form >>>=20 >>> 200 Ok >>> Content-Type: application/myform >>>=20 >>>
>>>
>>>=20 >>>=20 >>> Then use the form to construct the payload for the request >>>=20 >>> - to create a new entry and POST to /collection >>> or >>> - to update an entry and PUT to e.g. /entries/665 >>>=20 >>> makes sense? >>>=20 >>> Jan >>>=20 >>>=20 >>>=20 >>>=20 >>>> I'm not 100% sure, though as far as it's possible to specify = multiple link types as a value of the *rel* attribute and there are = already registered link relations of *collection* and *item* types as = per RFC6573 , in order to signify = meaning of the *form* link type in resource representations it's = possible to define links this way: >>>>=20 >>>> =3D=3D For collection =3D=3D >>>> | { >>>> | "links": [ >>>> | { >>>> | "href": "http://...", >>>> | "rel": "collection form", >>>> | "prompt": "Add new entry..." >>>> | } >>>> | ] >>>> | } >>>>=20 >>>> =3D=3D For item =3D=3D >>>> | { >>>> | "links": [ >>>> | { >>>> | "href": "http://...", >>>> | "rel": "item form", >>>> | "prompt": "Edit entry..." >>>> | } >>>> | ] >>>> | } >>>>=20 >>>> Again, i'm not 100% sure, though i believe it's much clear. >>>>=20 >>>> P.S. >>>> Most recent version of draft: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 >>>>=20 >>>> Best regards, >>>> Ioseb >>>> On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: >>>>=20 >>>>> Ioseb, >>>>>=20 >>>>> On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: >>>>>=20 >>>>>> Hello Jan, >>>>>>=20 >>>>>> Thanks for the questions! >>>>>>=20 >>>>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>>=20 >>>>>> I'm not sure regarding this, i never mentioned another link = relation type. I only created draft for form? >>>>>=20 >>>>> Your draft says: "This specification defines a pair of reciprocal = link relation types" - I took 'pair' to mean 'two' , no? >>>>>=20 >>>>>>=20 >>>>>> Below is the simple example use case: >>>>>>=20 >>>>>> =3D=3DRequest=3D=3D >>>>>>=20 >>>>>> | GET /users HTTP/1.1 >>>>>> | Host: service.org >>>>>> | Accept: application/vnd.collection.next+json >>>>>>=20 >>>>>> =3D=3DResponse=3D=3D >>>>>>=20 >>>>>> | HTTP/1.1 200 Ok >>>>>> | Content-Type: application/vnd.collection.next+json >>>>>> | Content-Length: ... >>>>>>=20 >>>>>> | {"collection": { >>>>>> | "version": "1.0", >>>>>> | "href": "http://service.org/users", >>>>>> | "items": [ >>>>>> | { >>>>>> | "href" : "http://service.org/users/john-doe", >>>>>> | "data" : [ >>>>>> | {"name": "name", "value": "John Doe", "prompt": "Full name"}, >>>>>> | {"name": "email", "value": "john@doe.com", "prompt": "Email"}, >>>>>> | {"name": "website", "value": "", "Prompt": "Website"} >>>>>> | ], >>>>>> | "links" : [ >>>>>> | { >>>>>> | "href": "http://service.org/users/john-doe/form", >>>>>> | "rel": "form", >>>>>=20 >>>>> How do I know the meaning of 'form' here? Will this add a new = entry? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Jan >>>>>=20 >>>>>=20 >>>>>> | "type": "application/vnd.collection.next+json" >>>>>> | "prompt": "Edit user" >>>>>> | } >>>>>> | ] >>>>>> | }, >>>>>> | {...}, >>>>>> | {...}, >>>>>> | {...} >>>>>> | ] >>>>>> | }} >>>>>>=20 >>>>>>=20 >>>>>> =3D=3DRequest: dereference the form resource=3D=3D >>>>>>=20 >>>>>> | GET /users/john-doe/form HTTP/1.1 >>>>>> | Host: service.org >>>>>> | Accept: application/vnd.collection.next+json >>>>>>=20 >>>>>> =3D=3DResponse=3D=3D >>>>>>=20 >>>>>> | HTTP/1.1 200 Ok >>>>>> | Content-Type: application/vnd.collection.next+json >>>>>> | Content-Length: ... >>>>>>=20 >>>>>> | {"collection": { >>>>>> | "version": "1.0", >>>>>> | >>>>>> | "template": { >>>>>> | "method": { >>>>>> | "options": [ >>>>>> | {"value": "PUT", "prompt": "Replace Entry"}, >>>>>> | {"value": "PATCH", "prompt": "Modify Entry"} >>>>>> | ] >>>>>> | }, >>>>>> | "data": [ >>>>>> | {"name": "first_name", "value": "John", "prompt": "First name", = "required": true}, >>>>>> | {"name": "last_name", "value": "Doe", "prompt": "Last name", = "required": true}, >>>>>> | {"name": "website", "value": "", "prompt": "Website", "type": = "url"} >>>>>> | ] >>>>>> | } >>>>>> | }} >>>>>>=20 >>>>>> =3D=3DRequest: submit the modified form element=3D=3D >>>>>>=20 >>>>>> | PATCH /users/john-doe HTTP/1.1 >>>>>> | Host: service.org >>>>>> | Content-Type: application/vnd.collection.next+json >>>>>> | Content-Length: ... >>>>>>=20 >>>>>> | {"template": { >>>>>> | "data": [ >>>>>> | {"name": "website", "value": "http://john.doe.com"} >>>>>> | ] >>>>>> | }} >>>>>>=20 >>>>>> Best regards, >>>>>> Ioseb >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> From: Jan Algermissen >>>>>> To: link-relations@ietf.org >>>>>> Cc: >>>>>> Date: Mon, 7 May 2012 20:26:39 +0200 >>>>>> Subject: [link-relations] Review of = draft-ioseb-dzmanashvili-link-relation-00 >>>>>> Hi Ioseb, >>>>>>=20 >>>>>> I have just looked at your draft[1] and have a couple of = questions: >>>>>>=20 >>>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>>=20 >>>>>> What is the exact purpose of the 'form' link relation? AFAIU the = client would do a GET on the link target and interpret the response body = as a form for adding entries. >>>>>>=20 >>>>>> Can you explain a bit, what the use cases are you have in mind = for this? Does it make sense to define such a relation in a general = manner? Why? Do you envision the specification of certain media types = for the forms to be returned? >>>>>>=20 >>>>>> Then you mention the use of 'form' to edit single member entries. = I find this to be problematic because the meaning of the returned form = (that is, the effect of submitting the form, depends on the context in = which the form has been found. In one case it will be 'add a member' in = the other it will be 'update a resource'. >>>>>>=20 >>>>>> Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found. >>>>>>=20 >>>>>> ..... >>>>>>=20 >>>>>> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build = on that approach for your purpose? >>>>>>=20 >>>>>> Jan >>>>>>=20 >>>>>>=20 >>>>>> [1] = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt >>>>>> [2] http://www.markbaker.ca/2003/05/RDF-Forms/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> link-relations mailing list >>>>>> link-relations@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/link-relations >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Ioseb Dzmanashvili >>>>>> Lead Architect >>>>>> Picktek LLC >>>>>> 24b Khazbegi ave. >>>>>> Tbilisi, 0177, Georgia >>>>>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>>>>> picktek.com >>>>>> code.ge >>>>>> github.com/ioseb >>>>>> twitter.com/iosebi >>=20 >=20 > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From ioseb.dzmanashvili@gmail.com Fri May 11 05:12:25 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70721F846F for ; Fri, 11 May 2012 05:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n8kMNzcYGm9 for ; Fri, 11 May 2012 05:12:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E733821F8469 for ; Fri, 11 May 2012 05:12:22 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1820982wgb.13 for ; Fri, 11 May 2012 05:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=nwMOHwsAqt8+tm7I4It8XMCqh834yN+AoJk7EMA/d2s=; b=Fl1sKcOIBAAwLrl989IEZN7lYBxQRmbT20tEyeonNJUfFn1F8Bjl+rmDQszfNojZgz +WA7nCkBAV15OBzdV/opqlrpPsfXIzY+kHSR5J6OJGuotzHtBrMX6zkcbgFpOErwQ3qp NZl01a1L4EhYUxQm/AODaxFOXC3QXAF/QB5TEfSmStfcg2CIG/KTKYEpLKISbAPIfaIJ /DiE5jHEchzFVPaepPvwghpr3wUmwi4lDFh19ZO0qwYEVC/7csm9f0nqFNd+o+nzI9fQ p0Of0juw2dBXU5w7GEQBGEEmpQCAmyM9RZ2qYohayBAcnO6x93dNIGZWW5EDp8wHPYpo 5d5Q== Received: by 10.216.30.213 with SMTP id k63mr1384420wea.59.1336738341940; Fri, 11 May 2012 05:12:21 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id ex2sm16530404wib.8.2012.05.11.05.12.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 05:12:21 -0700 (PDT) Date: Fri, 11 May 2012 16:30:00 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad0648_3c5e07c_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 12:12:25 -0000 --4fad0648_3c5e07c_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jan, > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? For me this sounds fantastic, i believe it's absolutely makes sense to include this in spec(i can't think about anything better for this). Thanks for this! P.S. I'll start to work on redefining the spec and will share descriptions here before updating the document. Thanks for great discussion! Ioseb On Friday, May 11, 2012 at 3:58 PM, Jan Algermissen wrote: > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > If i understand you correctly, this means that there can be only one form for creating or updating entry. If this is the case, how it solves the problem when create and update forms differ from each other? or when intent is to offer already pre-populated form? > > Ah, sure - you are right. Missed that. > > > In this case defining these relations separately will work better i believe. > > Yes - that would also not be a harm, IMHO. > > > > > I think re-defining the *form* as a generic type with meaning like "here is the form and use it for to construct submissions" and additional type *update-form* with meaning like "here is the entry/record/item and the related *pre-populated* form, use it to modify the entry and construct submission". In other words what i'm trying to achieve is to have the ability to manage both - create and update forms separately and coordinate client interactions. > > > > == Retrieve feed == > > | GET /feed HTTP/1.1 > > | Host: service.com (http://service.com) > > > > == Response == > > | HTTP/1.1 200 OK > > | Link: ; rel=form; title=Create new entry > > > > | > > | > > | ... > > | > > | > > | > > | > > > > Does it make sense? > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > POST /feed > Content-Type: application/order > > > > 415 Unsupported Media Type > Link: ; rel=form; title=Create new entry > Content-Type: text/html > > > .... Use this form to create a new entry. > > > > Jan > > > > > > > Best regards, > > Ioseb > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > Jan, > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > Send the form to the appropriate target URI. > > > > > > E.g. > > > > > > GET /feed > > > > > > 200 Ok, > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > Then > > > > > > GET /feed/entry-form > > > > > > 200 Ok > > > Content-Type: application/myform > > > > > >
> > >
> > > > > > > > > Then use the form to construct the payload for the request > > > > > > - to create a new entry and POST to /collection > > > or > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > makes sense? > > > > > > Jan > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > == For collection == > > > > | { > > > > | "links": [ > > > > | { > > > > | "href": "http://...", > > > > | "rel": "collection form", > > > > | "prompt": "Add new entry..." > > > > | } > > > > | ] > > > > | } > > > > > > > > == For item == > > > > | { > > > > | "links": [ > > > > | { > > > > | "href": "http://...", > > > > | "rel": "item form", > > > > | "prompt": "Edit entry..." > > > > | } > > > > | ] > > > > | } > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > P.S. > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > Best regards, > > > > Ioseb > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > Ioseb, > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > ==Request== > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > | Host: service.org (http://service.org) > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > ==Response== > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > | Content-Length: ... > > > > > > > > > > > > | {"collection": { > > > > > > | "version": "1.0", > > > > > > | "href": "http://service.org/users", > > > > > > | "items": [ > > > > > > | { > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > | "data" : [ > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > | ], > > > > > > | "links" : [ > > > > > > | { > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > | "prompt": "Edit user" > > > > > > | } > > > > > > | ] > > > > > > | }, > > > > > > | {...}, > > > > > > | {...}, > > > > > > | {...} > > > > > > | ] > > > > > > | }} > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > | Host: service.org (http://service.org) > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > ==Response== > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > | Content-Length: ... > > > > > > > > > > > > | {"collection": { > > > > > > | "version": "1.0", > > > > > > | > > > > > > | "template": { > > > > > > | "method": { > > > > > > | "options": [ > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > | ] > > > > > > | }, > > > > > > | "data": [ > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > | ] > > > > > > | } > > > > > > | }} > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > | Host: service.org (http://service.org) > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > | Content-Length: ... > > > > > > > > > > > > | {"template": { > > > > > > | "data": [ > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > | ] > > > > > > | }} > > > > > > > > > > > > Best regards, > > > > > > Ioseb > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > From: Jan Algermissen > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > Cc: > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > Hi Ioseb, > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > ..... > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > _______________________________________________ > > > > > > link-relations mailing list > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > -- > > > > > > Ioseb Dzmanashvili > > > > > > Lead Architect > > > > > > Picktek LLC > > > > > > 24b Khazbegi ave. > > > > > > Tbilisi, 0177, Georgia > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > picktek.com (http://picktek.com) > > > > > > code.ge > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --4fad0648_3c5e07c_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Jan, 

> BTW, w= hat would the reaction be if I POST to create without form and the server= does not 'allow' that=3F
> Should this maybe be mentioned i= n the spec as a hint=3F Any better/additional idea=3F
=46or me this sounds fantastic, i believe it's absolutely mak= es sense to include this in spec(i can't think about anything better for = this). Thanks for this=21

P.S.
I'll st= art to work on redefining the spec and will share descriptions here befor= e updating the document. Thanks for great discussion=21

Ioseb
=20

On =46riday, May 11, 2= 012 at 3:58 PM, Jan Algermissen wrote:


On May 11, 2012, = at 1:51 PM, Ioseb Dzmanashvili wrote:


If i understand you correctly, th= is means that there can be only one form for creating or updating entry. = If this is the case, how it solves the problem when create and update for= ms differ from each other=3F or when intent is to offer already pre-popul= ated form=3F

Ah, sure - you a= re right. Missed that.

=
In this case defining these relations separately will work better i = believe.

Yes - that would also not = be a harm, IMHO.

<= div>
I think re-defining the *form* as a generic type with = meaning like =22here is the form and use it for to construct submissions=22= and additional type *update-form* with meaning like =22here is the entry= /record/item and the related *pre-populated* form, use it to modify the e= ntry and construct submission=22. In other words what i'm trying to achie= ve is to have the ability to manage both - create and update forms separa= tely and coordinate client interactions.

=3D=3D = Retrieve feed =3D=3D
=7C GET /feed HTTP/1.1
=7C Host:= service.com

<= div>=3D=3D Response =3D=3D
=7C HTTP/1.1 200 OK
=7C Li= nk: </feed/form>; rel=3Dform; title=3DCreate new entry
=7C <feed>
=7C <entry>
=7C= ...
=7C <link rel=3D=22self=22 href=3D=22/entries/6= 65=22 />
=7C <link rel=3D=22update-form=22 href=3D=22= /entries/665/form=22 title=3D=22Update entry=22 />
=7C <= ;/entry>
=7C </feed>

Does it = make sense=3F

Yes, feels bett= er. I'll let it circle through my head whether there is something else to= it.

BTW, what would the reaction be if I POST t= o create without form and the server does not 'allow' that=3F
<= br>
Should this maybe be mentioned in the spec as a hint=3F Any= better/additional idea=3F

POST /feed
= Content-Type: application/order

<order/>

415 Unsupported Media Type
Link: </f= eed/form>; rel=3Dform; title=3DCreate new entry
Content-Type= : text/html

<html>
.... Use <= a href=3D=22/feed/form=22 title=3D=22Entry Creation =46orm=22>this for= m</a> to create a new entry.
</html>

=

Jan



Best regard= s,
Ioseb

On =46riday, May 11, 2012 at = 1:06 PM, Jan Algermissen wrote:


On May 11, 2012, at 10:57 AM, Ioseb Dzma= nashvili wrote:

Jan,

I was thinking about your question regar= ding understanding of meaning of *form*.
What is troubling me is that the meaning of 'form' depends on= the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spe= c depends on some other spec that defines what 'collection' and 'item' me= ans.

This in turn means that a client must under= stand the other specs (the media type of the context of the 'form' link) = to understand which meaning of form is in effect.

I'd rather define two new relations, or, make the form apply to both ca= ses equally and let the client figure out the submission target URI. (Who= says the form must contain the target=3F)

That = way 'form' would mean: 'here is a form that you can use to construct entr= y-submissions'. If you intend to edit an entry, use the form and if you i= ntend to create a new entry use that form too.

S= end the form to the appropriate target URI.

E.g.=

GET /feed

200 Ok,
Link: </feed/entry-form>; rel=3Dform

<feed>
<entry>
<link rel=3D=22edit=22= href=3D=22/entries/665=22/>
</entry>
....
</feed>


Then
=

GET /feed/entry-form

200 Ok<= /div>
Content-Type: application/myform

<f= orm>
</form>


T= hen use the form to construct the payload for the request

<= /div>
- to create a new entry and POST to /collection
or
- to update an entry and PUT to e.g. /entries/665

<= /div>
makes sense=3F

Jan




I'm not 100% sure, though as far as it's possible to specify m= ultiple link types as a value of the *rel* attribute and there are alread= y registered link relations of *collection* and *item* types as per R=46C= 6573 <http://tools.= ietf.org/html/rfc6573>, in order to signify meaning of the *form* = link type in resource representations it's possible to define links this = way:

=3D=3D =46or collection =3D=3D
=7C= =7B
=7C =22links=22: =5B
=7C =7B
=7C =22hr= ef=22: =22http://...=22,
=7C =22rel=22: =22collection form=22,<= /div>
=7C =22prompt=22: =22Add new entry...=22
=7C =7D
=7C =5D
=7C =7D

=3D=3D =46or ite= m =3D=3D
=7C =7B
=7C =22links=22: =5B
=7C =7B=
=7C =22href=22: =22http://...=22,
=7C =22rel=22: =22= item form=22,
=7C =22prompt=22: =22Edit entry...=22
=7C= =7D
=7C =5D
=7C =7D

Again, = i'm not 100% sure, though i believe it's much clear.

=
P.S.
<= br>
Best regards,
Ioseb
On =46riday, May 11= , 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 20= 12, at 10:21 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

Thanks = for the questions=21

You mention two link relations, but so far I can only see one ('form')= . Which is the other one you are going to define=3F

I'm not sure regarding this, i never mentioned another l= ink relation type. I only created draft for form=3F

Your draft says: =22This specification defines a p= air of reciprocal link relation types=22 - I took 'pair' to mean 'two' , = no=3F


Below is the simple example use case:

=3D= =3DRequest=3D=3D

=7C GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=
=7C Content-Type: application/vnd.collection.next+json
=7C= Content-Length: ...

=7C =7B=22collection=22: =7B=
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://service.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 := =22http://service.org/= users/john-doe=22,
=7C =22data=22 : =5B
=7C =7B=22= name=22: =22name=22, =22value=22: =22John Doe=22, =22prompt=22: =22=46ull= name=22=7D,
=7C =7B=22name=22: =22email=22, =22value=22: =22john=40doe.com=22, =22prompt=22: = =22Email=22=7D,
=7C =7B=22name=22: =22website=22, =22value=22: = =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22= links=22 : =5B
=7C =7B
=7C =22rel=22: =22form=22,

How do I know the meaning of 'form' here=3F Will = this add a new entry=3F



Jan


=7C =22type=22: =22application/vnd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C = =5D
=7C =7D,
=7C =7B...=7D,
=7C =7B...=7D,<= /div>
=7C =7B...=7D
=7C =5D
=7C =7D=7D
=

=3D=3DRequest: dereference the form resourc= e=3D=3D

=7C GET /users/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok<= /div>
=7C Content-Type: application/vnd.collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22= : =7B
=7C =22version=22: =221.0=22,
=7C
=7C= =22template=22: =7B
=7C =22method=22: =7B
=7C =22opt= ions=22: =5B
=7C =7B=22value=22: =22PUT=22, =22prompt=22: =22Re= place Entry=22=7D,
=7C =7B=22value=22: =22PATCH=22, =22prompt=22= : =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C= =22data=22: =5B
=7C =7B=22name=22: =22first=5Fname=22, =22valu= e=22: =22John=22, =22prompt=22: =22=46irst name=22, =22required=22: true=7D= ,
=7C =7B=22name=22: =22last=5Fname=22, =22value=22: =22Doe=22,= =22prompt=22: =22Last name=22, =22required=22: true=7D,
=7C =7B= =22name=22: =22website=22, =22value=22: =22=22, =22prompt=22: =22Website=22= , =22type=22: =22url=22=7D
=7C =5D
=7C =7D
= =7C =7D=7D

=3D=3DRequest: submit the modified fo= rm element=3D=3D

=7C PATCH /users/john-doe HTTP/= 1.1
=7C Host: service.org
<= div>=7C Content-Length: ...

=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- = =46orwarded message ----------
=46rom: Jan Algermissen <jan.algermissen=40nordsc.= com>
Cc:
Date: Mon, 7 May 2= 012 20:26:39 +0200
Subject: =5Blink-relations=5D Review of draf= t-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

<= /div>
I have just looked at your draft=5B1=5D and have a couple of qu= estions:

You mention two link relations, but so = far I can only see one ('form'). Which is the other one you are going to = define=3F

What is the exact purpose of the 'form= ' link relation=3F A=46AIU the client would do a GET on the link target a= nd interpret the response body as a form for adding entries.
Can you explain a bit, what the use cases are you have in mi= nd for this=3F Does it make sense to define such a relation in a general = manner=3F Why=3F Do you envision the specification of certain media types= for the forms to be returned=3F

Then you mentio= n the use of 'form' to edit single member entries. I find this to be prob= lematic because the meaning of the returned form (that is, the effect of = submitting the form, depends on the context in which the form has been fo= und. In one case it will be 'add a member' in the other it will be 'updat= e a resource'.

Have you considered using media t= ype semantics instead of link relations=3F It would in my opinion be bett= er to define a form media type and make the distinction between add and e= dit part of the type, not of the context in which a link is found.
<= div>
.....

Have you looked at Mark= Baker's RD=46 =46orms=5B2=5D=3F Maybe you can build on that approach for= your purpose=3F

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing lis= t


--
Ioseb Dzmana= shvili
Lead Architect
Picktek LLC
24b Khazb= egi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.56,= =46 (+1 202) 315.3934
code.ge
<= /div>
=20 =20 =20 =20 =20

--4fad0648_3c5e07c_1745-- From ioseb.dzmanashvili@gmail.com Fri May 11 05:14:21 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3014021F85D8 for ; Fri, 11 May 2012 05:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3emYpF2xjNhK for ; Fri, 11 May 2012 05:14:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1421F846F for ; Fri, 11 May 2012 05:14:18 -0700 (PDT) Received: by wibhr2 with SMTP id hr2so1330736wib.13 for ; Fri, 11 May 2012 05:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=KLcaQ0+s4eP/LeL0QBavWnt+ldPIjWh1x0hU2u4GPlQ=; b=uwVJKEyMZ8LWuLfzZNyqZnPsTrp2D5wYTVcUoJ8knQanBmASV7Y8C1xamOuuBj985T xsSSAiJ4PeEREGXESSL2YuH822GAlhPu4jJXMCcw2VqSfPmBQUTaDWAPgs0NNAQ3ritq z34hzqpDXn5NAJKLyRWJCmqjE2PVlOHWG560Y+1dwd3XsDZpu+BODWk5u/oB+OS9qUsG kjtnHYE1dHzBn91As6lnojE3RXK3tBGmEWCMboQ4kJg2HgW9JxA8Ub2qLA42RMrAN4tS gfd+LxioIEVYgEsTdxIiBI8Lp2Mz5Ubm8fDBDEc+WVd1r3HlXYLeXZbZmuOvCQB8PBPS DxlQ== Received: by 10.216.150.209 with SMTP id z59mr1393609wej.104.1336738458150; Fri, 11 May 2012 05:14:18 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id fn2sm16587679wib.0.2012.05.11.05.14.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 05:14:17 -0700 (PDT) Date: Fri, 11 May 2012 16:31:55 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <0202A28A7800405D975F120E0C93D635@gmail.com> In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad06bb_178e240d_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 12:14:21 -0000 --4fad06bb_178e240d_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI > > directly (maybe hidden of course). A bit like a 'typed' AJAX request. > Cool stuff, actually. I'm glad you like it!!! ioseb On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: > > On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: > > > > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > == Response == > > > | HTTP/1.1 200 OK > > > | Link: ; rel=form; title=Create new entry > > > > > > | > > > | > > > | ... > > > | > > > | > > > | > > > | > > > > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > Cool stuff, actually. > > Jan > > > > > > > > Does it make sense? > > > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > > > POST /feed > > Content-Type: application/order > > > > > > > > 415 Unsupported Media Type > > Link: ; rel=form; title=Create new entry > > Content-Type: text/html > > > > > > .... Use this form to create a new entry. > > > > > > > > Jan > > > > > > > > > > > > Best regards, > > > Ioseb > > > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > Jan, > > > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > > > Send the form to the appropriate target URI. > > > > > > > > E.g. > > > > > > > > GET /feed > > > > > > > > 200 Ok, > > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > Then > > > > > > > > GET /feed/entry-form > > > > > > > > 200 Ok > > > > Content-Type: application/myform > > > > > > > >
> > > >
> > > > > > > > > > > > Then use the form to construct the payload for the request > > > > > > > > - to create a new entry and POST to /collection > > > > or > > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > > > makes sense? > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > > > == For collection == > > > > > | { > > > > > | "links": [ > > > > > | { > > > > > | "href": "http://...", > > > > > | "rel": "collection form", > > > > > | "prompt": "Add new entry..." > > > > > | } > > > > > | ] > > > > > | } > > > > > > > > > > == For item == > > > > > | { > > > > > | "links": [ > > > > > | { > > > > > | "href": "http://...", > > > > > | "rel": "item form", > > > > > | "prompt": "Edit entry..." > > > > > | } > > > > > | ] > > > > > | } > > > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > > > P.S. > > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > > > Best regards, > > > > > Ioseb > > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > > > Ioseb, > > > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > > > ==Request== > > > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > > | Host: service.org (http://service.org) > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > | {"collection": { > > > > > > > | "version": "1.0", > > > > > > > | "href": "http://service.org/users", > > > > > > > | "items": [ > > > > > > > | { > > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > > | "data" : [ > > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > > | ], > > > > > > > | "links" : [ > > > > > > > | { > > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > > | "prompt": "Edit user" > > > > > > > | } > > > > > > > | ] > > > > > > > | }, > > > > > > > | {...}, > > > > > > > | {...}, > > > > > > > | {...} > > > > > > > | ] > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > > | Host: service.org (http://service.org) > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > | {"collection": { > > > > > > > | "version": "1.0", > > > > > > > | > > > > > > > | "template": { > > > > > > > | "method": { > > > > > > > | "options": [ > > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > > | ] > > > > > > > | }, > > > > > > > | "data": [ > > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > > | ] > > > > > > > | } > > > > > > > | }} > > > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > > | Host: service.org (http://service.org) > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > | {"template": { > > > > > > > | "data": [ > > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > > | ] > > > > > > > | }} > > > > > > > > > > > > > > Best regards, > > > > > > > Ioseb > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > > From: Jan Algermissen > > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > Cc: > > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > > Hi Ioseb, > > > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > > > ..... > > > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > link-relations mailing list > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ioseb Dzmanashvili > > > > > > > Lead Architect > > > > > > > Picktek LLC > > > > > > > 24b Khazbegi ave. > > > > > > > Tbilisi, 0177, Georgia > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > picktek.com (http://picktek.com) > > > > > > > code.ge > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > link-relations mailing list > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > --4fad06bb_178e240d_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
> Interesting thing is that a human targeted= user agent could treat the form-links like HTML <img> links and do= wnload the forms right away, embedding them in the UI > 
> directly (maybe hidden of course). A bit like a 'typed' AJAX reque= st.
> Cool stuff, actually.

I= 'm glad you like it=21=21=21

ioseb
=20

On =46riday, May 11, 2= 012 at 4:11 PM, Jan Algermissen wrote:


On May 11, 2012, = at 1:58 PM, Jan Algermissen wrote:


On May 11, 2012, at 1:51 PM, Ioseb Dz= manashvili wrote:

=


=3D=3D Response =3D=3D
=7C H= TTP/1.1 200 OK
=7C Link: </feed/form>; rel=3Dform; title=3D= Create new entry

=7C <feed>
=7C = <entry>
=7C ...
=7C <link rel=3D=22= self=22 href=3D=22/entries/665=22 />
=7C <link rel=3D= =22update-form=22 href=3D=22/entries/665/form=22 title=3D=22Update entry=22= />
=7C </entry>
=7C </feed>


In= teresting thing is that a human targeted user agent could treat the form-= links like HTML <img> links and download the forms right away, embe= dding them in the UI directly (maybe hidden of course). A bit like a 'typ= ed' AJAX request.

Cool stuff, actually.

Jan





Does it make sense=3F
Yes, feels better. I'll let it circle through my head whether= there is something else to it.

BTW, what would = the reaction be if I POST to create without form and the server does not = 'allow' that=3F

Should this maybe be mentioned i= n the spec as a hint=3F Any better/additional idea=3F

POST /feed
Content-Type: application/order

=
<order/>

415 Unsupported Media = Type
Link: </feed/form>; rel=3Dform; title=3DCreate new e= ntry
Content-Type: text/html

<html&= gt;
.... Use <a href=3D=22/feed/form=22 title=3D=22Entry Cre= ation =46orm=22>this form</a> to create a new entry.
&= lt;/html>


Jan




Best regards,
Ioseb

On= =46riday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote:

=

On May 11, 2= 012, at 10:57 AM, Ioseb Dzmanashvili wrote:

Jan,

I was thinki= ng about your question regarding understanding of meaning of *form*.

What is troubling me is that the = meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence= , Effectively the 'form' spec depends on some other spec that defines wha= t 'collection' and 'item' means.

This in turn me= ans that a client must understand the other specs (the media type of the = context of the 'form' link) to understand which meaning of form is in eff= ect.

I'd rather define two new relations, or, ma= ke the form apply to both cases equally and let the client figure out the= submission target URI. (Who says the form must contain the target=3F)

That way 'form' would mean: 'here is a form that y= ou can use to construct entry-submissions'. If you intend to edit an entr= y, use the form and if you intend to create a new entry use that form too= .

Send the form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Link: </feed/entry-form>; rel=3Df= orm

<feed>
<entry>
<link rel=3D=22edit=22 href=3D=22/entries/665=22/>
<= ;/entry>
....
</feed>


Then

GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form>
</form>

Then use the form to construct the payload for= the request

- to create a new entry and POST to= /collection
or
- to update an entry and PUT to e.g. = /entries/665

makes sense=3F

=
Jan




I'm not 100% sure, though as far= as it's possible to specify multiple link types as a value of the *rel* = attribute and there are already registered link relations of *collection*= and *item* types as per R=46C6573 <http://tools.ietf.org/html/rfc6573>, in order to = signify meaning of the *form* link type in resource representations it's = possible to define links this way:

=3D=3D =46or = collection =3D=3D
=7C =7B
=7C =22links=22: =5B
<= div>=7C =7B
=7C =22href=22: =22http://...=22,
=7C =22= rel=22: =22collection form=22,
=7C =22prompt=22: =22Add new ent= ry...=22
=7C =7D
=7C =5D
=7C =7D
=
=3D=3D =46or item =3D=3D
=7C =7B
=7C =22= links=22: =5B
=7C =7B
=7C =22href=22: =22http://...=22= ,
=7C =22rel=22: =22item form=22,
=7C =22prompt=22: =22= Edit entry...=22
=7C =7D
=7C =5D
=7C =7D

Again, i'm not 100% sure, though i believe it's mu= ch clear.

P.S.

Best regards,
Ioseb=
On =46riday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:<= /div>

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so f= ar I can only see one ('form'). Which is the other one you are going to d= efine=3F

I'm not sure regarding thi= s, i never mentioned another link relation type. I only created draft for= form=3F

Your draft says: =22= This specification defines a pair of reciprocal link relation types=22 - = I took 'pair' to mean 'two' , no=3F


Below is the simple example use case:=

=3D=3DRequest=3D=3D

=7C= GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+js= on

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd.collecti= on.next+json
=7C Content-Length: ...

=7C= =7B=22collection=22: =7B
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://ser= vice.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C =22data=22 = : =5B
=7C =7B=22name=22: =22name=22, =22value=22: =22John Doe=22= , =22prompt=22: =22=46ull name=22=7D,
=7C =7B=22name=22: =22ema= il=22, =22value=22: =22john=40doe.c= om=22, =22prompt=22: =22Email=22=7D,
=7C =7B=22name=22: =22= website=22, =22value=22: =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22links=22 : =5B
=7C =7B
=7C =22rel=22: =22= form=22,

How do I know the me= aning of 'form' here=3F Will this add a new entry=3F

=


Jan


=7C =22type=22: =22application/v= nd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C =5D
=7C =7D,
=7C =7B...= =7D,
=7C =7B...=7D,
=7C =7B...=7D
=7C =5D
=7C =7D=7D


=3D=3DRequest= : dereference the form resource=3D=3D

=7C GET /u= sers/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collectio= n.next+json

=3D=3DResponse=3D=3D

<= /div>
=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd= .collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22: =7B
=7C =22version=22: =221.0=22= ,
=7C
=7C =22template=22: =7B
=7C =22method= =22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22= PUT=22, =22prompt=22: =22Replace Entry=22=7D,
=7C =7B=22value=22= : =22PATCH=22, =22prompt=22: =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22:= =22first=5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst na= me=22, =22required=22: true=7D,
=7C =7B=22name=22: =22last=5Fna= me=22, =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required= =22: true=7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22= =22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D
=7C = =5D
=7C =7D
=7C =7D=7D

=3D=3D= Request: submit the modified form element=3D=3D

= =7C PATCH /users/john-doe HTTP/1.1
=7C Host: service.org
=7C Content-Type: application/= vnd.collection.next+json
=7C Content-Length: ...

=
=7C =7B=22template=22: =7B
=7C =22data=22: =5B
=
=7C =7B=22name=22: =22website=22, =22value=22: =22http://john.doe.com=22=7D
=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- =46orwarded message ----------
= =46rom: Jan Algermissen <jan.algermissen=40nordsc.com>
Cc:
Date: Mon, 7 May 2012 20:26:39 +0200
Subject: =5B= link-relations=5D Review of draft-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draf= t=5B1=5D and have a couple of questions:

You men= tion two link relations, but so far I can only see one ('form'). Which is= the other one you are going to define=3F

What i= s the exact purpose of the 'form' link relation=3F A=46AIU the client wou= ld do a GET on the link target and interpret the response body as a form = for adding entries.

Can you explain a bit, what = the use cases are you have in mind for this=3F Does it make sense to defi= ne such a relation in a general manner=3F Why=3F Do you envision the spec= ification of certain media types for the forms to be returned=3F

Then you mention the use of 'form' to edit single member= entries. I find this to be problematic because the meaning of the return= ed form (that is, the effect of submitting the form, depends on the conte= xt in which the form has been found. In one case it will be 'add a member= ' in the other it will be 'update a resource'.

H= ave you considered using media type semantics instead of link relations=3F= It would in my opinion be better to define a form media type and make th= e distinction between add and edit part of the type, not of the context i= n which a link is found.

.....

Have you looked at Mark Baker's RD=46 =46orms=5B2=5D=3F Maybe you= can build on that approach for your purpose=3F

= Jan


=5B2=5D h= ttp://www.markbaker.ca/2003/05/RD=46-=46orms/

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list


--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia=
T (+995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list
=20 =20 =20 =20 =20

--4fad06bb_178e240d_1745-- From ioseb.dzmanashvili@gmail.com Fri May 11 14:56:10 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9566D21F86B7 for ; Fri, 11 May 2012 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC-jC0LxMYS7 for ; Fri, 11 May 2012 14:56:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48F3C21F8599 for ; Fri, 11 May 2012 14:56:08 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2182322wgb.13 for ; Fri, 11 May 2012 14:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=aba2teDESV/OUgob1M+A56KVKWHl926Os9hilAIFYNk=; b=q9tbVzXOxyF4+tLI3xwbAS3GvqUaLTOPtXtsUNjmZIrCyiPY9kpk+QqCAKBZwtm5jk I8xienLro2JH0KSktuEECgLF9GeW3I6uS6SlH+DUCY6rlowhihKJEkhSWlKw/N73tAAv FAXheZ/4rc1118nNCD9mImpO/ghzizSuKpBtVbyMNyC+z+4Qh4vu58+ZJawLXyUinSDU ZR21h+1Bk19yLGBtF/VhwRHzHY8Na8Lro73stEE6tSkg1CvaWomBsj0RN2CGQYCvpGbL ncS2LzDzjHrNSKhHxS3W2Sxy1SCmDtQwrYz6e/jjHXDcigejAMJOwp/Mt6DxBahmbJeQ +TYQ== Received: by 10.180.78.233 with SMTP id e9mr11589613wix.5.1336773367176; Fri, 11 May 2012 14:56:07 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id f19sm21704273wiw.11.2012.05.11.14.56.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 14:56:06 -0700 (PDT) Date: Sat, 12 May 2012 02:13:46 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: <0202A28A7800405D975F120E0C93D635@gmail.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad8f1a_62fb8680_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:56:10 -0000 --4fad8f1a_62fb8680_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Jan, I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now i think. Best regards, Ioseb On Friday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote: > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI > > > directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > Cool stuff, actually. > > > I'm glad you like it!!! > > ioseb > > On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: > > > > > On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: > > > > > > > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > == Response == > > > > | HTTP/1.1 200 OK > > > > | Link: ; rel=form; title=Create new entry > > > > > > > > | > > > > | > > > > | ... > > > > | > > > > | > > > > | > > > > | > > > > > > > > > > > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > Cool stuff, actually. > > > > Jan > > > > > > > > > > > > > > Does it make sense? > > > > > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > > > > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > > > > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > > > > > POST /feed > > > Content-Type: application/order > > > > > > > > > > > > 415 Unsupported Media Type > > > Link: ; rel=form; title=Create new entry > > > Content-Type: text/html > > > > > > > > > .... Use this form to create a new entry. > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > Best regards, > > > > Ioseb > > > > > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > Jan, > > > > > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > > > > > Send the form to the appropriate target URI. > > > > > > > > > > E.g. > > > > > > > > > > GET /feed > > > > > > > > > > 200 Ok, > > > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > > > > > Then > > > > > > > > > > GET /feed/entry-form > > > > > > > > > > 200 Ok > > > > > Content-Type: application/myform > > > > > > > > > >
> > > > >
> > > > > > > > > > > > > > > Then use the form to construct the payload for the request > > > > > > > > > > - to create a new entry and POST to /collection > > > > > or > > > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > > > > > makes sense? > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > > > > > == For collection == > > > > > > | { > > > > > > | "links": [ > > > > > > | { > > > > > > | "href": "http://...", > > > > > > | "rel": "collection form", > > > > > > | "prompt": "Add new entry..." > > > > > > | } > > > > > > | ] > > > > > > | } > > > > > > > > > > > > == For item == > > > > > > | { > > > > > > | "links": [ > > > > > > | { > > > > > > | "href": "http://...", > > > > > > | "rel": "item form", > > > > > > | "prompt": "Edit entry..." > > > > > > | } > > > > > > | ] > > > > > > | } > > > > > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > > > > > P.S. > > > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > > > > > Best regards, > > > > > > Ioseb > > > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > > > > > Ioseb, > > > > > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > > > > > ==Request== > > > > > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > | "version": "1.0", > > > > > > > > | "href": "http://service.org/users", > > > > > > > > | "items": [ > > > > > > > > | { > > > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > > > | "data" : [ > > > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > > > | ], > > > > > > > > | "links" : [ > > > > > > > > | { > > > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > > > | "prompt": "Edit user" > > > > > > > > | } > > > > > > > > | ] > > > > > > > > | }, > > > > > > > > | {...}, > > > > > > > > | {...}, > > > > > > > > | {...} > > > > > > > > | ] > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > | "version": "1.0", > > > > > > > > | > > > > > > > > | "template": { > > > > > > > > | "method": { > > > > > > > > | "options": [ > > > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > > > | ] > > > > > > > > | }, > > > > > > > > | "data": [ > > > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > > > | ] > > > > > > > > | } > > > > > > > > | }} > > > > > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > | {"template": { > > > > > > > > | "data": [ > > > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > > > | ] > > > > > > > > | }} > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Ioseb > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > > > From: Jan Algermissen > > > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > Cc: > > > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > > > Hi Ioseb, > > > > > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > > > > > ..... > > > > > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > link-relations mailing list > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Ioseb Dzmanashvili > > > > > > > > Lead Architect > > > > > > > > Picktek LLC > > > > > > > > 24b Khazbegi ave. > > > > > > > > Tbilisi, 0177, Georgia > > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > > picktek.com (http://picktek.com) > > > > > > > > code.ge > > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > link-relations mailing list > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > --4fad8f1a_62fb8680_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Jan,

I update the spe= c http://tools.ietf.org/html/draft-ioseb-dzmanashvili-li= nk-relation-03 it included comprehensive information now(includi= ng you suggestions + acknowledgements). It's much better now i think.

Best regards,
Ioseb
=20

On =46riday, May 11, 2= 012 at 4:31 PM, Ioseb Dzmanashvili wrote:

> Interesting thing is that a human targeted= user agent could treat the form-links like HTML <img> links and do= wnload the forms right away, embedding them in the UI > 
> directly (maybe hidden of course). A bit like a 'typed' AJAX reque= st.
> Cool stuff, actually.

I= 'm glad you like it=21=21=21

ioseb
=20

On =46riday, May 11, 2= 012 at 4:11 PM, Jan Algermissen wrote:

<= div>

On May 11, 2012, = at 1:58 PM, Jan Algermissen wrote:


On May 11, 2012, at 1:51 PM, Ioseb Dz= manashvili wrote:

=


=3D=3D Response =3D=3D
=7C H= TTP/1.1 200 OK
=7C Link: </feed/form>; rel=3Dform; title=3D= Create new entry

=7C <feed>
=7C = <entry>
=7C ...
=7C <link rel=3D=22= self=22 href=3D=22/entries/665=22 />
=7C <link rel=3D= =22update-form=22 href=3D=22/entries/665/form=22 title=3D=22Update entry=22= />
=7C </entry>
=7C </feed>


In= teresting thing is that a human targeted user agent could treat the form-= links like HTML <img> links and download the forms right away, embe= dding them in the UI directly (maybe hidden of course). A bit like a 'typ= ed' AJAX request.

Cool stuff, actually.

Jan





Does it make sense=3F
Yes, feels better. I'll let it circle through my head whether= there is something else to it.

BTW, what would = the reaction be if I POST to create without form and the server does not = 'allow' that=3F

Should this maybe be mentioned i= n the spec as a hint=3F Any better/additional idea=3F

POST /feed
Content-Type: application/order

=
<order/>

415 Unsupported Media = Type
Link: </feed/form>; rel=3Dform; title=3DCreate new e= ntry
Content-Type: text/html

<html&= gt;
.... Use <a href=3D=22/feed/form=22 title=3D=22Entry Cre= ation =46orm=22>this form</a> to create a new entry.
&= lt;/html>


Jan




Best regards,
Ioseb

On= =46riday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote:

=

On May 11, 2= 012, at 10:57 AM, Ioseb Dzmanashvili wrote:

Jan,

I was thinki= ng about your question regarding understanding of meaning of *form*.

What is troubling me is that the = meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence= , Effectively the 'form' spec depends on some other spec that defines wha= t 'collection' and 'item' means.

This in turn me= ans that a client must understand the other specs (the media type of the = context of the 'form' link) to understand which meaning of form is in eff= ect.

I'd rather define two new relations, or, ma= ke the form apply to both cases equally and let the client figure out the= submission target URI. (Who says the form must contain the target=3F)

That way 'form' would mean: 'here is a form that y= ou can use to construct entry-submissions'. If you intend to edit an entr= y, use the form and if you intend to create a new entry use that form too= .

Send the form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Link: </feed/entry-form>; rel=3Df= orm

<feed>
<entry>
<link rel=3D=22edit=22 href=3D=22/entries/665=22/>
<= ;/entry>
....
</feed>


Then

GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form>
</form>

Then use the form to construct the payload for= the request

- to create a new entry and POST to= /collection
or
- to update an entry and PUT to e.g. = /entries/665

makes sense=3F

=
Jan




I'm not 100% sure, though as far= as it's possible to specify multiple link types as a value of the *rel* = attribute and there are already registered link relations of *collection*= and *item* types as per R=46C6573 <http://tools.ietf.org/html/rfc6573>, in order to = signify meaning of the *form* link type in resource representations it's = possible to define links this way:

=3D=3D =46or = collection =3D=3D
=7C =7B
=7C =22links=22: =5B
<= div>=7C =7B
=7C =22href=22: =22http://...=22,
=7C =22= rel=22: =22collection form=22,
=7C =22prompt=22: =22Add new ent= ry...=22
=7C =7D
=7C =5D
=7C =7D
=
=3D=3D =46or item =3D=3D
=7C =7B
=7C =22= links=22: =5B
=7C =7B
=7C =22href=22: =22http://...=22= ,
=7C =22rel=22: =22item form=22,
=7C =22prompt=22: =22= Edit entry...=22
=7C =7D
=7C =5D
=7C =7D

Again, i'm not 100% sure, though i believe it's mu= ch clear.

P.S.

Best regards,
Ioseb=
On =46riday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:<= /div>

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so f= ar I can only see one ('form'). Which is the other one you are going to d= efine=3F

I'm not sure regarding thi= s, i never mentioned another link relation type. I only created draft for= form=3F

Your draft says: =22= This specification defines a pair of reciprocal link relation types=22 - = I took 'pair' to mean 'two' , no=3F


Below is the simple example use case:=

=3D=3DRequest=3D=3D

=7C= GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+js= on

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd.collecti= on.next+json
=7C Content-Length: ...

=7C= =7B=22collection=22: =7B
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://ser= vice.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C =22data=22 = : =5B
=7C =7B=22name=22: =22name=22, =22value=22: =22John Doe=22= , =22prompt=22: =22=46ull name=22=7D,
=7C =7B=22name=22: =22ema= il=22, =22value=22: =22john=40doe.c= om=22, =22prompt=22: =22Email=22=7D,
=7C =7B=22name=22: =22= website=22, =22value=22: =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22links=22 : =5B
=7C =7B
=7C =22rel=22: =22= form=22,

How do I know the me= aning of 'form' here=3F Will this add a new entry=3F

=


Jan


=7C =22type=22: =22application/v= nd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C =5D
=7C =7D,
=7C =7B...= =7D,
=7C =7B...=7D,
=7C =7B...=7D
=7C =5D
=7C =7D=7D


=3D=3DRequest= : dereference the form resource=3D=3D

=7C GET /u= sers/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collectio= n.next+json

=3D=3DResponse=3D=3D

<= /div>
=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd= .collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22: =7B
=7C =22version=22: =221.0=22= ,
=7C
=7C =22template=22: =7B
=7C =22method= =22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22= PUT=22, =22prompt=22: =22Replace Entry=22=7D,
=7C =7B=22value=22= : =22PATCH=22, =22prompt=22: =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22:= =22first=5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst na= me=22, =22required=22: true=7D,
=7C =7B=22name=22: =22last=5Fna= me=22, =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required= =22: true=7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22= =22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D
=7C = =5D
=7C =7D
=7C =7D=7D

=3D=3D= Request: submit the modified form element=3D=3D

= =7C PATCH /users/john-doe HTTP/1.1
=7C Host: service.org
=7C Content-Type: application/= vnd.collection.next+json
=7C Content-Length: ...

=
=7C =7B=22template=22: =7B
=7C =22data=22: =5B
=
=7C =7B=22name=22: =22website=22, =22value=22: =22http://john.doe.com=22=7D
=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- =46orwarded message ----------
= =46rom: Jan Algermissen <jan.algermissen=40nordsc.com>
Cc:
Date: Mon, 7 May 2012 20:26:39 +0200
Subject: =5B= link-relations=5D Review of draft-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draf= t=5B1=5D and have a couple of questions:

You men= tion two link relations, but so far I can only see one ('form'). Which is= the other one you are going to define=3F

What i= s the exact purpose of the 'form' link relation=3F A=46AIU the client wou= ld do a GET on the link target and interpret the response body as a form = for adding entries.

Can you explain a bit, what = the use cases are you have in mind for this=3F Does it make sense to defi= ne such a relation in a general manner=3F Why=3F Do you envision the spec= ification of certain media types for the forms to be returned=3F

Then you mention the use of 'form' to edit single member= entries. I find this to be problematic because the meaning of the return= ed form (that is, the effect of submitting the form, depends on the conte= xt in which the form has been found. In one case it will be 'add a member= ' in the other it will be 'update a resource'.

H= ave you considered using media type semantics instead of link relations=3F= It would in my opinion be better to define a form media type and make th= e distinction between add and edit part of the type, not of the context i= n which a link is found.

.....

Have you looked at Mark Baker's RD=46 =46orms=5B2=5D=3F Maybe you= can build on that approach for your purpose=3F

= Jan


=5B2=5D h= ttp://www.markbaker.ca/2003/05/RD=46-=46orms/

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list


--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia=
T (+995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list
=20 =20 =20 =20

=20 =20 =20 =20 =20

--4fad8f1a_62fb8680_1745-- From ioseb.dzmanashvili@gmail.com Fri May 11 14:59:33 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D301C21F86C7 for ; Fri, 11 May 2012 14:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1+aSnuOhePt for ; Fri, 11 May 2012 14:59:32 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A15E421F86BD for ; Fri, 11 May 2012 14:59:31 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so595203wib.13 for ; Fri, 11 May 2012 14:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=T6Zb9WgbeIH43Gs5z/gEZpIdJp07RWOhkuRbyJRTgsk=; b=P8JJFQrDjIusxiEAi5wrlf/e5mHfDnxnDOmxe45w5LHBZBDVUYq7B6LYiONKEtfDnH NVHp4IJEQGKF6CzEsb/t3dUbTrrri/Hu10xN3LN0yMBKhIHyiGMT03bqvvIMyedgppJA oF5sHiec3DFbXXFxZmRUJCsQShGzhAzlWg7dN2eWnqxGtPI96HapzHp3/lk1rt05VCiS yc1IUgtL5g7/xRiJr3wQIcRHPWHAJ4F+A6Y3MfSJmpc6vJz0syprLcMFx6i0EPZy4JYz ZEWV2xXWc/CPF7wj8C+wv1jMkdnhiCpOC9GA5h7kQ+TTZ64K0xNE5B7LG2jFzBJGt5lE zHQw== Received: by 10.180.103.42 with SMTP id ft10mr11405550wib.18.1336773570712; Fri, 11 May 2012 14:59:30 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id b3sm13645733wib.4.2012.05.11.14.59.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 14:59:29 -0700 (PDT) Date: Sat, 12 May 2012 02:17:10 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad8fe6_9d30dfd_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:59:34 -0000 --4fad8fe6_9d30dfd_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Jan, I updated the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it includes comprehensive information now(including you suggestions + acknowledgements). It's much better now i think. Best regards, Ioseb On Saturday, May 12, 2012 at 2:13 AM, Ioseb Dzmanashvili wrote: > Hello Jan, > > I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now i think. > > Best regards, > Ioseb > > On Friday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote: > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI > > > > directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > Cool stuff, actually. > > > > > > I'm glad you like it!!! > > > > ioseb > > > > On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: > > > > > > > > On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: > > > > > > > > > > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > > > == Response == > > > > > | HTTP/1.1 200 OK > > > > > | Link: ; rel=form; title=Create new entry > > > > > > > > > > | > > > > > | > > > > > | ... > > > > > | > > > > > | > > > > > | > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > > > Cool stuff, actually. > > > > > > Jan > > > > > > > > > > > > > > > > > > > > Does it make sense? > > > > > > > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > > > > > > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > > > > > > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > > > > > > > POST /feed > > > > Content-Type: application/order > > > > > > > > > > > > > > > > 415 Unsupported Media Type > > > > Link: ; rel=form; title=Create new entry > > > > Content-Type: text/html > > > > > > > > > > > > .... Use this form to create a new entry. > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > Ioseb > > > > > > > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > Jan, > > > > > > > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > > > > > > > Send the form to the appropriate target URI. > > > > > > > > > > > > E.g. > > > > > > > > > > > > GET /feed > > > > > > > > > > > > 200 Ok, > > > > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > > > > > > > > > Then > > > > > > > > > > > > GET /feed/entry-form > > > > > > > > > > > > 200 Ok > > > > > > Content-Type: application/myform > > > > > > > > > > > >
> > > > > >
> > > > > > > > > > > > > > > > > > Then use the form to construct the payload for the request > > > > > > > > > > > > - to create a new entry and POST to /collection > > > > > > or > > > > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > > > > > > > makes sense? > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > > > > > > > == For collection == > > > > > > > | { > > > > > > > | "links": [ > > > > > > > | { > > > > > > > | "href": "http://...", > > > > > > > | "rel": "collection form", > > > > > > > | "prompt": "Add new entry..." > > > > > > > | } > > > > > > > | ] > > > > > > > | } > > > > > > > > > > > > > > == For item == > > > > > > > | { > > > > > > > | "links": [ > > > > > > > | { > > > > > > > | "href": "http://...", > > > > > > > | "rel": "item form", > > > > > > > | "prompt": "Edit entry..." > > > > > > > | } > > > > > > > | ] > > > > > > > | } > > > > > > > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > > > > > > > P.S. > > > > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > > > > > > > Best regards, > > > > > > > Ioseb > > > > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > > > > > > > Ioseb, > > > > > > > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > > > > > > > ==Request== > > > > > > > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > | "version": "1.0", > > > > > > > > > | "href": "http://service.org/users", > > > > > > > > > | "items": [ > > > > > > > > > | { > > > > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > > > > | "data" : [ > > > > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > > > > | ], > > > > > > > > > | "links" : [ > > > > > > > > > | { > > > > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > > > > | "prompt": "Edit user" > > > > > > > > > | } > > > > > > > > > | ] > > > > > > > > > | }, > > > > > > > > > | {...}, > > > > > > > > > | {...}, > > > > > > > > > | {...} > > > > > > > > > | ] > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > | "version": "1.0", > > > > > > > > > | > > > > > > > > > | "template": { > > > > > > > > > | "method": { > > > > > > > > > | "options": [ > > > > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > > > > | ] > > > > > > > > > | }, > > > > > > > > > | "data": [ > > > > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > > > > | ] > > > > > > > > > | } > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > | {"template": { > > > > > > > > > | "data": [ > > > > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > > > > | ] > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Ioseb > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > > > > From: Jan Algermissen > > > > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > Cc: > > > > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > > > > Hi Ioseb, > > > > > > > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > > > > > > > ..... > > > > > > > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > link-relations mailing list > > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ioseb Dzmanashvili > > > > > > > > > Lead Architect > > > > > > > > > Picktek LLC > > > > > > > > > 24b Khazbegi ave. > > > > > > > > > Tbilisi, 0177, Georgia > > > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > > > picktek.com (http://picktek.com) > > > > > > > > > code.ge > > > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > link-relations mailing list > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > --4fad8fe6_9d30dfd_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello Jan,

I updated t= he spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation= -03 it includes comprehensive information now(including you suggestions += acknowledgements). It's much better now i think.

Best regards,
Ioseb
=20

On Saturday, May 12, 2= 012 at 2:13 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

I update the spe= c http://tools.ietf.org/html/draft-ioseb-dzmanashvili-li= nk-relation-03 it included comprehensive information now(includi= ng you suggestions + acknowledgements). It's much better now i think.

Best regards,
Ioseb
=20

On =46riday, May 11, 2= 012 at 4:31 PM, Ioseb Dzmanashvili wrote:

> Interesting thing is that a human targeted= user agent could treat the form-links like HTML <img> links and do= wnload the forms right away, embedding them in the UI > 
> directly (maybe hidden of course). A bit like a 'typed' AJAX reque= st.
> Cool stuff, actually.

I= 'm glad you like it=21=21=21

ioseb
=20

On =46riday, May 11, 2= 012 at 4:11 PM, Jan Algermissen wrote:

<= div>

On May 11, 2012, = at 1:58 PM, Jan Algermissen wrote:


On May 11, 2012, at 1:51 PM, Ioseb Dz= manashvili wrote:

=


=3D=3D Response =3D=3D
=7C H= TTP/1.1 200 OK
=7C Link: </feed/form>; rel=3Dform; title=3D= Create new entry

=7C <feed>
=7C = <entry>
=7C ...
=7C <link rel=3D=22= self=22 href=3D=22/entries/665=22 />
=7C <link rel=3D= =22update-form=22 href=3D=22/entries/665/form=22 title=3D=22Update entry=22= />
=7C </entry>
=7C </feed>


In= teresting thing is that a human targeted user agent could treat the form-= links like HTML <img> links and download the forms right away, embe= dding them in the UI directly (maybe hidden of course). A bit like a 'typ= ed' AJAX request.

Cool stuff, actually.

Jan





Does it make sense=3F
Yes, feels better. I'll let it circle through my head whether= there is something else to it.

BTW, what would = the reaction be if I POST to create without form and the server does not = 'allow' that=3F

Should this maybe be mentioned i= n the spec as a hint=3F Any better/additional idea=3F

POST /feed
Content-Type: application/order

=
<order/>

415 Unsupported Media = Type
Link: </feed/form>; rel=3Dform; title=3DCreate new e= ntry
Content-Type: text/html

<html&= gt;
.... Use <a href=3D=22/feed/form=22 title=3D=22Entry Cre= ation =46orm=22>this form</a> to create a new entry.
&= lt;/html>


Jan




Best regards,
Ioseb

On= =46riday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote:

=

On May 11, 2= 012, at 10:57 AM, Ioseb Dzmanashvili wrote:

Jan,

I was thinki= ng about your question regarding understanding of meaning of *form*.

What is troubling me is that the = meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence= , Effectively the 'form' spec depends on some other spec that defines wha= t 'collection' and 'item' means.

This in turn me= ans that a client must understand the other specs (the media type of the = context of the 'form' link) to understand which meaning of form is in eff= ect.

I'd rather define two new relations, or, ma= ke the form apply to both cases equally and let the client figure out the= submission target URI. (Who says the form must contain the target=3F)

That way 'form' would mean: 'here is a form that y= ou can use to construct entry-submissions'. If you intend to edit an entr= y, use the form and if you intend to create a new entry use that form too= .

Send the form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Link: </feed/entry-form>; rel=3Df= orm

<feed>
<entry>
<link rel=3D=22edit=22 href=3D=22/entries/665=22/>
<= ;/entry>
....
</feed>


Then

GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form>
</form>

Then use the form to construct the payload for= the request

- to create a new entry and POST to= /collection
or
- to update an entry and PUT to e.g. = /entries/665

makes sense=3F

=
Jan




I'm not 100% sure, though as far= as it's possible to specify multiple link types as a value of the *rel* = attribute and there are already registered link relations of *collection*= and *item* types as per R=46C6573 <http://tools.ietf.org/html/rfc6573>, in order to = signify meaning of the *form* link type in resource representations it's = possible to define links this way:

=3D=3D =46or = collection =3D=3D
=7C =7B
=7C =22links=22: =5B
<= div>=7C =7B
=7C =22href=22: =22http://...=22,
=7C =22= rel=22: =22collection form=22,
=7C =22prompt=22: =22Add new ent= ry...=22
=7C =7D
=7C =5D
=7C =7D
=
=3D=3D =46or item =3D=3D
=7C =7B
=7C =22= links=22: =5B
=7C =7B
=7C =22href=22: =22http://...=22= ,
=7C =22rel=22: =22item form=22,
=7C =22prompt=22: =22= Edit entry...=22
=7C =7D
=7C =5D
=7C =7D

Again, i'm not 100% sure, though i believe it's mu= ch clear.

P.S.

Best regards,
Ioseb=
On =46riday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote:<= /div>

Hello Jan,

Thanks for the questions=21

You mention two link relations, but so f= ar I can only see one ('form'). Which is the other one you are going to d= efine=3F

I'm not sure regarding thi= s, i never mentioned another link relation type. I only created draft for= form=3F

Your draft says: =22= This specification defines a pair of reciprocal link relation types=22 - = I took 'pair' to mean 'two' , no=3F


Below is the simple example use case:=

=3D=3DRequest=3D=3D

=7C= GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+js= on

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd.collecti= on.next+json
=7C Content-Length: ...

=7C= =7B=22collection=22: =7B
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://ser= vice.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 : =22http://service.org/users/john-doe=22,
=7C =22data=22 = : =5B
=7C =7B=22name=22: =22name=22, =22value=22: =22John Doe=22= , =22prompt=22: =22=46ull name=22=7D,
=7C =7B=22name=22: =22ema= il=22, =22value=22: =22john=40doe.c= om=22, =22prompt=22: =22Email=22=7D,
=7C =7B=22name=22: =22= website=22, =22value=22: =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22links=22 : =5B
=7C =7B
=7C =22rel=22: =22= form=22,

How do I know the me= aning of 'form' here=3F Will this add a new entry=3F

=


Jan


=7C =22type=22: =22application/v= nd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C =5D
=7C =7D,
=7C =7B...= =7D,
=7C =7B...=7D,
=7C =7B...=7D
=7C =5D
=7C =7D=7D


=3D=3DRequest= : dereference the form resource=3D=3D

=7C GET /u= sers/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collectio= n.next+json

=3D=3DResponse=3D=3D

<= /div>
=7C HTTP/1.1 200 Ok
=7C Content-Type: application/vnd= .collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22: =7B
=7C =22version=22: =221.0=22= ,
=7C
=7C =22template=22: =7B
=7C =22method= =22: =7B
=7C =22options=22: =5B
=7C =7B=22value=22: =22= PUT=22, =22prompt=22: =22Replace Entry=22=7D,
=7C =7B=22value=22= : =22PATCH=22, =22prompt=22: =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C =22data=22: =5B
=7C =7B=22name=22:= =22first=5Fname=22, =22value=22: =22John=22, =22prompt=22: =22=46irst na= me=22, =22required=22: true=7D,
=7C =7B=22name=22: =22last=5Fna= me=22, =22value=22: =22Doe=22, =22prompt=22: =22Last name=22, =22required= =22: true=7D,
=7C =7B=22name=22: =22website=22, =22value=22: =22= =22, =22prompt=22: =22Website=22, =22type=22: =22url=22=7D
=7C = =5D
=7C =7D
=7C =7D=7D

=3D=3D= Request: submit the modified form element=3D=3D

= =7C PATCH /users/john-doe HTTP/1.1
=7C Host: service.org
=7C Content-Type: application/= vnd.collection.next+json
=7C Content-Length: ...

=
=7C =7B=22template=22: =7B
=7C =22data=22: =5B
=
=7C =7B=22name=22: =22website=22, =22value=22: =22http://john.doe.com=22=7D
=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- =46orwarded message ----------
= =46rom: Jan Algermissen <jan.algermissen=40nordsc.com>
Cc:
Date: Mon, 7 May 2012 20:26:39 +0200
Subject: =5B= link-relations=5D Review of draft-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

I have just looked at your draf= t=5B1=5D and have a couple of questions:

You men= tion two link relations, but so far I can only see one ('form'). Which is= the other one you are going to define=3F

What i= s the exact purpose of the 'form' link relation=3F A=46AIU the client wou= ld do a GET on the link target and interpret the response body as a form = for adding entries.

Can you explain a bit, what = the use cases are you have in mind for this=3F Does it make sense to defi= ne such a relation in a general manner=3F Why=3F Do you envision the spec= ification of certain media types for the forms to be returned=3F

Then you mention the use of 'form' to edit single member= entries. I find this to be problematic because the meaning of the return= ed form (that is, the effect of submitting the form, depends on the conte= xt in which the form has been found. In one case it will be 'add a member= ' in the other it will be 'update a resource'.

H= ave you considered using media type semantics instead of link relations=3F= It would in my opinion be better to define a form media type and make th= e distinction between add and edit part of the type, not of the context i= n which a link is found.

.....

Have you looked at Mark Baker's RD=46 =46orms=5B2=5D=3F Maybe you= can build on that approach for your purpose=3F

= Jan


=5B2=5D h= ttp://www.markbaker.ca/2003/05/RD=46-=46orms/

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list


--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia=
T (+995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list
=20 =20 =20 =20

=20 =20 =20 =20

=20 =20 =20 =20 =20

--4fad8fe6_9d30dfd_1745-- From jan.algermissen@nordsc.com Fri May 11 15:03:59 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA121F86DC for ; Fri, 11 May 2012 15:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=-2.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhsG75ZiEcbQ for ; Fri, 11 May 2012 15:03:58 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3121F86D8 for ; Fri, 11 May 2012 15:03:58 -0700 (PDT) Received: from [192.168.2.101] (p548FB3C8.dip.t-dialin.net [84.143.179.200]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0M5tNd-1SDERR0nw9-00xd2m; Sat, 12 May 2012 00:03:56 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: Date: Sat, 12 May 2012 00:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:G+OpJTng2WbtiotNa3WIXrM4ceMP4VM74IgaHEWWGFQ DYmXTZzBj8VDhS0n3L0XZ24vfWGyTuqa9u873Dh3CwtVGqMpSw GiJwPglJcxJIQmhfjm8nX5c0pZkXeATNdiB7bMRKltK9bVBOW5 WfLOZWo4wyf8XN87KEj07AVKPWum4E+mHOSvOO8f9M0MKuurLk 4mOEt2wZjp28guimR+o7fJJA1I0li3IMEtYNbYWsuag0pNC35V +W76qbQ81DjLDcqWNwptCC+CiN2uu31tRqGoMgCefFpTAri5gA xg1yWEAvxPG9dkVXnV01j+9vSAr9mwdY90c1kY9QGaPA8HJ4MH DvQ8Q28nGdhVDw4u3SG30QLdnI3CJR4YC/EUuJjuYwr711ARm8 jTF9+J5k2qqLA== Cc: "julian.reschke@gmx.de" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:03:59 -0000 On May 12, 2012, at 12:13 AM, Ioseb Dzmanashvili wrote: > Hello Jan, >=20 > I update the spec = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it = included comprehensive information now(including you suggestions + = acknowledgements). It's much better now i think. Thanks, I think so, too. There are a few wording issues (though I am far from being an expert on = this :-) which I will try comment on the next days. Also, consider changing form to create-form to make the two more = aligned. (No idea, BTW, whether - is allowed in the shortname) Think about dropping the passages that talk about where the link is = found (e.g. in a collection or item) because that mandates that you = explain what a collection or item is. It is not necessary anymore anyhow = because the link rels are now context independent. I'd rather say:=20 create-form points to a resource where you can find a form to be used to = append an item to the link context ('append' is fine in this case IMHO = because HTTP implicitly defines what that means in the POST section of = the spec.) update-from points to a resource where you can find a form to update the = link context. Think about it. Good work! Jan=20 >=20 > Best regards, > Ioseb > On Friday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote: >=20 >> > Interesting thing is that a human targeted user agent could treat = the form-links like HTML links and download the forms right away, = embedding them in the UI >=20 >> > directly (maybe hidden of course). A bit like a 'typed' AJAX = request. >> > Cool stuff, actually. >>=20 >> I'm glad you like it!!! >>=20 >> ioseb >> On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: >>=20 >>>=20 >>> On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: >>>=20 >>>>=20 >>>> On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> =3D=3D Response =3D=3D >>>>> | HTTP/1.1 200 OK >>>>> | Link: ; rel=3Dform; title=3DCreate new entry >>>>>=20 >>>>> | >>>>> | >>>>> | ... >>>>> | >>>>> | >>>>> | >>>>> | >>>=20 >>>=20 >>> Interesting thing is that a human targeted user agent could treat = the form-links like HTML links and download the forms right away, = embedding them in the UI directly (maybe hidden of course). A bit like a = 'typed' AJAX request. >>>=20 >>> Cool stuff, actually. >>>=20 >>> Jan >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>> Does it make sense? >>>>=20 >>>> Yes, feels better. I'll let it circle through my head whether there = is something else to it. >>>>=20 >>>> BTW, what would the reaction be if I POST to create without form = and the server does not 'allow' that? >>>>=20 >>>> Should this maybe be mentioned in the spec as a hint? Any = better/additional idea? >>>>=20 >>>> POST /feed >>>> Content-Type: application/order >>>>=20 >>>> >>>>=20 >>>> 415 Unsupported Media Type >>>> Link: ; rel=3Dform; title=3DCreate new entry >>>> Content-Type: text/html >>>>=20 >>>> >>>> .... Use this = form to create a new entry. >>>> >>>>=20 >>>>=20 >>>> Jan >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Best regards, >>>>> Ioseb >>>>>=20 >>>>> On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: >>>>>=20 >>>>>>=20 >>>>>> On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: >>>>>>=20 >>>>>>> Jan, >>>>>>>=20 >>>>>>> I was thinking about your question regarding understanding of = meaning of *form*. >>>>>>=20 >>>>>> What is troubling me is that the meaning of 'form' depends on the = meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec = depends on some other spec that defines what 'collection' and 'item' = means. >>>>>>=20 >>>>>> This in turn means that a client must understand the other specs = (the media type of the context of the 'form' link) to understand which = meaning of form is in effect. >>>>>>=20 >>>>>> I'd rather define two new relations, or, make the form apply to = both cases equally and let the client figure out the submission target = URI. (Who says the form must contain the target?) >>>>>>=20 >>>>>> That way 'form' would mean: 'here is a form that you can use to = construct entry-submissions'. If you intend to edit an entry, use the = form and if you intend to create a new entry use that form too. >>>>>>=20 >>>>>> Send the form to the appropriate target URI. >>>>>>=20 >>>>>> E.g. >>>>>>=20 >>>>>> GET /feed >>>>>>=20 >>>>>> 200 Ok, >>>>>> Link: ; rel=3Dform >>>>>>=20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> .... >>>>>> >>>>>>=20 >>>>>>=20 >>>>>> Then >>>>>>=20 >>>>>> GET /feed/entry-form >>>>>>=20 >>>>>> 200 Ok >>>>>> Content-Type: application/myform >>>>>>=20 >>>>>>
>>>>>>
>>>>>>=20 >>>>>>=20 >>>>>> Then use the form to construct the payload for the request >>>>>>=20 >>>>>> - to create a new entry and POST to /collection >>>>>> or >>>>>> - to update an entry and PUT to e.g. /entries/665 >>>>>>=20 >>>>>> makes sense? >>>>>>=20 >>>>>> Jan >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> I'm not 100% sure, though as far as it's possible to specify = multiple link types as a value of the *rel* attribute and there are = already registered link relations of *collection* and *item* types as = per RFC6573 , in order to signify = meaning of the *form* link type in resource representations it's = possible to define links this way: >>>>>>>=20 >>>>>>> =3D=3D For collection =3D=3D >>>>>>> | { >>>>>>> | "links": [ >>>>>>> | { >>>>>>> | "href": "http://...", >>>>>>> | "rel": "collection form", >>>>>>> | "prompt": "Add new entry..." >>>>>>> | } >>>>>>> | ] >>>>>>> | } >>>>>>>=20 >>>>>>> =3D=3D For item =3D=3D >>>>>>> | { >>>>>>> | "links": [ >>>>>>> | { >>>>>>> | "href": "http://...", >>>>>>> | "rel": "item form", >>>>>>> | "prompt": "Edit entry..." >>>>>>> | } >>>>>>> | ] >>>>>>> | } >>>>>>>=20 >>>>>>> Again, i'm not 100% sure, though i believe it's much clear. >>>>>>>=20 >>>>>>> P.S. >>>>>>> Most recent version of draft: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Ioseb >>>>>>> On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: >>>>>>>=20 >>>>>>>> Ioseb, >>>>>>>>=20 >>>>>>>> On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: >>>>>>>>=20 >>>>>>>>> Hello Jan, >>>>>>>>>=20 >>>>>>>>> Thanks for the questions! >>>>>>>>>=20 >>>>>>>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>>>>>=20 >>>>>>>>> I'm not sure regarding this, i never mentioned another link = relation type. I only created draft for form? >>>>>>>>=20 >>>>>>>> Your draft says: "This specification defines a pair of = reciprocal link relation types" - I took 'pair' to mean 'two' , no? >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Below is the simple example use case: >>>>>>>>>=20 >>>>>>>>> =3D=3DRequest=3D=3D >>>>>>>>>=20 >>>>>>>>> | GET /users HTTP/1.1 >>>>>>>>> | Host: service.org >>>>>>>>> | Accept: application/vnd.collection.next+json >>>>>>>>>=20 >>>>>>>>> =3D=3DResponse=3D=3D >>>>>>>>>=20 >>>>>>>>> | HTTP/1.1 200 Ok >>>>>>>>> | Content-Type: application/vnd.collection.next+json >>>>>>>>> | Content-Length: ... >>>>>>>>>=20 >>>>>>>>> | {"collection": { >>>>>>>>> | "version": "1.0", >>>>>>>>> | "href": "http://service.org/users", >>>>>>>>> | "items": [ >>>>>>>>> | { >>>>>>>>> | "href" : "http://service.org/users/john-doe", >>>>>>>>> | "data" : [ >>>>>>>>> | {"name": "name", "value": "John Doe", "prompt": "Full = name"}, >>>>>>>>> | {"name": "email", "value": "john@doe.com", "prompt": = "Email"}, >>>>>>>>> | {"name": "website", "value": "", "Prompt": "Website"} >>>>>>>>> | ], >>>>>>>>> | "links" : [ >>>>>>>>> | { >>>>>>>>> | "href": "http://service.org/users/john-doe/form", >>>>>>>>> | "rel": "form", >>>>>>>>=20 >>>>>>>> How do I know the meaning of 'form' here? Will this add a new = entry? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Jan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> | "type": "application/vnd.collection.next+json" >>>>>>>>> | "prompt": "Edit user" >>>>>>>>> | } >>>>>>>>> | ] >>>>>>>>> | }, >>>>>>>>> | {...}, >>>>>>>>> | {...}, >>>>>>>>> | {...} >>>>>>>>> | ] >>>>>>>>> | }} >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =3D=3DRequest: dereference the form resource=3D=3D >>>>>>>>>=20 >>>>>>>>> | GET /users/john-doe/form HTTP/1.1 >>>>>>>>> | Host: service.org >>>>>>>>> | Accept: application/vnd.collection.next+json >>>>>>>>>=20 >>>>>>>>> =3D=3DResponse=3D=3D >>>>>>>>>=20 >>>>>>>>> | HTTP/1.1 200 Ok >>>>>>>>> | Content-Type: application/vnd.collection.next+json >>>>>>>>> | Content-Length: ... >>>>>>>>>=20 >>>>>>>>> | {"collection": { >>>>>>>>> | "version": "1.0", >>>>>>>>> | >>>>>>>>> | "template": { >>>>>>>>> | "method": { >>>>>>>>> | "options": [ >>>>>>>>> | {"value": "PUT", "prompt": "Replace Entry"}, >>>>>>>>> | {"value": "PATCH", "prompt": "Modify Entry"} >>>>>>>>> | ] >>>>>>>>> | }, >>>>>>>>> | "data": [ >>>>>>>>> | {"name": "first_name", "value": "John", "prompt": "First = name", "required": true}, >>>>>>>>> | {"name": "last_name", "value": "Doe", "prompt": "Last name", = "required": true}, >>>>>>>>> | {"name": "website", "value": "", "prompt": "Website", = "type": "url"} >>>>>>>>> | ] >>>>>>>>> | } >>>>>>>>> | }} >>>>>>>>>=20 >>>>>>>>> =3D=3DRequest: submit the modified form element=3D=3D >>>>>>>>>=20 >>>>>>>>> | PATCH /users/john-doe HTTP/1.1 >>>>>>>>> | Host: service.org >>>>>>>>> | Content-Type: application/vnd.collection.next+json >>>>>>>>> | Content-Length: ... >>>>>>>>>=20 >>>>>>>>> | {"template": { >>>>>>>>> | "data": [ >>>>>>>>> | {"name": "website", "value": "http://john.doe.com"} >>>>>>>>> | ] >>>>>>>>> | }} >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>> Ioseb >>>>>>>>>=20 >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: Jan Algermissen >>>>>>>>> To: link-relations@ietf.org >>>>>>>>> Cc: >>>>>>>>> Date: Mon, 7 May 2012 20:26:39 +0200 >>>>>>>>> Subject: [link-relations] Review of = draft-ioseb-dzmanashvili-link-relation-00 >>>>>>>>> Hi Ioseb, >>>>>>>>>=20 >>>>>>>>> I have just looked at your draft[1] and have a couple of = questions: >>>>>>>>>=20 >>>>>>>>> You mention two link relations, but so far I can only see one = ('form'). Which is the other one you are going to define? >>>>>>>>>=20 >>>>>>>>> What is the exact purpose of the 'form' link relation? AFAIU = the client would do a GET on the link target and interpret the response = body as a form for adding entries. >>>>>>>>>=20 >>>>>>>>> Can you explain a bit, what the use cases are you have in mind = for this? Does it make sense to define such a relation in a general = manner? Why? Do you envision the specification of certain media types = for the forms to be returned? >>>>>>>>>=20 >>>>>>>>> Then you mention the use of 'form' to edit single member = entries. I find this to be problematic because the meaning of the = returned form (that is, the effect of submitting the form, depends on = the context in which the form has been found. In one case it will be = 'add a member' in the other it will be 'update a resource'. >>>>>>>>>=20 >>>>>>>>> Have you considered using media type semantics instead of link = relations? It would in my opinion be better to define a form media type = and make the distinction between add and edit part of the type, not of = the context in which a link is found. >>>>>>>>>=20 >>>>>>>>> ..... >>>>>>>>>=20 >>>>>>>>> Have you looked at Mark Baker's RDF Forms[2]? Maybe you can = build on that approach for your purpose? >>>>>>>>>=20 >>>>>>>>> Jan >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> [1] = http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt >>>>>>>>> [2] http://www.markbaker.ca/2003/05/RDF-Forms/ >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> link-relations mailing list >>>>>>>>> link-relations@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/link-relations >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Ioseb Dzmanashvili >>>>>>>>> Lead Architect >>>>>>>>> Picktek LLC >>>>>>>>> 24b Khazbegi ave. >>>>>>>>> Tbilisi, 0177, Georgia >>>>>>>>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>>>>>>>> picktek.com >>>>>>>>> code.ge >>>>>>>>> github.com/ioseb >>>>>>>>> twitter.com/iosebi >>>>=20 >>>> _______________________________________________ >>>> link-relations mailing list >>>> link-relations@ietf.org >>>> https://www.ietf.org/mailman/listinfo/link-relations >>=20 >=20 From ioseb.dzmanashvili@gmail.com Fri May 11 15:08:08 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318F21F86DC for ; Fri, 11 May 2012 15:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ5NoABpJ0nv for ; Fri, 11 May 2012 15:08:07 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6204021F865B for ; Fri, 11 May 2012 15:08:06 -0700 (PDT) Received: by werf13 with SMTP id f13so1720682wer.31 for ; Fri, 11 May 2012 15:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=FZw6TMStmvsprtEPskqg9kCV0vKcW7PDDGrs1oEgYJw=; b=wK8tbYm7mSR+lXMoHKbX2K529/4QAE6IhVo4oh+qMVGf847eOJf8oh/RuiOwcUZqAp gdmyhVweNM9iam3i05sDih6eknORzjAY48IgRkDFAsxBe/rsOiulrX8oxTHKSnqBoDEL QarvQNdmbbL/HTPSN5SieIzKAQf/ITbYDBXDKUVCRDNj/nRsrtXpov95od+onrbXTrma F/2dlrv8Y7qcaC/KIve6mYGQZA9Y2wBu/v/N0l4E0zKSzKFcPq0vYNnyC1b2J7bKjL6H d4bQ7ZWXhFYfG7uI6RD3fZzKJAB448THM5JusSeWheyFKKvNjsjnrotLLsxyN5ypWd1b LIvQ== Received: by 10.180.78.105 with SMTP id a9mr11373686wix.20.1336774085520; Fri, 11 May 2012 15:08:05 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id h8sm21826422wix.4.2012.05.11.15.08.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 15:08:04 -0700 (PDT) Date: Sat, 12 May 2012 02:25:44 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad91e8_32766a55_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:08:08 -0000 --4fad91e8_32766a55_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for quick response and suggestions! I'll modify link relation name and texts over weekend for sure. Ioseb On Saturday, May 12, 2012 at 2:03 AM, Jan Algermissen wrote: > > On May 12, 2012, at 12:13 AM, Ioseb Dzmanashvili wrote: > > > Hello Jan, > > > > I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now i think. > > Thanks, I think so, too. > > There are a few wording issues (though I am far from being an expert on this :-) which I will try comment on the next days. > > Also, consider changing form to create-form to make the two more aligned. (No idea, BTW, whether - is allowed in the shortname) > > Think about dropping the passages that talk about where the link is found (e.g. in a collection or item) because that mandates that you explain what a collection or item is. It is not necessary anymore anyhow because the link rels are now context independent. > > I'd rather say: > > create-form points to a resource where you can find a form to be used to append an item to the link context ('append' is fine in this case IMHO because HTTP implicitly defines what that means in the POST section of the spec.) > > update-from points to a resource where you can find a form to update the link context. > > Think about it. > > Good work! > > Jan > > > > > > > Best regards, > > Ioseb > > On Friday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote: > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI > > > > > directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > Cool stuff, actually. > > > > > > > > > > > > > I'm glad you like it!!! > > > > > > ioseb > > > On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: > > > > > > > > > > > On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > > > > > > > == Response == > > > > > > | HTTP/1.1 200 OK > > > > > > | Link: ; rel=form; title=Create new entry > > > > > > > > > > > > | > > > > > > | > > > > > > | ... > > > > > > | > > > > > > | > > > > > > | > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > > > > > Cool stuff, actually. > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > > > > > > > > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > > > > > > > > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > > > > > > > > > POST /feed > > > > > Content-Type: application/order > > > > > > > > > > > > > > > > > > > > 415 Unsupported Media Type > > > > > Link: ; rel=form; title=Create new entry > > > > > Content-Type: text/html > > > > > > > > > > > > > > > .... Use this form to create a new entry. > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Ioseb > > > > > > > > > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > Jan, > > > > > > > > > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > > > > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > > > > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > > > > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > > > > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > > > > > > > > > Send the form to the appropriate target URI. > > > > > > > > > > > > > > E.g. > > > > > > > > > > > > > > GET /feed > > > > > > > > > > > > > > 200 Ok, > > > > > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then > > > > > > > > > > > > > > GET /feed/entry-form > > > > > > > > > > > > > > 200 Ok > > > > > > > Content-Type: application/myform > > > > > > > > > > > > > >
> > > > > > >
> > > > > > > > > > > > > > > > > > > > > Then use the form to construct the payload for the request > > > > > > > > > > > > > > - to create a new entry and POST to /collection > > > > > > > or > > > > > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > > > > > > > > > makes sense? > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > > > > > > > > > == For collection == > > > > > > > > | { > > > > > > > > | "links": [ > > > > > > > > | { > > > > > > > > | "href": "http://...", > > > > > > > > | "rel": "collection form", > > > > > > > > | "prompt": "Add new entry..." > > > > > > > > | } > > > > > > > > | ] > > > > > > > > | } > > > > > > > > > > > > > > > > == For item == > > > > > > > > | { > > > > > > > > | "links": [ > > > > > > > > | { > > > > > > > > | "href": "http://...", > > > > > > > > | "rel": "item form", > > > > > > > > | "prompt": "Edit entry..." > > > > > > > > | } > > > > > > > > | ] > > > > > > > > | } > > > > > > > > > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > > > > > > > > > P.S. > > > > > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Ioseb > > > > > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > Ioseb, > > > > > > > > > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > > > > > > > > > ==Request== > > > > > > > > > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > > | "version": "1.0", > > > > > > > > > > | "href": "http://service.org/users", > > > > > > > > > > | "items": [ > > > > > > > > > > | { > > > > > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > > > > > | "data" : [ > > > > > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > > > > > | ], > > > > > > > > > > | "links" : [ > > > > > > > > > > | { > > > > > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > > > > > | "prompt": "Edit user" > > > > > > > > > > | } > > > > > > > > > > | ] > > > > > > > > > > | }, > > > > > > > > > > | {...}, > > > > > > > > > > | {...}, > > > > > > > > > > | {...} > > > > > > > > > > | ] > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > > | "version": "1.0", > > > > > > > > > > | > > > > > > > > > > | "template": { > > > > > > > > > > | "method": { > > > > > > > > > > | "options": [ > > > > > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > > > > > | ] > > > > > > > > > > | }, > > > > > > > > > > | "data": [ > > > > > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > > > > > | ] > > > > > > > > > > | } > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > | {"template": { > > > > > > > > > > | "data": [ > > > > > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > > > > > | ] > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Ioseb > > > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > > > > > From: Jan Algermissen > > > > > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > > Cc: > > > > > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > > > > > Hi Ioseb, > > > > > > > > > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > > > > > > > > > ..... > > > > > > > > > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > link-relations mailing list > > > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Ioseb Dzmanashvili > > > > > > > > > > Lead Architect > > > > > > > > > > Picktek LLC > > > > > > > > > > 24b Khazbegi ave. > > > > > > > > > > Tbilisi, 0177, Georgia > > > > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > > > > picktek.com (http://picktek.com) > > > > > > > > > > code.ge > > > > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > link-relations mailing list > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > --4fad91e8_32766a55_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks for quick response and suggestions=21 

I'll modify link relation name and texts over wee= kend for sure.

Ioseb

On Saturday, May 12, 2012 at 2:03 AM, Jan Alg= ermissen wrote:

On May 12, 2012, = at 12:13 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

I update th= e spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-li= nk-relation-03 it included comprehensive information now(including yo= u suggestions + acknowledgements). It's much better now i think.

Thanks, I think so, too.
There are a few wording issues (though I am far from being a= n expert on this :-) which I will try comment on the next days.

Also, consider changing form to create-form to make the t= wo more aligned. (No idea, BTW, whether - is allowed in the shortname)

Think about dropping the passages that talk about = where the link is found (e.g. in a collection or item) because that manda= tes that you explain what a collection or item is. It is not necessary an= ymore anyhow because the link rels are now context independent.

I'd rather say:

create-form poi= nts to a resource where you can find a form to be used to append an item = to the link context ('append' is fine in this case IMHO because HTTP impl= icitly defines what that means in the POST section of the spec.)

update-from points to a resource where you can find a fo= rm to update the link context.

Think about it.

Good work=21

Jan
<= div>



Best regards,
Ioseb
On =46r= iday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote:

Interesting thing is that a human targeted user agent could treat t= he form-links like HTML <img> links and download the forms right aw= ay, embedding them in the UI >
directly (maybe hidden of co= urse). A bit like a 'typed' AJAX request.
Cool stuff, actually.=

I'm glad you like it=21=21=21=

ioseb
On =46riday, May 11, 2012 at 4:= 11 PM, Jan Algermissen wrote:


On May 11, 2012, at 1:58 PM, Jan Algermis= sen wrote:

On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote:
=


=3D=3D Response =3D=3D
=7C HTTP/1.1 200 OK
=7C Link: </feed/form>; rel=3Dform; title=3DCreate new entry

=7C <feed>
=7C <entry>
=7C ...
=7C <link rel=3D=22self=22 href=3D=22/entries/665= =22 />
=7C <link rel=3D=22update-form=22 href=3D=22/entri= es/665/form=22 title=3D=22Update entry=22 />
=7C </entry&= gt;
=7C </feed>


Interesting thing is that a human ta= rgeted user agent could treat the form-links like HTML <img> links = and download the forms right away, embedding them in the UI directly (may= be hidden of course). A bit like a 'typed' AJAX request.

Cool stuff, actually.

Jan




Does it m= ake sense=3F

Yes, feels better. I'l= l let it circle through my head whether there is something else to it.

BTW, what would the reaction be if I POST to creat= e without form and the server does not 'allow' that=3F

Should this maybe be mentioned in the spec as a hint=3F Any better= /additional idea=3F

POST /feed
Content= -Type: application/order

<order/>

415 Unsupported Media Type
Link: </feed/for= m>; rel=3Dform; title=3DCreate new entry
Content-Type: text/= html

<html>
.... Use <a href=3D= =22/feed/form=22 title=3D=22Entry Creation =46orm=22>this form</a&g= t; to create a new entry.
</html>


Jan




Best regards,
<= div>Ioseb

On =46riday, May 11, 2012 at 1:06 PM, = Jan Algermissen wrote:

=

On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili= wrote:

Jan,<= /div>

I was thinking about your question regarding und= erstanding of meaning of *form*.

<= div>What is troubling me is that the meaning of 'form' depends on the mea= ning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depend= s on some other spec that defines what 'collection' and 'item' means.

This in turn means that a client must understand th= e other specs (the media type of the context of the 'form' link) to under= stand which meaning of form is in effect.

I'd ra= ther define two new relations, or, make the form apply to both cases equa= lly and let the client figure out the submission target URI. (Who says th= e form must contain the target=3F)

That way 'for= m' would mean: 'here is a form that you can use to construct entry-submis= sions'. If you intend to edit an entry, use the form and if you intend to= create a new entry use that form too.

Send the = form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Li= nk: </feed/entry-form>; rel=3Dform

<fee= d>
<entry>
<link rel=3D=22edit=22 href=3D= =22/entries/665=22/>
</entry>
....
</feed>


Then
GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form><= /div>
</form>


Then use = the form to construct the payload for the request

- to create a new entry and POST to /collection
or
= - to update an entry and PUT to e.g. /entries/665

makes sense=3F

Jan



=
I'm not 100% sure, though as far as it's possible to specify multipl= e link types as a value of the *rel* attribute and there are already regi= stered link relations of *collection* and *item* types as per R=46C6573 &= lt;http://tools.ietf.o= rg/html/rfc6573>, in order to signify meaning of the *form* link t= ype in resource representations it's possible to define links this way:

=3D=3D =46or collection =3D=3D
=7C =7B<= /div>
=7C =22links=22: =5B
=7C =7B
=7C =22href=22= : =22http://...=22,
=7C =22rel=22: =22collection form=22,
=
=7C =22prompt=22: =22Add new entry...=22
=7C =7D
=7C =5D
=7C =7D

=3D=3D =46or item =3D= =3D
=7C =7B
=7C =22links=22: =5B
=7C =7B
=7C =22href=22: =22http://...=22,
=7C =22rel=22: =22ite= m form=22,
=7C =22prompt=22: =22Edit entry...=22
=7C = =7D
=7C =5D
=7C =7D

Again, i= 'm not 100% sure, though i believe it's much clear.

<= div>P.S.
Best regards,
Ioseb
On =46riday, May 11,= 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 201= 2, at 10:21 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

Thanks f= or the questions=21

You mention two link relations, but so far I can only see one ('form').= Which is the other one you are going to define=3F

I'm not sure regarding this, i never mentioned another li= nk relation type. I only created draft for form=3F

Your draft says: =22This specification defines a pa= ir of reciprocal link relation types=22 - I took 'pair' to mean 'two' , n= o=3F


Below is the simple example use case:

=3D= =3DRequest=3D=3D

=7C GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=
=7C Content-Type: application/vnd.collection.next+json
=7C= Content-Length: ...

=7C =7B=22collection=22: =7B=
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://service.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 := =22http://service.org/= users/john-doe=22,
=7C =22data=22 : =5B
=7C =7B=22= name=22: =22name=22, =22value=22: =22John Doe=22, =22prompt=22: =22=46ull= name=22=7D,
=7C =7B=22name=22: =22email=22, =22value=22: =22john=40doe.com=22, =22prompt=22: = =22Email=22=7D,
=7C =7B=22name=22: =22website=22, =22value=22: = =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22= links=22 : =5B
=7C =7B
=7C =22rel=22: =22form=22,

How do I know the meaning of 'form' here=3F Will = this add a new entry=3F



Jan


=7C =22type=22: =22application/vnd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C = =5D
=7C =7D,
=7C =7B...=7D,
=7C =7B...=7D,<= /div>
=7C =7B...=7D
=7C =5D
=7C =7D=7D
=

=3D=3DRequest: dereference the form resourc= e=3D=3D

=7C GET /users/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok<= /div>
=7C Content-Type: application/vnd.collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22= : =7B
=7C =22version=22: =221.0=22,
=7C
=7C= =22template=22: =7B
=7C =22method=22: =7B
=7C =22opt= ions=22: =5B
=7C =7B=22value=22: =22PUT=22, =22prompt=22: =22Re= place Entry=22=7D,
=7C =7B=22value=22: =22PATCH=22, =22prompt=22= : =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C= =22data=22: =5B
=7C =7B=22name=22: =22first=5Fname=22, =22valu= e=22: =22John=22, =22prompt=22: =22=46irst name=22, =22required=22: true=7D= ,
=7C =7B=22name=22: =22last=5Fname=22, =22value=22: =22Doe=22,= =22prompt=22: =22Last name=22, =22required=22: true=7D,
=7C =7B= =22name=22: =22website=22, =22value=22: =22=22, =22prompt=22: =22Website=22= , =22type=22: =22url=22=7D
=7C =5D
=7C =7D
= =7C =7D=7D

=3D=3DRequest: submit the modified fo= rm element=3D=3D

=7C PATCH /users/john-doe HTTP/= 1.1
=7C Host: service.org
<= div>=7C Content-Length: ...

=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- = =46orwarded message ----------
=46rom: Jan Algermissen <jan.algermissen=40nordsc.= com>
Cc:
Date: Mon, 7 May 2= 012 20:26:39 +0200
Subject: =5Blink-relations=5D Review of draf= t-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

<= /div>
I have just looked at your draft=5B1=5D and have a couple of qu= estions:

You mention two link relations, but so = far I can only see one ('form'). Which is the other one you are going to = define=3F

What is the exact purpose of the 'form= ' link relation=3F A=46AIU the client would do a GET on the link target a= nd interpret the response body as a form for adding entries.
Can you explain a bit, what the use cases are you have in mi= nd for this=3F Does it make sense to define such a relation in a general = manner=3F Why=3F Do you envision the specification of certain media types= for the forms to be returned=3F

Then you mentio= n the use of 'form' to edit single member entries. I find this to be prob= lematic because the meaning of the returned form (that is, the effect of = submitting the form, depends on the context in which the form has been fo= und. In one case it will be 'add a member' in the other it will be 'updat= e a resource'.

Have you considered using media t= ype semantics instead of link relations=3F It would in my opinion be bett= er to define a form media type and make the distinction between add and e= dit part of the type, not of the context in which a link is found.
<= div>
.....

Have you looked at Mark= Baker's RD=46 =46orms=5B2=5D=3F Maybe you can build on that approach for= your purpose=3F

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing lis= t


--
Ioseb Dzmana= shvili
Lead Architect
Picktek LLC
24b Khazb= egi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.56,= =46 (+1 202) 315.3934
code.ge
<= /div>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list
=20 =20 =20 =20 =20

--4fad91e8_32766a55_1745-- From ioseb.dzmanashvili@gmail.com Fri May 11 15:33:14 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9050321F8638 for ; Fri, 11 May 2012 15:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG2joefgqJIv for ; Fri, 11 May 2012 15:33:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7E521F8634 for ; Fri, 11 May 2012 15:33:12 -0700 (PDT) Received: by werf13 with SMTP id f13so1730141wer.31 for ; Fri, 11 May 2012 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=qUzbUktTipoSHOv1wkfbX1PJKLM8PfEE3/pjTgfLGXA=; b=mqqs8ZpAngF/ALR3JzmCSMnyVY+sWfFSjn/dVtCqGgx3aI/G2Voi1QHzuexuuSNOiA vayr/AH7EPMskb13vARo+dKGAUlyGCk8fFPlpIPjThfXVcQdKP8qBlLh+YiI9v0OEUcQ pG+4SqFSFKKp4Sk0T1cyDiVpFlJ2cSDMZBUnADZVtTmhhnrKnFKHV7WWCy/Tg4Mov2hg rLzbupKqyxHO+/1zXl/MRjH0KPxIPIgSGG9OnJTKHO186liIJlXPpQok7xcLduwvun+1 HA/ef7H9kT6h7xasEDW3zQfPQk2STuDTRoUkvMXln6G+2hvJk7KpcTXwXRfZMX/xVwRo NyBA== Received: by 10.216.19.195 with SMTP id n45mr597932wen.69.1336775591243; Fri, 11 May 2012 15:33:11 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id et10sm2396124wib.2.2012.05.11.15.33.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 May 2012 15:33:10 -0700 (PDT) Date: Sat, 12 May 2012 02:50:50 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fad97ca_49d1fea0_1745" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 22:33:14 -0000 --4fad97ca_49d1fea0_1745 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Changed link relation name and some wording: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-04 Thanks again! Best regards, Ioseb On Saturday, May 12, 2012 at 2:25 AM, Ioseb Dzmanashvili wrote: > Thanks for quick response and suggestions! > > I'll modify link relation name and texts over weekend for sure. > > Ioseb > > On Saturday, May 12, 2012 at 2:03 AM, Jan Algermissen wrote: > > > > On May 12, 2012, at 12:13 AM, Ioseb Dzmanashvili wrote: > > > > > Hello Jan, > > > > > > I update the spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-03 it included comprehensive information now(including you suggestions + acknowledgements). It's much better now i think. > > > > Thanks, I think so, too. > > > > There are a few wording issues (though I am far from being an expert on this :-) which I will try comment on the next days. > > > > Also, consider changing form to create-form to make the two more aligned. (No idea, BTW, whether - is allowed in the shortname) > > > > Think about dropping the passages that talk about where the link is found (e.g. in a collection or item) because that mandates that you explain what a collection or item is. It is not necessary anymore anyhow because the link rels are now context independent. > > > > I'd rather say: > > > > create-form points to a resource where you can find a form to be used to append an item to the link context ('append' is fine in this case IMHO because HTTP implicitly defines what that means in the POST section of the spec.) > > > > update-from points to a resource where you can find a form to update the link context. > > > > Think about it. > > > > Good work! > > > > Jan > > > > > > > > > > > > Best regards, > > > Ioseb > > > On Friday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote: > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI > > > > > > directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > > Cool stuff, actually. > > > > > > > > > > > > > > > > > I'm glad you like it!!! > > > > > > > > ioseb > > > > On Friday, May 11, 2012 at 4:11 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > On May 11, 2012, at 1:58 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > == Response == > > > > > > > | HTTP/1.1 200 OK > > > > > > > | Link: ; rel=form; title=Create new entry > > > > > > > > > > > > > > | > > > > > > > | > > > > > > > | ... > > > > > > > | > > > > > > > | > > > > > > > | > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Interesting thing is that a human targeted user agent could treat the form-links like HTML links and download the forms right away, embedding them in the UI directly (maybe hidden of course). A bit like a 'typed' AJAX request. > > > > > > > > > > Cool stuff, actually. > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does it make sense? > > > > > > > > > > > > Yes, feels better. I'll let it circle through my head whether there is something else to it. > > > > > > > > > > > > BTW, what would the reaction be if I POST to create without form and the server does not 'allow' that? > > > > > > > > > > > > Should this maybe be mentioned in the spec as a hint? Any better/additional idea? > > > > > > > > > > > > POST /feed > > > > > > Content-Type: application/order > > > > > > > > > > > > > > > > > > > > > > > > 415 Unsupported Media Type > > > > > > Link: ; rel=form; title=Create new entry > > > > > > Content-Type: text/html > > > > > > > > > > > > > > > > > > .... Use this form to create a new entry. > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Ioseb > > > > > > > > > > > > > > On Friday, May 11, 2012 at 1:06 PM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > > > > > > > On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > Jan, > > > > > > > > > > > > > > > > > > I was thinking about your question regarding understanding of meaning of *form*. > > > > > > > > > > > > > > > > What is troubling me is that the meaning of 'form' depends on the meaning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depends on some other spec that defines what 'collection' and 'item' means. > > > > > > > > > > > > > > > > This in turn means that a client must understand the other specs (the media type of the context of the 'form' link) to understand which meaning of form is in effect. > > > > > > > > > > > > > > > > I'd rather define two new relations, or, make the form apply to both cases equally and let the client figure out the submission target URI. (Who says the form must contain the target?) > > > > > > > > > > > > > > > > That way 'form' would mean: 'here is a form that you can use to construct entry-submissions'. If you intend to edit an entry, use the form and if you intend to create a new entry use that form too. > > > > > > > > > > > > > > > > Send the form to the appropriate target URI. > > > > > > > > > > > > > > > > E.g. > > > > > > > > > > > > > > > > GET /feed > > > > > > > > > > > > > > > > 200 Ok, > > > > > > > > Link: ; rel=form > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then > > > > > > > > > > > > > > > > GET /feed/entry-form > > > > > > > > > > > > > > > > 200 Ok > > > > > > > > Content-Type: application/myform > > > > > > > > > > > > > > > >
> > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Then use the form to construct the payload for the request > > > > > > > > > > > > > > > > - to create a new entry and POST to /collection > > > > > > > > or > > > > > > > > - to update an entry and PUT to e.g. /entries/665 > > > > > > > > > > > > > > > > makes sense? > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not 100% sure, though as far as it's possible to specify multiple link types as a value of the *rel* attribute and there are already registered link relations of *collection* and *item* types as per RFC6573 , in order to signify meaning of the *form* link type in resource representations it's possible to define links this way: > > > > > > > > > > > > > > > > > > == For collection == > > > > > > > > > | { > > > > > > > > > | "links": [ > > > > > > > > > | { > > > > > > > > > | "href": "http://...", > > > > > > > > > | "rel": "collection form", > > > > > > > > > | "prompt": "Add new entry..." > > > > > > > > > | } > > > > > > > > > | ] > > > > > > > > > | } > > > > > > > > > > > > > > > > > > == For item == > > > > > > > > > | { > > > > > > > > > | "links": [ > > > > > > > > > | { > > > > > > > > > | "href": "http://...", > > > > > > > > > | "rel": "item form", > > > > > > > > > | "prompt": "Edit entry..." > > > > > > > > > | } > > > > > > > > > | ] > > > > > > > > > | } > > > > > > > > > > > > > > > > > > Again, i'm not 100% sure, though i believe it's much clear. > > > > > > > > > > > > > > > > > > P.S. > > > > > > > > > Most recent version of draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-02 > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Ioseb > > > > > > > > > On Friday, May 11, 2012 at 1:13 AM, Jan Algermissen wrote: > > > > > > > > > > > > > > > > > > > Ioseb, > > > > > > > > > > > > > > > > > > > > On May 8, 2012, at 10:21 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > > > > > > > > > Hello Jan, > > > > > > > > > > > > > > > > > > > > > > Thanks for the questions! > > > > > > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > > > > > I'm not sure regarding this, i never mentioned another link relation type. I only created draft for form? > > > > > > > > > > > > > > > > > > > > Your draft says: "This specification defines a pair of reciprocal link relation types" - I took 'pair' to mean 'two' , no? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Below is the simple example use case: > > > > > > > > > > > > > > > > > > > > > > ==Request== > > > > > > > > > > > > > > > > > > > > > > | GET /users HTTP/1.1 > > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > > > | "version": "1.0", > > > > > > > > > > > | "href": "http://service.org/users", > > > > > > > > > > > | "items": [ > > > > > > > > > > > | { > > > > > > > > > > > | "href" : "http://service.org/users/john-doe", > > > > > > > > > > > | "data" : [ > > > > > > > > > > > | {"name": "name", "value": "John Doe", "prompt": "Full name"}, > > > > > > > > > > > | {"name": "email", "value": "john@doe.com (mailto:john@doe.com)", "prompt": "Email"}, > > > > > > > > > > > | {"name": "website", "value": "", "Prompt": "Website"} > > > > > > > > > > > | ], > > > > > > > > > > > | "links" : [ > > > > > > > > > > > | { > > > > > > > > > > > | "href": "http://service.org/users/john-doe/form", > > > > > > > > > > > | "rel": "form", > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How do I know the meaning of 'form' here? Will this add a new entry? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | "type": "application/vnd.collection.next+json" > > > > > > > > > > > | "prompt": "Edit user" > > > > > > > > > > > | } > > > > > > > > > > > | ] > > > > > > > > > > > | }, > > > > > > > > > > > | {...}, > > > > > > > > > > > | {...}, > > > > > > > > > > > | {...} > > > > > > > > > > > | ] > > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ==Request: dereference the form resource== > > > > > > > > > > > > > > > > > > > > > > | GET /users/john-doe/form HTTP/1.1 > > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > > | Accept: application/vnd.collection.next+json > > > > > > > > > > > > > > > > > > > > > > ==Response== > > > > > > > > > > > > > > > > > > > > > > | HTTP/1.1 200 Ok > > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > > > | {"collection": { > > > > > > > > > > > | "version": "1.0", > > > > > > > > > > > | > > > > > > > > > > > | "template": { > > > > > > > > > > > | "method": { > > > > > > > > > > > | "options": [ > > > > > > > > > > > | {"value": "PUT", "prompt": "Replace Entry"}, > > > > > > > > > > > | {"value": "PATCH", "prompt": "Modify Entry"} > > > > > > > > > > > | ] > > > > > > > > > > > | }, > > > > > > > > > > > | "data": [ > > > > > > > > > > > | {"name": "first_name", "value": "John", "prompt": "First name", "required": true}, > > > > > > > > > > > | {"name": "last_name", "value": "Doe", "prompt": "Last name", "required": true}, > > > > > > > > > > > | {"name": "website", "value": "", "prompt": "Website", "type": "url"} > > > > > > > > > > > | ] > > > > > > > > > > > | } > > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > ==Request: submit the modified form element== > > > > > > > > > > > > > > > > > > > > > > | PATCH /users/john-doe HTTP/1.1 > > > > > > > > > > > | Host: service.org (http://service.org) > > > > > > > > > > > | Content-Type: application/vnd.collection.next+json > > > > > > > > > > > | Content-Length: ... > > > > > > > > > > > > > > > > > > > > > > | {"template": { > > > > > > > > > > > | "data": [ > > > > > > > > > > > | {"name": "website", "value": "http://john.doe.com"} > > > > > > > > > > > | ] > > > > > > > > > > > | }} > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > Ioseb > > > > > > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > > > > > > From: Jan Algermissen > > > > > > > > > > > To: link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > > > Cc: > > > > > > > > > > > Date: Mon, 7 May 2012 20:26:39 +0200 > > > > > > > > > > > Subject: [link-relations] Review of draft-ioseb-dzmanashvili-link-relation-00 > > > > > > > > > > > Hi Ioseb, > > > > > > > > > > > > > > > > > > > > > > I have just looked at your draft[1] and have a couple of questions: > > > > > > > > > > > > > > > > > > > > > > You mention two link relations, but so far I can only see one ('form'). Which is the other one you are going to define? > > > > > > > > > > > > > > > > > > > > > > What is the exact purpose of the 'form' link relation? AFAIU the client would do a GET on the link target and interpret the response body as a form for adding entries. > > > > > > > > > > > > > > > > > > > > > > Can you explain a bit, what the use cases are you have in mind for this? Does it make sense to define such a relation in a general manner? Why? Do you envision the specification of certain media types for the forms to be returned? > > > > > > > > > > > > > > > > > > > > > > Then you mention the use of 'form' to edit single member entries. I find this to be problematic because the meaning of the returned form (that is, the effect of submitting the form, depends on the context in which the form has been found. In one case it will be 'add a member' in the other it will be 'update a resource'. > > > > > > > > > > > > > > > > > > > > > > Have you considered using media type semantics instead of link relations? It would in my opinion be better to define a form media type and make the distinction between add and edit part of the type, not of the context in which a link is found. > > > > > > > > > > > > > > > > > > > > > > ..... > > > > > > > > > > > > > > > > > > > > > > Have you looked at Mark Baker's RDF Forms[2]? Maybe you can build on that approach for your purpose? > > > > > > > > > > > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] http://www.ietf.org/id/draft-ioseb-dzmanashvili-link-relation-00.txt > > > > > > > > > > > [2] http://www.markbaker.ca/2003/05/RDF-Forms/ > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > link-relations mailing list > > > > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Ioseb Dzmanashvili > > > > > > > > > > > Lead Architect > > > > > > > > > > > Picktek LLC > > > > > > > > > > > 24b Khazbegi ave. > > > > > > > > > > > Tbilisi, 0177, Georgia > > > > > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > > > > > picktek.com (http://picktek.com) > > > > > > > > > > > code.ge > > > > > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > link-relations mailing list > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --4fad97ca_49d1fea0_1745 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Changed link relation name and some wording: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relati= on-04

Thanks again=21 

Best regards,
Ioseb
=20

On Saturday, May 12, 2= 012 at 2:25 AM, Ioseb Dzmanashvili wrote:

Thanks for quick response and suggestions=21 

I'll modify link relation name and texts over wee= kend for sure.

Ioseb

On Saturday, May 12, 2012 at 2:03 AM, Jan Alg= ermissen wrote:

On May 12, 2012, = at 12:13 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

I update th= e spec http://tools.ietf.org/html/draft-ioseb-dzmanashvili-li= nk-relation-03 it included comprehensive information now(including yo= u suggestions + acknowledgements). It's much better now i think.

Thanks, I think so, too.
There are a few wording issues (though I am far from being a= n expert on this :-) which I will try comment on the next days.

Also, consider changing form to create-form to make the t= wo more aligned. (No idea, BTW, whether - is allowed in the shortname)

Think about dropping the passages that talk about = where the link is found (e.g. in a collection or item) because that manda= tes that you explain what a collection or item is. It is not necessary an= ymore anyhow because the link rels are now context independent.

I'd rather say:

create-form poi= nts to a resource where you can find a form to be used to append an item = to the link context ('append' is fine in this case IMHO because HTTP impl= icitly defines what that means in the POST section of the spec.)

update-from points to a resource where you can find a fo= rm to update the link context.

Think about it.

Good work=21

Jan
<= div>



Best regards,
Ioseb
On =46r= iday, May 11, 2012 at 4:31 PM, Ioseb Dzmanashvili wrote:

Interesting thing is that a human targeted user agent could treat t= he form-links like HTML <img> links and download the forms right aw= ay, embedding them in the UI >
directly (maybe hidden of co= urse). A bit like a 'typed' AJAX request.
Cool stuff, actually.=

I'm glad you like it=21=21=21=

ioseb
On =46riday, May 11, 2012 at 4:= 11 PM, Jan Algermissen wrote:


On May 11, 2012, at 1:58 PM, Jan Algermis= sen wrote:

On May 11, 2012, at 1:51 PM, Ioseb Dzmanashvili wrote:
=


=3D=3D Response =3D=3D
=7C HTTP/1.1 200 OK
=7C Link: </feed/form>; rel=3Dform; title=3DCreate new entry

=7C <feed>
=7C <entry>
=7C ...
=7C <link rel=3D=22self=22 href=3D=22/entries/665= =22 />
=7C <link rel=3D=22update-form=22 href=3D=22/entri= es/665/form=22 title=3D=22Update entry=22 />
=7C </entry&= gt;
=7C </feed>


Interesting thing is that a human ta= rgeted user agent could treat the form-links like HTML <img> links = and download the forms right away, embedding them in the UI directly (may= be hidden of course). A bit like a 'typed' AJAX request.

Cool stuff, actually.

Jan




Does it m= ake sense=3F

Yes, feels better. I'l= l let it circle through my head whether there is something else to it.

BTW, what would the reaction be if I POST to creat= e without form and the server does not 'allow' that=3F

Should this maybe be mentioned in the spec as a hint=3F Any better= /additional idea=3F

POST /feed
Content= -Type: application/order

<order/>

415 Unsupported Media Type
Link: </feed/for= m>; rel=3Dform; title=3DCreate new entry
Content-Type: text/= html

<html>
.... Use <a href=3D= =22/feed/form=22 title=3D=22Entry Creation =46orm=22>this form</a&g= t; to create a new entry.
</html>


Jan




Best regards,
<= div>Ioseb

On =46riday, May 11, 2012 at 1:06 PM, = Jan Algermissen wrote:

=

On May 11, 2012, at 10:57 AM, Ioseb Dzmanashvili= wrote:

Jan,<= /div>

I was thinking about your question regarding und= erstanding of meaning of *form*.

<= div>What is troubling me is that the meaning of 'form' depends on the mea= ning of 'collection' vs 'item'. Hence, Effectively the 'form' spec depend= s on some other spec that defines what 'collection' and 'item' means.

This in turn means that a client must understand th= e other specs (the media type of the context of the 'form' link) to under= stand which meaning of form is in effect.

I'd ra= ther define two new relations, or, make the form apply to both cases equa= lly and let the client figure out the submission target URI. (Who says th= e form must contain the target=3F)

That way 'for= m' would mean: 'here is a form that you can use to construct entry-submis= sions'. If you intend to edit an entry, use the form and if you intend to= create a new entry use that form too.

Send the = form to the appropriate target URI.

E.g.

GET /feed

200 Ok,
Li= nk: </feed/entry-form>; rel=3Dform

<fee= d>
<entry>
<link rel=3D=22edit=22 href=3D= =22/entries/665=22/>
</entry>
....
</feed>


Then
GET /feed/entry-form

200 Ok
Content-Type: application/myform

<form><= /div>
</form>


Then use = the form to construct the payload for the request

- to create a new entry and POST to /collection
or
= - to update an entry and PUT to e.g. /entries/665

makes sense=3F

Jan



=
I'm not 100% sure, though as far as it's possible to specify multipl= e link types as a value of the *rel* attribute and there are already regi= stered link relations of *collection* and *item* types as per R=46C6573 &= lt;http://tools.ietf.o= rg/html/rfc6573>, in order to signify meaning of the *form* link t= ype in resource representations it's possible to define links this way:

=3D=3D =46or collection =3D=3D
=7C =7B<= /div>
=7C =22links=22: =5B
=7C =7B
=7C =22href=22= : =22http://...=22,
=7C =22rel=22: =22collection form=22,
=
=7C =22prompt=22: =22Add new entry...=22
=7C =7D
=7C =5D
=7C =7D

=3D=3D =46or item =3D= =3D
=7C =7B
=7C =22links=22: =5B
=7C =7B
=7C =22href=22: =22http://...=22,
=7C =22rel=22: =22ite= m form=22,
=7C =22prompt=22: =22Edit entry...=22
=7C = =7D
=7C =5D
=7C =7D

Again, i= 'm not 100% sure, though i believe it's much clear.

<= div>P.S.
Best regards,
Ioseb
On =46riday, May 11,= 2012 at 1:13 AM, Jan Algermissen wrote:

Ioseb,

On May 8, 201= 2, at 10:21 AM, Ioseb Dzmanashvili wrote:

Hello Jan,

Thanks f= or the questions=21

You mention two link relations, but so far I can only see one ('form').= Which is the other one you are going to define=3F

I'm not sure regarding this, i never mentioned another li= nk relation type. I only created draft for form=3F

Your draft says: =22This specification defines a pa= ir of reciprocal link relation types=22 - I took 'pair' to mean 'two' , n= o=3F


Below is the simple example use case:

=3D= =3DRequest=3D=3D

=7C GET /users HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok
=
=7C Content-Type: application/vnd.collection.next+json
=7C= Content-Length: ...

=7C =7B=22collection=22: =7B=
=7C =22version=22: =221.0=22,
=7C =22href=22: =22http://service.org/users=22,
=7C =22items=22: =5B
=7C =7B
=7C =22href=22 := =22http://service.org/= users/john-doe=22,
=7C =22data=22 : =5B
=7C =7B=22= name=22: =22name=22, =22value=22: =22John Doe=22, =22prompt=22: =22=46ull= name=22=7D,
=7C =7B=22name=22: =22email=22, =22value=22: =22john=40doe.com=22, =22prompt=22: = =22Email=22=7D,
=7C =7B=22name=22: =22website=22, =22value=22: = =22=22, =22Prompt=22: =22Website=22=7D
=7C =5D,
=7C =22= links=22 : =5B
=7C =7B
=7C =22rel=22: =22form=22,

How do I know the meaning of 'form' here=3F Will = this add a new entry=3F



Jan


=7C =22type=22: =22application/vnd.collection.next+json=22
=7C =22prompt=22: =22Edit user=22
=7C =7D
=7C = =5D
=7C =7D,
=7C =7B...=7D,
=7C =7B...=7D,<= /div>
=7C =7B...=7D
=7C =5D
=7C =7D=7D
=

=3D=3DRequest: dereference the form resourc= e=3D=3D

=7C GET /users/john-doe/form HTTP/1.1
=7C Host: service.org
=7C Accept: application/vnd.collection.next+json

=3D=3DResponse=3D=3D

=7C HTTP/1.1 200 Ok<= /div>
=7C Content-Type: application/vnd.collection.next+json
=7C Content-Length: ...

=7C =7B=22collection=22= : =7B
=7C =22version=22: =221.0=22,
=7C
=7C= =22template=22: =7B
=7C =22method=22: =7B
=7C =22opt= ions=22: =5B
=7C =7B=22value=22: =22PUT=22, =22prompt=22: =22Re= place Entry=22=7D,
=7C =7B=22value=22: =22PATCH=22, =22prompt=22= : =22Modify Entry=22=7D
=7C =5D
=7C =7D,
=7C= =22data=22: =5B
=7C =7B=22name=22: =22first=5Fname=22, =22valu= e=22: =22John=22, =22prompt=22: =22=46irst name=22, =22required=22: true=7D= ,
=7C =7B=22name=22: =22last=5Fname=22, =22value=22: =22Doe=22,= =22prompt=22: =22Last name=22, =22required=22: true=7D,
=7C =7B= =22name=22: =22website=22, =22value=22: =22=22, =22prompt=22: =22Website=22= , =22type=22: =22url=22=7D
=7C =5D
=7C =7D
= =7C =7D=7D

=3D=3DRequest: submit the modified fo= rm element=3D=3D

=7C PATCH /users/john-doe HTTP/= 1.1
=7C Host: service.org
<= div>=7C Content-Length: ...

=7C =5D
=7C =7D=7D

Best regards,
Ioseb

---------- = =46orwarded message ----------
=46rom: Jan Algermissen <jan.algermissen=40nordsc.= com>
Cc:
Date: Mon, 7 May 2= 012 20:26:39 +0200
Subject: =5Blink-relations=5D Review of draf= t-ioseb-dzmanashvili-link-relation-00
Hi Ioseb,

<= /div>
I have just looked at your draft=5B1=5D and have a couple of qu= estions:

You mention two link relations, but so = far I can only see one ('form'). Which is the other one you are going to = define=3F

What is the exact purpose of the 'form= ' link relation=3F A=46AIU the client would do a GET on the link target a= nd interpret the response body as a form for adding entries.
Can you explain a bit, what the use cases are you have in mi= nd for this=3F Does it make sense to define such a relation in a general = manner=3F Why=3F Do you envision the specification of certain media types= for the forms to be returned=3F

Then you mentio= n the use of 'form' to edit single member entries. I find this to be prob= lematic because the meaning of the returned form (that is, the effect of = submitting the form, depends on the context in which the form has been fo= und. In one case it will be 'add a member' in the other it will be 'updat= e a resource'.

Have you considered using media t= ype semantics instead of link relations=3F It would in my opinion be bett= er to define a form media type and make the distinction between add and e= dit part of the type, not of the context in which a link is found.
<= div>
.....

Have you looked at Mark= Baker's RD=46 =46orms=5B2=5D=3F Maybe you can build on that approach for= your purpose=3F

Jan


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing lis= t


--
Ioseb Dzmana= shvili
Lead Architect
Picktek LLC
24b Khazb= egi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.56,= =46 (+1 202) 315.3934
code.ge
<= /div>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
link-relations mailing list
=20 =20 =20 =20

=20 =20 =20 =20 =20

--4fad97ca_49d1fea0_1745-- From ioseb.dzmanashvili@gmail.com Mon May 14 00:18:44 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C79E8013 for ; Mon, 14 May 2012 00:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRxrXCjprX+f for ; Mon, 14 May 2012 00:18:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 228BB9E8012 for ; Mon, 14 May 2012 00:18:42 -0700 (PDT) Received: by werf13 with SMTP id f13so2840181wer.31 for ; Mon, 14 May 2012 00:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=JYfqwiPOajLLfvHJk2y3OOEU0GlH7oaXyau4xnwRGxU=; b=BWDwNBbgsB/N+IyJP6Gb/dGlAwnUzQWYSPmrtRwi96cLrs1fqKvxW2RTowByacWZxj L0GsQ4fdFViRaDTRhXCeIXOCo+G7L7lWqW8S+bsSuydRdMHEkFWjTF2fFFCGHH93D6iO XDPKV/9+LBu77rsE2KMxjDNsoBHES84j/d9nDjfhmsYMfIAcUdI6fNnUGzIQs8VGXyxm sc2ipcyoHFx9MswUZfFRx3Mh7smUZIUZpDmqU8mNXlIIKeeHSgMFPcJnuFgukx6rpp7H IWAcqNW7MkLUY4wkbk+x2SKREwQOrTw0/0qnFC46bGWylSEFl2bZWf//Us2C8ZfaYh7K g4sA== Received: by 10.180.91.225 with SMTP id ch1mr3343296wib.18.1336979922021; Mon, 14 May 2012 00:18:42 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id ex2sm52312084wib.8.2012.05.14.00.18.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 00:18:41 -0700 (PDT) Date: Mon, 14 May 2012 11:36:23 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <3A0410376879473F9B505648A2C2E0C9@gmail.com> In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb0b5f7_71f32454_cd" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:18:44 -0000 --4fb0b5f7_71f32454_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. Reviews are highly appreciated. Thanks in advance! Best regards, Ioseb -- Ioseb Dzmanashvili Lead Architect Picktek LLC 24b Khazbegi ave. Tbilisi, 0177, Georgia T (+995 32) 39.58.56, F (+1 202) 315.3934 picktek.com code.ge github.com/ioseb twitter.com/iosebi --4fb0b5f7_71f32454_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello,

I've updated draft f= or =22create-form=22 and =22update-form=22 link relations. =46ixed severa= l minor issues and added table of contents. 

Reviews are highly appreciated. Thanks in advance=21

Best regards,
Ioseb

--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC<= /div>
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T = (+995 32) 39.58.56, =46 (+1 202) 315.3934
picktek.com
code.ge
github.com/ioseb
twitter.com/iosebi
=20 =20 =20 =20
=20

--4fb0b5f7_71f32454_cd-- From ioseb.dzmanashvili@gmail.com Mon May 14 00:26:24 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE9221F84DE for ; Mon, 14 May 2012 00:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdnMWeslkb17 for ; Mon, 14 May 2012 00:26:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 507B221F8468 for ; Mon, 14 May 2012 00:26:23 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3169671wgb.13 for ; Mon, 14 May 2012 00:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=zK64OhkDrYBPAkzyWYTR//7jBAUIqgpg3rXa5Zbm/84=; b=uAKDXZTdWcbrITy873nkjkTCxteTMqVrq94fC2toW7mjiNCK1+EAbQlj50NLbFmX6R 6KQBcbD4IYYtIH+27QyMTgXJMYtLO9LctVwywZe8bzKB131yAY5MitNCuWvpWmeSMSzQ 5bsMNw/pk3ua6E6LwEYvoqFhJC5WrGJZaPhQYlZegKiWakkPA+0EcsnMqqR2YNN5vEV5 bVxRjvacCeilutYXtWuGzCmTtUwRsCm8yYEbT3TKfWn2hBH7l0pJvhORP5dVkeUXkNr3 +PaiuKIxXgERP8MsCQl1pkgJ4KLoaZEmVRhskN2WnEz/vwg9dI7kpcI4DHtKEQDnCMgS T00Q== Received: by 10.180.102.101 with SMTP id fn5mr17214185wib.6.1336980382318; Mon, 14 May 2012 00:26:22 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id j3sm52380534wiw.1.2012.05.14.00.26.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 00:26:21 -0700 (PDT) Date: Mon, 14 May 2012 11:44:03 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> In-Reply-To: <3A0410376879473F9B505648A2C2E0C9@gmail.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb0b7c3_6ceaf087_cd" Cc: julian.reschke@gmx.de Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 07:26:24 -0000 --4fb0b7c3_6ceaf087_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: > Hello, > > I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. > > Reviews are highly appreciated. Thanks in advance! > > Best regards, > Ioseb > > -- > Ioseb Dzmanashvili > Lead Architect > Picktek LLC > 24b Khazbegi ave. > Tbilisi, 0177, Georgia > T (+995 32) 39.58.56, F (+1 202) 315.3934 > picktek.com (http://picktek.com) > code.ge > github.com/ioseb (http://github.com/ioseb) > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > --4fb0b7c3_6ceaf087_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =20

On Monday, May 14, 201= 2 at 11:36 AM, Ioseb Dzmanashvili wrote:

Hello,

I've updated draft f= or =22create-form=22 and =22update-form=22 link relations. =46ixed severa= l minor issues and added table of contents. 

Reviews are highly appreciated. Thanks in advance=21

Best regards,
Ioseb

--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC<= /div>
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T = (+995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20

=20 =20 =20 =20
=20

--4fb0b7c3_6ceaf087_cd-- From julian.reschke@gmx.de Tue May 15 00:45:35 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FFE21F863E for ; Tue, 15 May 2012 00:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.112 X-Spam-Level: X-Spam-Status: No, score=-103.112 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VWAsMjMHVpt for ; Tue, 15 May 2012 00:45:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8CCB221F84B2 for ; Tue, 15 May 2012 00:45:34 -0700 (PDT) Received: (qmail invoked by alias); 15 May 2012 07:45:31 -0000 Received: from p5DD978E6.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.120.230] by mail.gmx.net (mp024) with SMTP; 15 May 2012 09:45:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+h/95pdsah73QPdHMqOTT3nezpLlYeDkQnUc8F6b jXduI21WU0xx47 Message-ID: <4FB20999.1030506@gmx.de> Date: Tue, 15 May 2012 09:45:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: link-relations@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [link-relations] new Designated Expert Jan Algermissen X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 07:45:35 -0000 Friends of Web Linking, I assumed there'd be some kind of official announcement but apparently there won't one... The Link Relations registry started with a promise of fast processing and three Designated Experts. Processing hasn't always been fast as it should, and we lost one of the Experts a few months ago. Thus it's great that Jan Algermissen volunteered to take over the position and will help us over here in the future. Welcome, Jan! From jan.algermissen@nordsc.com Tue May 15 00:55:50 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EC921F8936 for ; Tue, 15 May 2012 00:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz40YkCdTiFe for ; Tue, 15 May 2012 00:55:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6B921F878E for ; Tue, 15 May 2012 00:55:49 -0700 (PDT) Received: from [10.164.229.51] (tmo-110-115.customers.d1-online.com [80.187.110.115]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Ly7gf-1S12Dm2BSH-0166mg; Tue, 15 May 2012 09:55:48 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Jan Algermissen In-Reply-To: <4FB20999.1030506@gmx.de> Date: Tue, 15 May 2012 09:55:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FB20999.1030506@gmx.de> To: link-relations@ietf.org X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:D/wEhBWOWsmSehsPwIkHSj6tXD11QRaOJKNJqvs+MSN Z1mldTii7j3xUt4CYPnU+r6TltY6z+F1nkLseX6+uMObJTFJL7 MHace2OyznnMIAmtl/uZCSkYwDpE8NbmKcD2+4g798jjXvfpoT l4bR0sM+B3t5OkvE10r10F1NsUG2K21cLX/Jc9ip1Ei91oFgD+ MOW3Rnss5f4Asud59cUdZ/t+yg8AI1w31JG5Pwa/k8o+Z14MKP S9GBtM21XIqaxOug78cpN1sATa71bc0e+oLvzEfiwT6EfUfYwS sQS4fABa8i7JpZ/S3/H2Gt72E017KvbxnCyHZ5w31C+FSdO88L UPQ1sYx/hWsDTSbbmbSaEYwE0dTq2D97lOkVcNsFQ3XodEVP5B Apjz3UehpkrAw== Subject: Re: [link-relations] new Designated Expert Jan Algermissen X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 07:55:50 -0000 On May 15, 2012, at 9:45 AM, Julian Reschke wrote: > Friends of Web Linking, >=20 > I assumed there'd be some kind of official announcement but apparently = there won't one... >=20 > The Link Relations registry started with a promise of fast processing = and three Designated Experts. Processing hasn't always been fast as it = should, and we lost one of the Experts a few months ago. >=20 > Thus it's great that Jan Algermissen volunteered to take over the = position and will help us over here in the future. >=20 > Welcome, Jan! Thanks Julian! Looking forward to hopefully make a contribution to the Web. Keep the specs coming :-) Cheers, Jan > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations From ioseb.dzmanashvili@gmail.com Tue May 15 01:42:56 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB021F88BB for ; Tue, 15 May 2012 01:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs5v-wEitGLv for ; Tue, 15 May 2012 01:42:55 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4221F88B4 for ; Tue, 15 May 2012 01:42:55 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3989053wgb.13 for ; Tue, 15 May 2012 01:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:x-mailer:mime-version :content-type; bh=OlvcpHFh/Q4WDPHyPHi99nwCCfo8dPjEtTySmfh2io4=; b=AtY6b4ebBEe5QGzHx6kP+SHxAQvquOEsWP9zh2orYt6zY9m5IvgvSzTC7Lok5nRYBO Qcd8SQEL3bT2edJom6GLHVYJnNCj6Xop2QaacoJ1wvpFqgHIrAtrrkhmmQ/maMyxScaU 5yJ76y3K/JzwYydkTdW7QqrN2aSuj0CS8pGumwyL9P8WROd9jRg+xlpNTjb4CehclkOt PTTfCOJ/x1EyGgrFvLSbh4/UuDhkKcbGCYrfTalAGg4ow1xzy1yoFVYM09BGZFoFLWFF 6f62AE05UNb1waXSBGkfdBfDfwi2Q3PIKBnrJzmLBZd9zgoy1/GgjvUsMbrP5CCcSLaJ 38ug== Received: by 10.180.74.7 with SMTP id p7mr8887210wiv.20.1337071374280; Tue, 15 May 2012 01:42:54 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id z3sm41982726wix.0.2012.05.15.01.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 01:42:53 -0700 (PDT) Date: Tue, 15 May 2012 13:00:36 +0400 From: Ioseb Dzmanashvili To: jan.algermissen@nordsc.com Message-ID: <52FF769E923E4AB7971C6B9D3147E342@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb21b34_14330624_cd" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" , link-relations@ietf.org Subject: Re: [link-relations] new Designated Expert Jan Algermissen X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 08:42:56 -0000 --4fb21b34_14330624_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Congrats Jan!!! B-) Best Regards, ioseb --4fb21b34_14330624_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Congrats Jan=21=21=21 B-)

B= est Regards,
ioseb
--4fb21b34_14330624_cd-- From jan.algermissen@nordsc.com Tue May 15 02:31:22 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0221F8954 for ; Tue, 15 May 2012 02:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8-xu+Ilg6Fv for ; Tue, 15 May 2012 02:31:21 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id D429621F8903 for ; Tue, 15 May 2012 02:31:20 -0700 (PDT) Received: from [10.90.128.109] ([87.253.171.200]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LlEeM-1Rvict0lBW-00b195; Tue, 15 May 2012 11:31:18 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> Date: Tue, 15 May 2012 11:31:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:hlsgUk0PGweyTF2gVDQGqX60oYXYdvWeH0GcgYyBCo3 DJkYJKpFuChECQWPXD93SzN9zg8I48rBdpcCLgl4ZPtgpr5f2Z 9gsk75GtnaqrVvGsmVNRIzdF3NcPYdIphOlaBNhWPFskyOMuxa bzPC5Q/91c4cNHzTG1W1iXkGyKIShh1PEF8cB9xNua9ksSnEVU +mCFD6rSRtmVIgE5q5wpOwzJQofkg2j22zMOhgvLrL5x8r6V9z +CjsaljdiHn9ngDbUW3Tz/atuIW2ZfjSd8jZ8enDc5I3Zp2cA7 BzpgwBF4a6AZeQ5UFIKOYrjuQXjmNNe1GRdsNCeg1SaCS1KClp vRVMUP1hD1oR5D7fZwOcJ6OYFhLcSuUoTE5nasE01KD48aFByP YHeNkkX5IRmEw== Cc: julian.reschke@gmx.de, link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 09:31:22 -0000 Review of = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 Abstract "between any kind of entry and a pre-populated input form for modifying = the associated entry" s/pre-populated input// Introduction "between any kind of entry and a pre-populated input form for modifying = the associated entry" s/pre-populated input// Consider dropping the second paragraph or rewrite so that it does not = imply that sometimes link relations would be tied to a media type (which = they must never be). 3.1.1 Do not constrain the method use. It is a runtime choice the client = makes. If the form media type includes method information the client = will (usually) be programmed to use that , otherwise, your draft must = not constrain method use. As a client I can try create resources using PUT as often as I desire - = the server will tell me at runtime whether it worked. If you feel you must say something here, make it a hint along the lines = of "If the client has no particular information about what method to use = a POST would be the best guess" Not sure about the SHOULD in the 415 example - using SHOULD here makes = your draft depend normatively on the 415 spec and the fact that 415 is = the code to use for the described case is inherent in the nature of 415. = No need to repeat that here. Maybe emphasize that it is an example. 3.1.2 see 3.1.1 comments :-) 4.2. consider s/update-form/edit-form/ ? I think 4.1 and 4.2 need slight rephrasing, but I am not an experience = I-D writer. If I think of something I'll let you know. Jan On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: > Updated link: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: >=20 >> Hello, >>=20 >> I've updated draft for "create-form" and "update-form" link = relations. Fixed several minor issues and added table of contents.=20 >>=20 >> Reviews are highly appreciated. Thanks in advance! >>=20 >> Best regards, >> Ioseb >>=20 >> -- >> Ioseb Dzmanashvili >> Lead Architect >> Picktek LLC >> 24b Khazbegi ave. >> Tbilisi, 0177, Georgia >> T (+995 32) 39.58.56, F (+1 202) 315.3934 >> picktek.com >> code.ge >> github.com/ioseb >> twitter.com/iosebi >>=20 >=20 From ioseb.dzmanashvili@gmail.com Tue May 15 03:41:10 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9828521F8874 for ; Tue, 15 May 2012 03:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHHSI+10ywHQ for ; Tue, 15 May 2012 03:41:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7521F886E for ; Tue, 15 May 2012 03:41:08 -0700 (PDT) Received: by werf13 with SMTP id f13so3908223wer.31 for ; Tue, 15 May 2012 03:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=aGlRNS0bUx+8hKxwqPyNtJODb1p4NCgC1BwUnJt3XKE=; b=kEVj1GRvuNzSpqY1LGFbmNPvUFNeeSSQB1eO42bzfGjeFgU74aGv0oBtYia8ZnHFnO /cjCm8Il9yN2oLOszo/nOgXzU7YtrhBGz0TK1X19VtnYfbSrf2Z9qUvpwqEGhEt0ujro l/GI091ngOnOomeVPcP4z751K3xXE2a3XwsdHyOfkMKN74raeyLBMlMvcWY+d/ZLT7ZH Qfq0U2TCRhSTbXzbd5JWmIwu6pSMCikOYm61kb2WIfPUA4ZxPDHZSjr5mFlQeEBzdqvM HGd+6pF/Zoi0dk75JNy7lLbUkPaN8gPQySBCESQ0XHu0nJ/VyQQSxsCQW6g50ZqaZj1H jqnA== Received: by 10.180.75.241 with SMTP id f17mr7036674wiw.11.1337078467885; Tue, 15 May 2012 03:41:07 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id e6sm41583747wix.8.2012.05.15.03.41.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 03:41:06 -0700 (PDT) Date: Tue, 15 May 2012 14:58:50 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> In-Reply-To: <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb236ea_2708c9af_cd" Cc: julian.reschke@gmx.de, link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 10:41:10 -0000 --4fb236ea_2708c9af_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, Thanks for review! Here are changes i made(i didn't submit draft yet): > Abstract > "between any kind of entry and a pre-populated input form for modifying the associated entry" > s/pre-populated input// > Introduction > "between any kind of entry and a pre-populated input form for modifying the associated entry" s/pre-populated input// > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). Changed this: "This specification defines link relation types which may be used to express the relationships between a resource and an input form for constructing entry submissions, or between any kind of entry and a pre-populated input form for modifying the associated entry." to this: "This specification defines link relation types which may be used to express the relationships between a resource and an input form for constructing data submissions." > 3.1.1 > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > 3.1.2 > see 3.1.1 comments :-) Chanted this: "If the media type, used for constructing submission form, supports target URI information provisioning, explicitly specified target URI MUST be used by clients for submitting the populated form. Context URI MUST be used otherwise." to this: "Target URI specified in the form representation MUST be used for submit requests. Context URI MUST be used otherwise." -------- Changed this: "If the media type, used for constructing submission form, supports method information provisioning, explicitly specified request method MUST be used by clients for submitting the populated form. HTTP's PUT method MUST be used otherwise." to this: "Request method specified in the form representation MUST be used for submit requests. HTTP's POST method MAY be used otherwise." --------- Changed this: "If the media type, used for constructing submission form, supports content encoding information provisioning, form data MUST be encoded according to the explicitly specified encoding type before submission. The media type used for constructing form MUST be used otherwise." to this: "Content type specified in the form representation MUST be used for submit requests. The content type of the form representation MUST be used otherwise." ---------------- in 3.2. changed this: "When included in a resource which represents particular entry, the "update-form" link relation identifies a target resource that represents a pre-populated form for editing associated entry." to this: "When included in a resource, the "edit-form" link relation identifies a target resource that represents the form for editing associated resource" > 4.2. consider s/update-form/edit-form/ ? Done > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. in 4.1 changed this: "The target IRI points to a resource that is a representation of a valid submission form for the data described by the form resource" to this: "The target IRI points to a resource that is a representation of a valid submission form." ---------- in 4.2 changed this: "The target IRI points to a resource that is a representation of a valid pre-populated submission form for editing the data represented by the associated entry." to this: "The target IRI points to a resource that is a representation of a valid submission form for editing associated resource." Best regards, Ioseb On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: > Review of http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > Abstract > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > s/pre-populated input// > > > Introduction > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > s/pre-populated input// > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > 3.1.1 > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > 3.1.2 > see 3.1.1 comments :-) > > > 4.2. consider s/update-form/edit-form/ ? > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > Jan > > > > On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: > > > Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: > > > > > Hello, > > > > > > I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. > > > > > > Reviews are highly appreciated. Thanks in advance! > > > > > > Best regards, > > > Ioseb > > > > > > -- > > > Ioseb Dzmanashvili > > > Lead Architect > > > Picktek LLC > > > 24b Khazbegi ave. > > > Tbilisi, 0177, Georgia > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > picktek.com (http://picktek.com) > > > code.ge > > > github.com/ioseb (http://github.com/ioseb) > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > --4fb236ea_2708c9af_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 

Thanks for re= view=21

Here are changes i made(i didn't submit = draft yet):

> Abstract
> =22= between any kind of entry and a pre-populated input form for modifying th= e associated entry=22
> s/pre-populated input//
&g= t; Introduction
> =22between any kind of entry and a pre-pop= ulated input form for modifying the associated entry=22 s/pre-populated i= nput//
> Consider dropping the second paragraph or rewrite s= o that it does not imply that sometimes link relations would be tied to a= media type (which they must never be).

Changed = this: =22This specification defines link relation types which may be used=
   to express the relationships between a resource a= nd an input form for
   constructing entry submission= s, or between any kind of entry and a
   pre-populate= d input form for modifying the associated entry.=22
  &nbs= p;
to this: =22This specification defines link relation types w= hich may be used
      to express the relationsh= ips between a resource and an input form for
    &nbs= p; constructing data submissions.=22


<= div>> 3.1.1
> Do not constrain the method use. It is a ru= ntime choice the client makes. If the form media type includes method inf= ormation the client will (usually) be programmed to use that , otherwise,= your draft must not constrain method use.
> As a client I c= an try create resources using PUT as often as I desire - the server will = tell me at runtime whether it worked.
> If you feel you must= say something here, make it a hint along the lines of =22If the client h= as no particular information about what method to use a POST would be the= best guess=22
> Not sure about the SHOULD in the 415 exampl= e - using SHOULD here makes your draft depend normatively on the 415 spec= and the fact that 415 is the code to use for the described case is inher= ent in the nature of 415. No need to repeat that here. Maybe emphasize th= at it is an example.
> 3.1.2
> see 3.1.1 commen= ts :-)

Chanted this: =22If the media type, used = for constructing submission form, supports
   target = URI information provisioning, explicitly specified target URI
&= nbsp;  MUST be used by clients for submitting the populated form. &n= bsp;Context
   URI MUST be used otherwise.=22
   
to this: =22Target URI specified in the form r= epresentation MUST be used for
      submit requ= ests.  Context URI MUST be used otherwise.=22

--------

Changed this: =22If the media type, = used for constructing submission form, supports
   me= thod information provisioning, explicitly specified request method
<= div>   MUST be used by clients for submitting the populated for= m.  HTTP's
   PUT method MUST be used otherwise.= =22
   
to this: =22Request method specifie= d in the form representation MUST be used for
    &nb= sp; submit requests.  HTTP's POST method MAY be used otherwise.=22

---------

Changed this: = =22If the media type, used for constructing submission form, supports
   content encoding information provisioning, form data = MUST be encoded
   according to the explicitly specif= ied encoding type before
   submission.  The med= ia type used for constructing form MUST be used
   ot= herwise.=22
   
to this: =22Content type sp= ecified in the form representation MUST be used for
  &nbs= p;   submit requests.  The content type of the form representat= ion MUST be
      used otherwise.=22
<= br>
----------------

in 3.2. changed t= his: =22When included in a resource which represents particular entry, th= e
         =22update-form=22 link rela= tion identifies a target resource that
      &nb= sp;  represents a pre-populated form for editing associated entry.=22=

to this: =22When included in a resource, the =22= edit-form=22 link relation
     identifies a tar= get resource that represents the form for editing associated resource=22<= /div>

> 4.2. consider s/update-form/edit-form/ =3F<= /div>

Done

> I think 4.1 a= nd 4.2 need slight rephrasing, but I am not an experience I-D writer. If = I think of something I'll let you know.

in 4.1 c= hanged this: =22The target IRI points to a resource that is a representat= ion of a
      valid submission form for the dat= a described by the form resource=22
      <= /div>
to this: =22The target IRI points to a resource that is a repre= sentation of a
            valid = submission form.=22

----------

in 4.2 changed this: =22The target IRI points to a resource that = is a representation of a
      valid pre-populat= ed submission form for editing the data
      re= presented by the associated entry.=22
      = ;
to this: =22The target IRI points to a resource that is a rep= resentation of a
            vali= d submission form for editing associated resource.=22

Best regards,
Ioseb

=20

On Tuesday, May 15, 20= 12 at 1:31 PM, Jan Algermissen wrote:

=
Abstract

=22between any kind of e= ntry and a pre-populated input form for modifying the associated entry=22=
s/pre-populated input//


Introduction

=22between any kind of entry and = a pre-populated input form for modifying the associated entry=22
s/pre-populated input//

Consider dropping the = second paragraph or rewrite so that it does not imply that sometimes link= relations would be tied to a media type (which they must never be).

3.1.1

Do not constrain the = method use. It is a runtime choice the client makes. If the form media ty= pe includes method information the client will (usually) be programmed to= use that , otherwise, your draft must not constrain method use.

As a client I can try create resources using PUT as ofte= n as I desire - the server will tell me at runtime whether it worked.

If you feel you must say something here, make it a = hint along the lines of =22If the client has no particular information ab= out what method to use a POST would be the best guess=22

Not sure about the SHOULD in the 415 example - using SHOULD here= makes your draft depend normatively on the 415 spec and the fact that 41= 5 is the code to use for the described case is inherent in the nature of = 415. No need to repeat that here. Maybe emphasize that it is an example.<= /div>

3.1.2
see 3.1.1 comments :-)


4.2. consider s/update-form/edit-form/ =3F=

I think 4.1 and 4.2 need slight rephrasing, but= I am not an experience I-D writer. If I think of something I'll let you = know.

Jan



On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote:




On Monday, May 14, 2012 at 11:36 AM,= Ioseb Dzmanashvili wrote:

Hello,

I've updated draft for =22c= reate-form=22 and =22update-form=22 link relations. =46ixed several minor= issues and added table of contents.

Reviews ar= e highly appreciated. Thanks in advance=21

Best = regards,
Ioseb

--
Ioseb Dzma= nashvili
Lead Architect
Picktek LLC
24b Kha= zbegi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.5= 6, =46 (+1 202) 315.3934
code.ge
 =20 =20 =20 =20
=20

--4fb236ea_2708c9af_cd-- From jan.algermissen@nordsc.com Tue May 15 06:43:42 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774AC21F89C2 for ; Tue, 15 May 2012 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR-T-qow9AYq for ; Tue, 15 May 2012 06:43:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2808621F8930 for ; Tue, 15 May 2012 06:43:41 -0700 (PDT) Received: from [31.252.17.84] (tmo-103-27.customers.d1-online.com [80.187.103.27]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lh5vD-1Rirwk2Hpf-00oUeC; Tue, 15 May 2012 15:43:38 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> Date: Tue, 15 May 2012 15:43:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:woECQvygWJdchFQDMmNaL+TNqU2HQTA3zk58jJ9vALP 7rJa/fRA9OMmATsi5CRgsT9aLW7KbO8v2XNcPbOxMQDdz0TdIf 2kJZ4k+egRDrVmYdRQ3HWcoakmSghmcGkOGGSVOTNImE+ChN+m yaVL/YOlTgUX2i7yS5iWlOowcGGIuut0hHfZl6Id9AV1W2Xegh clyWf0fEB6zNN82O/xYRp5a0pe8uwunTck0X5RPhfYXEMY3Cz3 jc8QZe61jkMChDvePeNH7qRJIeCB9eiz++GC7TjL4Cj1evU8WK TO1phhdymYaIBYBPSNe85NSluRCILSr/ILUy980k1aK//kjcht NvHu6WE8Cb02F7F6+xz/ztytNPEltLn5jbHvjaJzMjpECzJw6l mtE3+HZZzSZ0w== Cc: julian.reschke@gmx.de, link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 13:43:42 -0000 On May 15, 2012, at 12:58 PM, Ioseb Dzmanashvili wrote: > Hi Jan,=20 >=20 > Thanks for review! >=20 > Here are changes i made(i didn't submit draft yet): >=20 > > Abstract > > "between any kind of entry and a pre-populated input form for = modifying the associated entry" > > s/pre-populated input// > > Introduction > > "between any kind of entry and a pre-populated input form for = modifying the associated entry" s/pre-populated input// > > Consider dropping the second paragraph or rewrite so that it does = not imply that sometimes link relations would be tied to a media type = (which they must never be). >=20 > Changed this: "This specification defines link relation types which = may be used > to express the relationships between a resource and an input form = for > constructing entry submissions, or between any kind of entry and a > pre-populated input form for modifying the associated entry." > =20 > to this: "This specification defines link relation types which may be = used > to express the relationships between a resource and an input = form for > constructing data submissions." Sounds good. >=20 >=20 > > 3.1.1 > > Do not constrain the method use. It is a runtime choice the client = makes. If the form media type includes method information the client = will (usually) be programmed to use that , otherwise, your draft must = not constrain method use. > > As a client I can try create resources using PUT as often as I = desire - the server will tell me at runtime whether it worked. > > If you feel you must say something here, make it a hint along the = lines of "If the client has no particular information about what method = to use a POST would be the best guess" > > Not sure about the SHOULD in the 415 example - using SHOULD here = makes your draft depend normatively on the 415 spec and the fact that = 415 is the code to use for the described case is inherent in the nature = of 415. No need to repeat that here. Maybe emphasize that it is an = example. > > 3.1.2 > > see 3.1.1 comments :-) >=20 > Chanted this: "If the media type, used for constructing submission = form, supports > target URI information provisioning, explicitly specified target = URI > MUST be used by clients for submitting the populated form. Context > URI MUST be used otherwise." > =20 > to this: "Target URI specified in the form representation MUST be used = for > submit requests. Context URI MUST be used otherwise." Agreed. >=20 > -------- >=20 > Changed this: "If the media type, used for constructing submission = form, supports > method information provisioning, explicitly specified request = method > MUST be used by clients for submitting the populated form. HTTP's > PUT method MUST be used otherwise." > =20 > to this: "Request method specified in the form representation MUST be = used for > submit requests. HTTP's POST method MAY be used otherwise." >=20 Ok. > --------- >=20 > Changed this: "If the media type, used for constructing submission = form, supports > content encoding information provisioning, form data MUST be = encoded > according to the explicitly specified encoding type before > submission. The media type used for constructing form MUST be used > otherwise." > =20 > to this: "Content type specified in the form representation MUST be = used for > submit requests. The content type of the form representation = MUST be > used otherwise." This sounds wrong to me. I get your point I think, but the question of = what to send if the form does not tell you seems orthogonal to your = draft to me. Getting a second opinion here might be a good idea. >=20 > ---------------- >=20 > in 3.2. changed this: "When included in a resource which represents = particular entry, the > "update-form" link relation identifies a target resource that > represents a pre-populated form for editing associated = entry." >=20 > to this: "When included in a resource, the "edit-form" link relation > identifies a target resource that represents the form for editing = associated resource" >=20 > > 4.2. consider s/update-form/edit-form/ ? >=20 > Done >=20 > > I think 4.1 and 4.2 need slight rephrasing, but I am not an = experience I-D writer. If I think of something I'll let you know. >=20 > in 4.1 changed this: "The target IRI points to a resource that is a = representation of a > valid submission form for the data described by the form = resource" > =20 > to this: "The target IRI points to a resource that is a representation = of a > valid submission form." 'representation' here sounds (to me) misleading. What about 'points to a = resource where a creation form can be obtained'? (Though I dislike 'creation form' here) Anyhow - maybe yours is just good enough... Thanks for the quick responses. Jan >=20 > ---------- >=20 > in 4.2 changed this: "The target IRI points to a resource that is a = representation of a > valid pre-populated submission form for editing the data > represented by the associated entry." > =20 > to this: "The target IRI points to a resource that is a representation = of a > valid submission form for editing associated resource." >=20 > Best regards, > Ioseb >=20 > On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: >=20 >> Review of = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 >>=20 >> Abstract >>=20 >> "between any kind of entry and a pre-populated input form for = modifying the associated entry" >> s/pre-populated input// >>=20 >>=20 >> Introduction >>=20 >> "between any kind of entry and a pre-populated input form for = modifying the associated entry" >> s/pre-populated input// >>=20 >> Consider dropping the second paragraph or rewrite so that it does not = imply that sometimes link relations would be tied to a media type (which = they must never be). >>=20 >> 3.1.1 >>=20 >> Do not constrain the method use. It is a runtime choice the client = makes. If the form media type includes method information the client = will (usually) be programmed to use that , otherwise, your draft must = not constrain method use. >>=20 >> As a client I can try create resources using PUT as often as I desire = - the server will tell me at runtime whether it worked. >>=20 >> If you feel you must say something here, make it a hint along the = lines of "If the client has no particular information about what method = to use a POST would be the best guess" >>=20 >> Not sure about the SHOULD in the 415 example - using SHOULD here = makes your draft depend normatively on the 415 spec and the fact that = 415 is the code to use for the described case is inherent in the nature = of 415. No need to repeat that here. Maybe emphasize that it is an = example. >>=20 >> 3.1.2 >> see 3.1.1 comments :-) >>=20 >>=20 >> 4.2. consider s/update-form/edit-form/ ? >>=20 >> I think 4.1 and 4.2 need slight rephrasing, but I am not an = experience I-D writer. If I think of something I'll let you know. >>=20 >> Jan >>=20 >>=20 >>=20 >> On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: >>=20 >>> Updated link: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 >>=20 >>=20 >>=20 >>> On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: >>>=20 >>>> Hello, >>>>=20 >>>> I've updated draft for "create-form" and "update-form" link = relations. Fixed several minor issues and added table of contents. >>>>=20 >>>> Reviews are highly appreciated. Thanks in advance! >>>>=20 >>>> Best regards, >>>> Ioseb >>>>=20 >>>> -- >>>> Ioseb Dzmanashvili >>>> Lead Architect >>>> Picktek LLC >>>> 24b Khazbegi ave. >>>> Tbilisi, 0177, Georgia >>>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>>> picktek.com >>>> code.ge >>>> github.com/ioseb >>>> twitter.com/iosebi >=20 From ioseb.dzmanashvili@gmail.com Tue May 15 07:15:42 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDDB21F8724 for ; Tue, 15 May 2012 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4s8-pVWiKYW for ; Tue, 15 May 2012 07:15:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E07D821F86C3 for ; Tue, 15 May 2012 07:15:35 -0700 (PDT) Received: by bkty8 with SMTP id y8so5683541bkt.31 for ; Tue, 15 May 2012 07:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=W6v84jsNfhV9gctA6wTcAea5TT1eWJYxnn31p9sW83c=; b=zXtS2t54rxRvwWegbprSiahJEBGliA8IXaQEM2G6foTzz5pmP9Ab6aIK6dWS4jKEHy hkVT2ktZH8jnG8S7bfAJnAhB9n+t1DTG0S9g9by3zgVaIwt0cenSk4kbVCfZnWVSc6sH 36JeFTlHBizOCcP70DlbiM7qLLh/0uMkmJ6SqGCr9zoK+R5v7enjo6A0sKctGJLRSBb3 gwp5azYsRAGgxpKoysNFwMnQmtfmwM/Anj79qBFvN/KUSZw33oawZqg3ySf2wA4VEtYj eMoQfjXv6wTOIJ3xVi9AdmnhnhF8O+dLwfAMtcHQe3xV8OOpk2AVlqTafEMgxzWZIuGr WEOg== Received: by 10.204.155.137 with SMTP id s9mr4723091bkw.103.1337091334465; Tue, 15 May 2012 07:15:34 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id e20sm42080854bkv.10.2012.05.15.07.15.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 May 2012 07:15:32 -0700 (PDT) Date: Tue, 15 May 2012 18:33:16 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <97C779D535114EA8BC3C5351C0DF289D@gmail.com> In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb2692c_6fde8af6_cd" Cc: julian.reschke@gmx.de, link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:15:42 -0000 --4fb2692c_6fde8af6_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, Thank you very much! >> to this: "Content type specified in the form representation MUST be used for >> submit requests. The content type of the form representation MUST be >> used otherwise." > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > Getting a second opinion here might be a good idea. Maybe this? "A content type specified in the form representation MUST be used for submitting requests, or otherwise, a content type defined in the media type specification of a form MUST be used" For example form HTML forms, for data submission default content type is "application/x-www-form-urlencoded" but in some cases "multipart/form-data" can be indicated explicitly. Both cases are defined by media type spec itself. >> "The target IRI points to a resource that is a representation of a >> valid submission form." > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > (Though I dislike 'creation form' here) What about this? "The target IRI points to a resource where a submission form can be obtained" What do you think? ioseb On Tuesday, May 15, 2012 at 5:43 PM, Jan Algermissen wrote: > > On May 15, 2012, at 12:58 PM, Ioseb Dzmanashvili wrote: > > > Hi Jan, > > > > Thanks for review! > > > > Here are changes i made(i didn't submit draft yet): > > > > > Abstract > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > s/pre-populated input// > > > Introduction > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" s/pre-populated input// > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > > > > Changed this: "This specification defines link relation types which may be used > > to express the relationships between a resource and an input form for > > constructing entry submissions, or between any kind of entry and a > > pre-populated input form for modifying the associated entry." > > > > to this: "This specification defines link relation types which may be used > > to express the relationships between a resource and an input form for > > constructing data submissions." > > > > > Sounds good. > > > > > > > > 3.1.1 > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > 3.1.2 > > > see 3.1.1 comments :-) > > > > > > > > > Chanted this: "If the media type, used for constructing submission form, supports > > target URI information provisioning, explicitly specified target URI > > MUST be used by clients for submitting the populated form. Context > > URI MUST be used otherwise." > > > > to this: "Target URI specified in the form representation MUST be used for > > submit requests. Context URI MUST be used otherwise." > > > > > Agreed. > > > > > -------- > > > > Changed this: "If the media type, used for constructing submission form, supports > > method information provisioning, explicitly specified request method > > MUST be used by clients for submitting the populated form. HTTP's > > PUT method MUST be used otherwise." > > > > to this: "Request method specified in the form representation MUST be used for > > submit requests. HTTP's POST method MAY be used otherwise." > > > > > Ok. > > > --------- > > > > Changed this: "If the media type, used for constructing submission form, supports > > content encoding information provisioning, form data MUST be encoded > > according to the explicitly specified encoding type before > > submission. The media type used for constructing form MUST be used > > otherwise." > > > > to this: "Content type specified in the form representation MUST be used for > > submit requests. The content type of the form representation MUST be > > used otherwise." > > > > > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > > Getting a second opinion here might be a good idea. > > > > > > ---------------- > > > > in 3.2. changed this: "When included in a resource which represents particular entry, the > > "update-form" link relation identifies a target resource that > > represents a pre-populated form for editing associated entry." > > > > to this: "When included in a resource, the "edit-form" link relation > > identifies a target resource that represents the form for editing associated resource" > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > Done > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > in 4.1 changed this: "The target IRI points to a resource that is a representation of a > > valid submission form for the data described by the form resource" > > > > to this: "The target IRI points to a resource that is a representation of a > > valid submission form." > > > > > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > (Though I dislike 'creation form' here) > > Anyhow - maybe yours is just good enough... > > Thanks for the quick responses. > > Jan > > > > > > ---------- > > > > in 4.2 changed this: "The target IRI points to a resource that is a representation of a > > valid pre-populated submission form for editing the data > > represented by the associated entry." > > > > to this: "The target IRI points to a resource that is a representation of a > > valid submission form for editing associated resource." > > > > Best regards, > > Ioseb > > > > On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: > > > > > Review of http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > Abstract > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > s/pre-populated input// > > > > > > > > > Introduction > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > s/pre-populated input// > > > > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > 3.1.1 > > > > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > > > > 3.1.2 > > > see 3.1.1 comments :-) > > > > > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > > > Jan > > > > > > > > > > > > On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: > > > > > > > Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > > > > > > > > On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > Hello, > > > > > > > > > > I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. > > > > > > > > > > Reviews are highly appreciated. Thanks in advance! > > > > > > > > > > Best regards, > > > > > Ioseb > > > > > > > > > > -- > > > > > Ioseb Dzmanashvili > > > > > Lead Architect > > > > > Picktek LLC > > > > > 24b Khazbegi ave. > > > > > Tbilisi, 0177, Georgia > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > picktek.com (http://picktek.com) > > > > > code.ge > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > --4fb2692c_6fde8af6_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 

Thank you ver= y much=21

>> to this: =22Content type= specified in the form representation MUST be used for
>>= submit requests. The content type of the form representation MUST be
>> used otherwise.=22

> This sou= nds wrong to me. I get your point I think, but the question of what to se= nd if the form does not tell you seems orthogonal to your draft to me.
> Getting a second opinion here might be a good idea.

Maybe this=3F 

=22A conten= t type specified in the form representation MUST be used for submitting r= equests, or otherwise, a content type defined in the media type specifica= tion of a form MUST be used=22

=46or example for= m HTML forms, for data submission default content type is =22application/= x-www-form-urlencoded=22 but in some cases =22multipart/form-data=22 can = be indicated explicitly. Both cases are defined by media type spec itself= . 

>> =22The target IRI points to a r= esource that is a representation of a
>> valid submission= form.=22

> 'representation' here sounds (to = me) misleading. What about 'points to a resource where a creation form ca= n be obtained'=3F
> (Though I dislike 'creation form' here)<= /div>

What about this=3F 
=22The target= IRI points to a resource where a submission form can be obtained=22

What do you think=3F 

ioseb
=20

On Tuesday, May 15, 20= 12 at 5:43 PM, Jan Algermissen wrote:


On May 15, 2012, = at 12:58 PM, Ioseb Dzmanashvili wrote:

Hi Jan,

Thanks for re= view=21

Here are changes i made(i didn't submit = draft yet):

A= bstract
=22between any kind of entry and a pre-populated input = form for modifying the associated entry=22
s/pre-populated inpu= t//
Introduction
=22between any kind of entry and a p= re-populated input form for modifying the associated entry=22 s/pre-popul= ated input//
Consider dropping the second paragraph or rewrite = so that it does not imply that sometimes link relations would be tied to = a media type (which they must never be).
Changed this: =22This specification defines link relation typ= es which may be used
to express the relationships between a = resource and an input form for
constructing entry submission= s, or between any kind of entry and a
pre-populated input fo= rm for modifying the associated entry.=22
to this= : =22This specification defines link relation types which may be used
to express the relationships between a resource and an input= form for
constructing data submissions.=22

Sounds good.



3.1.1
Do not constrain the method use. It = is a runtime choice the client makes. If the form media type includes met= hod information the client will (usually) be programmed to use that , oth= erwise, your draft must not constrain method use.
As a client I= can try create resources using PUT as often as I desire - the server wil= l tell me at runtime whether it worked.
If you feel you must sa= y something here, make it a hint along the lines of =22If the client has = no particular information about what method to use a POST would be the be= st guess=22
Not sure about the SHOULD in the 415 example - usin= g SHOULD here makes your draft depend normatively on the 415 spec and the= fact that 415 is the code to use for the described case is inherent in t= he nature of 415. No need to repeat that here. Maybe emphasize that it is= an example.
3.1.2
see 3.1.1 comments :-)
=

Chanted this: =22If the media type, used= for constructing submission form, supports
target URI infor= mation provisioning, explicitly specified target URI
MUST be= used by clients for submitting the populated form. Context
= URI MUST be used otherwise.=22
to this: =22Targe= t URI specified in the form representation MUST be used for
= submit requests. Context URI MUST be used otherwise.=22

Agreed.


--------

Changed this: =22If the media type, used for constructing submission fo= rm, supports
method information provisioning, explicitly spe= cified request method
MUST be used by clients for submitting= the populated form. HTTP's
PUT method MUST be used otherwi= se.=22
to this: =22Request method specified in th= e form representation MUST be used for
submit requests. = HTTP's POST method MAY be used otherwise.=22

Ok.

---------

Changed this: =22If the media t= ype, used for constructing submission form, supports
content= encoding information provisioning, form data MUST be encoded
= according to the explicitly specified encoding type before
= submission. The media type used for constructing form MUST be used
otherwise.=22
to this: =22Content type s= pecified in the form representation MUST be used for
subm= it requests. The content type of the form representation MUST be
used otherwise.=22

T= his sounds wrong to me. I get your point I think, but the question of wha= t to send if the form does not tell you seems orthogonal to your draft to= me.

Getting a second opinion here might be a go= od idea.



----------------

in 3.= 2. changed this: =22When included in a resource which represents particul= ar entry, the
=22update-form=22 link relation identifi= es a target resource that
represents a pre-populated f= orm for editing associated entry.=22

to this: =22= When included in a resource, the =22edit-form=22 link relation
= identifies a target resource that represents the form for editing as= sociated resource=22

4.2. consider s/update-form/edit-form/ =3F

=
Done

I = think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D = writer. If I think of something I'll let you know.

in 4.1 changed this: =22The target IRI points to a resour= ce that is a representation of a
valid submission form fo= r the data described by the form resource=22
t= o this: =22The target IRI points to a resource that is a representation o= f a
valid submission form.=22

'representation' here sounds (to me) misleading. W= hat about 'points to a resource where a creation form can be obtained'=3F=
(Though I dislike 'creation form' here)

Anyhow - maybe yours is just good enough...

T= hanks for the quick responses.

Jan


<= div>----------

in 4.2 changed this: =22The targe= t IRI points to a resource that is a representation of a
= valid pre-populated submission form for editing the data
= represented by the associated entry.=22
to thi= s: =22The target IRI points to a resource that is a representation of a
valid submission form for editing associated resourc= e.=22

Best regards,
Ioseb
On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote:<= /div>


Abstract

=22be= tween any kind of entry and a pre-populated input form for modifying the = associated entry=22
s/pre-populated input//


Introduction

=22between any= kind of entry and a pre-populated input form for modifying the associate= d entry=22
s/pre-populated input//

Con= sider dropping the second paragraph or rewrite so that it does not imply = that sometimes link relations would be tied to a media type (which they m= ust never be).

3.1.1

Do= not constrain the method use. It is a runtime choice the client makes. I= f the form media type includes method information the client will (usuall= y) be programmed to use that , otherwise, your draft must not constrain m= ethod use.

As a client I can try create resource= s using PUT as often as I desire - the server will tell me at runtime whe= ther it worked.

If you feel you must say somethi= ng here, make it a hint along the lines of =22If the client has no partic= ular information about what method to use a POST would be the best guess=22=

Not sure about the SHOULD in the 415 example - = using SHOULD here makes your draft depend normatively on the 415 spec and= the fact that 415 is the code to use for the described case is inherent = in the nature of 415. No need to repeat that here. Maybe emphasize that i= t is an example.

3.1.2
see 3.1.1 comme= nts :-)


4.2. consider s/update-fo= rm/edit-form/ =3F

I think 4.1 and 4.2 need sligh= t rephrasing, but I am not an experience I-D writer. If I think of someth= ing I'll let you know.

Jan

<= div>

On May 14, 2012, at 9:44 AM, Ioseb Dzma= nashvili wrote:



<= div>
On Monday, May 14, = 2012 at 11:36 AM, Ioseb Dzmanashvili wrote:

Hello,

I've updat= ed draft for =22create-form=22 and =22update-form=22 link relations. =46i= xed several minor issues and added table of contents.

Reviews are highly appreciated. Thanks in advance=21

=
Best regards,
Ioseb

--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T (= +995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20 =20

--4fb2692c_6fde8af6_cd-- From ioseb.dzmanashvili@gmail.com Wed May 16 02:12:26 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1942321F85F0 for ; Wed, 16 May 2012 02:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZbxVwqTC8wW for ; Wed, 16 May 2012 02:12:20 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6B21F8726 for ; Wed, 16 May 2012 02:12:18 -0700 (PDT) Received: by werf13 with SMTP id f13so368276wer.31 for ; Wed, 16 May 2012 02:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=YgPupKTw80L7LI0j5PiqnsMd3J4fkoJBL8p4gE6g2mg=; b=0g628V2dogvQ1wlMxL2XEHhYBGv6u4CMLTvSbMzlBQTU/QxFBBU+fi0Z7uyJ1YlKqj mghy1e6x11lbJ/4JjxT45eXsPxKf5nSx9U9yQcONJWcjAsauUl6NGhR+7qBhg7ic+ROh dXsJzwCC+MWy3hgn7QcA69zbFrYBMaENAcubdvA1L12SOAJZTkwmhLQq43cX43iBLNl9 vYlPEHz/e2Q+3ucPTo33COG/dQtYQ0cywVSbQlZIsvZbZS2Uw3jeJHVaYwKQNOhZbGbZ Ar1a3x1PQR5bp4TmLgRauQ48wHNN2E+/mAK6qZz+gK7bPjbP/g87PYOXi8Vm91jPycP7 7xoA== Received: by 10.180.86.197 with SMTP id r5mr5951030wiz.21.1337159537798; Wed, 16 May 2012 02:12:17 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id h8sm7228132wix.4.2012.05.16.02.12.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 02:12:16 -0700 (PDT) Date: Wed, 16 May 2012 13:30:01 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: In-Reply-To: <97C779D535114EA8BC3C5351C0DF289D@gmail.com> References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> <97C779D535114EA8BC3C5351C0DF289D@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb37399_20f4bdad_cd" Cc: julian.reschke@gmx.de, link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-06 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 09:12:26 -0000 --4fb37399_20f4bdad_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, I updated the draft: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-06 All discussed changes are there. Additionally, as you suggested i moved error handling example to separate sub section, removed "SHOULD" and changed wording from "service SHOULD respond" to "service may respond"; Best regards, Ioseb On Tuesday, May 15, 2012 at 6:33 PM, Ioseb Dzmanashvili wrote: > Hi Jan, > > Thank you very much! > > >> to this: "Content type specified in the form representation MUST be used for > >> submit requests. The content type of the form representation MUST be > >> used otherwise." > > > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > > Getting a second opinion here might be a good idea. > > Maybe this? > > "A content type specified in the form representation MUST be used for submitting requests, or otherwise, a content type defined in the media type specification of a form MUST be used" > > For example form HTML forms, for data submission default content type is "application/x-www-form-urlencoded" but in some cases "multipart/form-data" can be indicated explicitly. Both cases are defined by media type spec itself. > > >> "The target IRI points to a resource that is a representation of a > >> valid submission form." > > > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > > (Though I dislike 'creation form' here) > > What about this? > "The target IRI points to a resource where a submission form can be obtained" > > > What do you think? > > ioseb > > On Tuesday, May 15, 2012 at 5:43 PM, Jan Algermissen wrote: > > > > > On May 15, 2012, at 12:58 PM, Ioseb Dzmanashvili wrote: > > > > > Hi Jan, > > > > > > Thanks for review! > > > > > > Here are changes i made(i didn't submit draft yet): > > > > > > > Abstract > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > s/pre-populated input// > > > > Introduction > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" s/pre-populated input// > > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > > > > > > > > Changed this: "This specification defines link relation types which may be used > > > to express the relationships between a resource and an input form for > > > constructing entry submissions, or between any kind of entry and a > > > pre-populated input form for modifying the associated entry." > > > > > > to this: "This specification defines link relation types which may be used > > > to express the relationships between a resource and an input form for > > > constructing data submissions." > > > > > > > > > Sounds good. > > > > > > > > > > > > 3.1.1 > > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > > 3.1.2 > > > > see 3.1.1 comments :-) > > > > > > > > > > > > > Chanted this: "If the media type, used for constructing submission form, supports > > > target URI information provisioning, explicitly specified target URI > > > MUST be used by clients for submitting the populated form. Context > > > URI MUST be used otherwise." > > > > > > to this: "Target URI specified in the form representation MUST be used for > > > submit requests. Context URI MUST be used otherwise." > > > > > > > > > Agreed. > > > > > > > > -------- > > > > > > Changed this: "If the media type, used for constructing submission form, supports > > > method information provisioning, explicitly specified request method > > > MUST be used by clients for submitting the populated form. HTTP's > > > PUT method MUST be used otherwise." > > > > > > to this: "Request method specified in the form representation MUST be used for > > > submit requests. HTTP's POST method MAY be used otherwise." > > > > > > > > > Ok. > > > > > --------- > > > > > > Changed this: "If the media type, used for constructing submission form, supports > > > content encoding information provisioning, form data MUST be encoded > > > according to the explicitly specified encoding type before > > > submission. The media type used for constructing form MUST be used > > > otherwise." > > > > > > to this: "Content type specified in the form representation MUST be used for > > > submit requests. The content type of the form representation MUST be > > > used otherwise." > > > > > > > > > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > > > > Getting a second opinion here might be a good idea. > > > > > > > > > > ---------------- > > > > > > in 3.2. changed this: "When included in a resource which represents particular entry, the > > > "update-form" link relation identifies a target resource that > > > represents a pre-populated form for editing associated entry." > > > > > > to this: "When included in a resource, the "edit-form" link relation > > > identifies a target resource that represents the form for editing associated resource" > > > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > > > Done > > > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > > > in 4.1 changed this: "The target IRI points to a resource that is a representation of a > > > valid submission form for the data described by the form resource" > > > > > > to this: "The target IRI points to a resource that is a representation of a > > > valid submission form." > > > > > > > > > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > > (Though I dislike 'creation form' here) > > > > Anyhow - maybe yours is just good enough... > > > > Thanks for the quick responses. > > > > Jan > > > > > > > > > > ---------- > > > > > > in 4.2 changed this: "The target IRI points to a resource that is a representation of a > > > valid pre-populated submission form for editing the data > > > represented by the associated entry." > > > > > > to this: "The target IRI points to a resource that is a representation of a > > > valid submission form for editing associated resource." > > > > > > Best regards, > > > Ioseb > > > > > > On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: > > > > > > > Review of http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > > > Abstract > > > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > s/pre-populated input// > > > > > > > > > > > > Introduction > > > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > s/pre-populated input// > > > > > > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > > > 3.1.1 > > > > > > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > > > > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > > > > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > > > > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > > > > > > 3.1.2 > > > > see 3.1.1 comments :-) > > > > > > > > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > > > > > Jan > > > > > > > > > > > > > > > > On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > > > > > > > > > > > > On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. > > > > > > > > > > > > Reviews are highly appreciated. Thanks in advance! > > > > > > > > > > > > Best regards, > > > > > > Ioseb > > > > > > > > > > > > -- > > > > > > Ioseb Dzmanashvili > > > > > > Lead Architect > > > > > > Picktek LLC > > > > > > 24b Khazbegi ave. > > > > > > Tbilisi, 0177, Georgia > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > picktek.com (http://picktek.com) > > > > > > code.ge > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --4fb37399_20f4bdad_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan, 


All discussed changes a= re there. Additionally, as you suggested i moved error handling example t= o separate sub section, removed =22SHOULD=22 and changed wording from =22= service SHOULD respond=22 to =22service may  respond=22;
<= div>
Best regards,
Ioseb
=20

On Tuesday, May 15, 20= 12 at 6:33 PM, Ioseb Dzmanashvili wrote:

Hi Jan, 

Thank you ver= y much=21

>> to this: =22Content type= specified in the form representation MUST be used for
>>= submit requests. The content type of the form representation MUST be
>> used otherwise.=22

> This sou= nds wrong to me. I get your point I think, but the question of what to se= nd if the form does not tell you seems orthogonal to your draft to me.
> Getting a second opinion here might be a good idea.

Maybe this=3F 

=22A conten= t type specified in the form representation MUST be used for submitting r= equests, or otherwise, a content type defined in the media type specifica= tion of a form MUST be used=22

=46or example for= m HTML forms, for data submission default content type is =22application/= x-www-form-urlencoded=22 but in some cases =22multipart/form-data=22 can = be indicated explicitly. Both cases are defined by media type spec itself= . 

>> =22The target IRI points to a r= esource that is a representation of a
>> valid submission= form.=22

> 'representation' here sounds (to = me) misleading. What about 'points to a resource where a creation form ca= n be obtained'=3F
> (Though I dislike 'creation form' here)<= /div>

What about this=3F 
=22The target= IRI points to a resource where a submission form can be obtained=22

What do you think=3F 

ioseb
=20

On Tuesday, May 15, 20= 12 at 5:43 PM, Jan Algermissen wrote:


On May 15, 2012, = at 12:58 PM, Ioseb Dzmanashvili wrote:

Hi Jan,

Thanks for re= view=21

Here are changes i made(i didn't submit = draft yet):

A= bstract
=22between any kind of entry and a pre-populated input = form for modifying the associated entry=22
s/pre-populated inpu= t//
Introduction
=22between any kind of entry and a p= re-populated input form for modifying the associated entry=22 s/pre-popul= ated input//
Consider dropping the second paragraph or rewrite = so that it does not imply that sometimes link relations would be tied to = a media type (which they must never be).
Changed this: =22This specification defines link relation typ= es which may be used
to express the relationships between a = resource and an input form for
constructing entry submission= s, or between any kind of entry and a
pre-populated input fo= rm for modifying the associated entry.=22
to this= : =22This specification defines link relation types which may be used
to express the relationships between a resource and an input= form for
constructing data submissions.=22

Sounds good.



3.1.1
Do not constrain the method use. It = is a runtime choice the client makes. If the form media type includes met= hod information the client will (usually) be programmed to use that , oth= erwise, your draft must not constrain method use.
As a client I= can try create resources using PUT as often as I desire - the server wil= l tell me at runtime whether it worked.
If you feel you must sa= y something here, make it a hint along the lines of =22If the client has = no particular information about what method to use a POST would be the be= st guess=22
Not sure about the SHOULD in the 415 example - usin= g SHOULD here makes your draft depend normatively on the 415 spec and the= fact that 415 is the code to use for the described case is inherent in t= he nature of 415. No need to repeat that here. Maybe emphasize that it is= an example.
3.1.2
see 3.1.1 comments :-)
=

Chanted this: =22If the media type, used= for constructing submission form, supports
target URI infor= mation provisioning, explicitly specified target URI
MUST be= used by clients for submitting the populated form. Context
= URI MUST be used otherwise.=22
to this: =22Targe= t URI specified in the form representation MUST be used for
= submit requests. Context URI MUST be used otherwise.=22

Agreed.


--------

Changed this: =22If the media type, used for constructing submission fo= rm, supports
method information provisioning, explicitly spe= cified request method
MUST be used by clients for submitting= the populated form. HTTP's
PUT method MUST be used otherwi= se.=22
to this: =22Request method specified in th= e form representation MUST be used for
submit requests. = HTTP's POST method MAY be used otherwise.=22

Ok.

---------

Changed this: =22If the media t= ype, used for constructing submission form, supports
content= encoding information provisioning, form data MUST be encoded
= according to the explicitly specified encoding type before
= submission. The media type used for constructing form MUST be used
otherwise.=22
to this: =22Content type s= pecified in the form representation MUST be used for
subm= it requests. The content type of the form representation MUST be
used otherwise.=22

T= his sounds wrong to me. I get your point I think, but the question of wha= t to send if the form does not tell you seems orthogonal to your draft to= me.

Getting a second opinion here might be a go= od idea.



----------------

in 3.= 2. changed this: =22When included in a resource which represents particul= ar entry, the
=22update-form=22 link relation identifi= es a target resource that
represents a pre-populated f= orm for editing associated entry.=22

to this: =22= When included in a resource, the =22edit-form=22 link relation
= identifies a target resource that represents the form for editing as= sociated resource=22

4.2. consider s/update-form/edit-form/ =3F

=
Done

I = think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D = writer. If I think of something I'll let you know.

in 4.1 changed this: =22The target IRI points to a resour= ce that is a representation of a
valid submission form fo= r the data described by the form resource=22
t= o this: =22The target IRI points to a resource that is a representation o= f a
valid submission form.=22

'representation' here sounds (to me) misleading. W= hat about 'points to a resource where a creation form can be obtained'=3F=
(Though I dislike 'creation form' here)

Anyhow - maybe yours is just good enough...

T= hanks for the quick responses.

Jan


<= div>----------

in 4.2 changed this: =22The targe= t IRI points to a resource that is a representation of a
= valid pre-populated submission form for editing the data
= represented by the associated entry.=22
to thi= s: =22The target IRI points to a resource that is a representation of a
valid submission form for editing associated resourc= e.=22

Best regards,
Ioseb
On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote:<= /div>


Abstract

=22be= tween any kind of entry and a pre-populated input form for modifying the = associated entry=22
s/pre-populated input//


Introduction

=22between any= kind of entry and a pre-populated input form for modifying the associate= d entry=22
s/pre-populated input//

Con= sider dropping the second paragraph or rewrite so that it does not imply = that sometimes link relations would be tied to a media type (which they m= ust never be).

3.1.1

Do= not constrain the method use. It is a runtime choice the client makes. I= f the form media type includes method information the client will (usuall= y) be programmed to use that , otherwise, your draft must not constrain m= ethod use.

As a client I can try create resource= s using PUT as often as I desire - the server will tell me at runtime whe= ther it worked.

If you feel you must say somethi= ng here, make it a hint along the lines of =22If the client has no partic= ular information about what method to use a POST would be the best guess=22=

Not sure about the SHOULD in the 415 example - = using SHOULD here makes your draft depend normatively on the 415 spec and= the fact that 415 is the code to use for the described case is inherent = in the nature of 415. No need to repeat that here. Maybe emphasize that i= t is an example.

3.1.2
see 3.1.1 comme= nts :-)


4.2. consider s/update-fo= rm/edit-form/ =3F

I think 4.1 and 4.2 need sligh= t rephrasing, but I am not an experience I-D writer. If I think of someth= ing I'll let you know.

Jan

<= div>

On May 14, 2012, at 9:44 AM, Ioseb Dzma= nashvili wrote:



<= div>
On Monday, May 14, = 2012 at 11:36 AM, Ioseb Dzmanashvili wrote:

Hello,

I've updat= ed draft for =22create-form=22 and =22update-form=22 link relations. =46i= xed several minor issues and added table of contents.

Reviews are highly appreciated. Thanks in advance=21

=
Best regards,
Ioseb

--
Ioseb Dzmanashvili
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T (= +995 32) 39.58.56, =46 (+1 202) 315.3934
code.ge
=20 =20 =20 =20

=20 =20 =20 =20 =20

--4fb37399_20f4bdad_cd-- From jan.algermissen@nordsc.com Wed May 16 03:15:12 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA97421F8664 for ; Wed, 16 May 2012 03:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy3peSZ1BWmE for ; Wed, 16 May 2012 03:15:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id AE53121F8661 for ; Wed, 16 May 2012 03:15:07 -0700 (PDT) Received: from [10.90.131.143] ([87.253.171.222]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MSGxn-1Sef570aeh-00TAMS; Wed, 16 May 2012 12:15:06 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jan Algermissen In-Reply-To: <97C779D535114EA8BC3C5351C0DF289D@gmail.com> Date: Wed, 16 May 2012 08:55:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> <97C779D535114EA8BC3C5351C0DF289D@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:EAjuVPzjja/Yg7XdmAsVIfHqU7RZxmR50pfWNoX4l+Q Z6QrhZvJMASNflvMYjfU3PxUls6oGeFAzHUs2UUfgIilwKRaop Hqk+P4yoaPgQus+xkP8s2tR4vN3UC7niV8quNKspDORcuu4eLF tWIB0G45dHILhQLxG1r5F+VEMKr0CHooQzqgZPpMJpYmV7VLSG fUvPr7K1qfAsMmjL1kwLo69UTTmE+4UiWM1wVMwEDr3mf37APr I3Y6sVRG+AED8hIZyzgaidw9N65SsVf19ZZlooGFM9lOeQgqBA PQIJuSqD7OyjU+VRU52LKPOKvjDijvIrw9d1TeNSvpGmW9ULgX pgSlu1GhnXzj5sb0zuNz1N3ut/WDhI7uro1lSucuE5NjKjfhJ3 nDskm7TpAWEjQ== Cc: link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 10:15:12 -0000 On May 15, 2012, at 4:33 PM, Ioseb Dzmanashvili wrote: > Hi Jan,=20 >=20 > Thank you very much! >=20 > >> to this: "Content type specified in the form representation MUST be = used for > >> submit requests. The content type of the form representation MUST = be > >> used otherwise." >=20 > > This sounds wrong to me. I get your point I think, but the question = of what to send if the form does not tell you seems orthogonal to your = draft to me. > > Getting a second opinion here might be a good idea. >=20 > Maybe this?=20 >=20 > "A content type specified in the form representation MUST be used for = submitting requests, or otherwise, a content type defined in the media = type specification of a form MUST be used" Why do you need to say this at all? IWO, what is missing if you drop it? >=20 > For example form HTML forms, for data submission default content type = is "application/x-www-form-urlencoded" but in some cases = "multipart/form-data" can be indicated explicitly. Both cases are = defined by media type spec itself. Right - and they are defined *there* - why do you want to say in your = draft that one must obey other drafts? >=20 > >> "The target IRI points to a resource that is a representation of a > >> valid submission form." >=20 > > 'representation' here sounds (to me) misleading. What about 'points = to a resource where a creation form can be obtained'? > > (Though I dislike 'creation form' here) >=20 > What about this?=20 > "The target IRI points to a resource where a submission form can be = obtained" Yes, I guess that works. (Admittedly, I am still unsure how appropriate this language-tweaking is = for I-Ds. I guess one could go on forever fiddling with the words. I = lack a quality indicator, telling me that 'we are done' :-) @Mark, Julian ... if you read this, drop me note what balance makes = sense. Jan=20 >=20 > What do you think?=20 >=20 > ioseb > On Tuesday, May 15, 2012 at 5:43 PM, Jan Algermissen wrote: >=20 >>=20 >> On May 15, 2012, at 12:58 PM, Ioseb Dzmanashvili wrote: >>=20 >>> Hi Jan, >>>=20 >>> Thanks for review! >>>=20 >>> Here are changes i made(i didn't submit draft yet): >>>=20 >>>> Abstract >>>> "between any kind of entry and a pre-populated input form for = modifying the associated entry" >>>> s/pre-populated input// >>>> Introduction >>>> "between any kind of entry and a pre-populated input form for = modifying the associated entry" s/pre-populated input// >>>> Consider dropping the second paragraph or rewrite so that it does = not imply that sometimes link relations would be tied to a media type = (which they must never be). >>>=20 >>> Changed this: "This specification defines link relation types which = may be used >>> to express the relationships between a resource and an input form = for >>> constructing entry submissions, or between any kind of entry and a >>> pre-populated input form for modifying the associated entry." >>> to this: "This specification defines link relation types which may = be used >>> to express the relationships between a resource and an input form = for >>> constructing data submissions." >>=20 >> Sounds good. >>=20 >>>=20 >>>=20 >>>> 3.1.1 >>>> Do not constrain the method use. It is a runtime choice the client = makes. If the form media type includes method information the client = will (usually) be programmed to use that , otherwise, your draft must = not constrain method use. >>>> As a client I can try create resources using PUT as often as I = desire - the server will tell me at runtime whether it worked. >>>> If you feel you must say something here, make it a hint along the = lines of "If the client has no particular information about what method = to use a POST would be the best guess" >>>> Not sure about the SHOULD in the 415 example - using SHOULD here = makes your draft depend normatively on the 415 spec and the fact that = 415 is the code to use for the described case is inherent in the nature = of 415. No need to repeat that here. Maybe emphasize that it is an = example. >>>> 3.1.2 >>>> see 3.1.1 comments :-) >>>=20 >>> Chanted this: "If the media type, used for constructing submission = form, supports >>> target URI information provisioning, explicitly specified target URI >>> MUST be used by clients for submitting the populated form. Context >>> URI MUST be used otherwise." >>> to this: "Target URI specified in the form representation MUST be = used for >>> submit requests. Context URI MUST be used otherwise." >>=20 >> Agreed. >>=20 >>>=20 >>> -------- >>>=20 >>> Changed this: "If the media type, used for constructing submission = form, supports >>> method information provisioning, explicitly specified request method >>> MUST be used by clients for submitting the populated form. HTTP's >>> PUT method MUST be used otherwise." >>> to this: "Request method specified in the form representation MUST = be used for >>> submit requests. HTTP's POST method MAY be used otherwise." >>=20 >> Ok. >>=20 >>> --------- >>>=20 >>> Changed this: "If the media type, used for constructing submission = form, supports >>> content encoding information provisioning, form data MUST be encoded >>> according to the explicitly specified encoding type before >>> submission. The media type used for constructing form MUST be used >>> otherwise." >>> to this: "Content type specified in the form representation MUST be = used for >>> submit requests. The content type of the form representation MUST be >>> used otherwise." >>=20 >> This sounds wrong to me. I get your point I think, but the question = of what to send if the form does not tell you seems orthogonal to your = draft to me. >>=20 >> Getting a second opinion here might be a good idea. >>=20 >>=20 >>>=20 >>> ---------------- >>>=20 >>> in 3.2. changed this: "When included in a resource which represents = particular entry, the >>> "update-form" link relation identifies a target resource that >>> represents a pre-populated form for editing associated entry." >>>=20 >>> to this: "When included in a resource, the "edit-form" link relation >>> identifies a target resource that represents the form for editing = associated resource" >>>=20 >>>> 4.2. consider s/update-form/edit-form/ ? >>>=20 >>> Done >>>=20 >>>> I think 4.1 and 4.2 need slight rephrasing, but I am not an = experience I-D writer. If I think of something I'll let you know. >>>=20 >>> in 4.1 changed this: "The target IRI points to a resource that is a = representation of a >>> valid submission form for the data described by the form resource" >>> to this: "The target IRI points to a resource that is a = representation of a >>> valid submission form." >>=20 >> 'representation' here sounds (to me) misleading. What about 'points = to a resource where a creation form can be obtained'? >> (Though I dislike 'creation form' here) >>=20 >> Anyhow - maybe yours is just good enough... >>=20 >> Thanks for the quick responses. >>=20 >> Jan >>=20 >>=20 >>>=20 >>> ---------- >>>=20 >>> in 4.2 changed this: "The target IRI points to a resource that is a = representation of a >>> valid pre-populated submission form for editing the data >>> represented by the associated entry." >>> to this: "The target IRI points to a resource that is a = representation of a >>> valid submission form for editing associated resource." >>>=20 >>> Best regards, >>> Ioseb >>>=20 >>> On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: >>>=20 >>>> Review of = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 >>>>=20 >>>> Abstract >>>>=20 >>>> "between any kind of entry and a pre-populated input form for = modifying the associated entry" >>>> s/pre-populated input// >>>>=20 >>>>=20 >>>> Introduction >>>>=20 >>>> "between any kind of entry and a pre-populated input form for = modifying the associated entry" >>>> s/pre-populated input// >>>>=20 >>>> Consider dropping the second paragraph or rewrite so that it does = not imply that sometimes link relations would be tied to a media type = (which they must never be). >>>>=20 >>>> 3.1.1 >>>>=20 >>>> Do not constrain the method use. It is a runtime choice the client = makes. If the form media type includes method information the client = will (usually) be programmed to use that , otherwise, your draft must = not constrain method use. >>>>=20 >>>> As a client I can try create resources using PUT as often as I = desire - the server will tell me at runtime whether it worked. >>>>=20 >>>> If you feel you must say something here, make it a hint along the = lines of "If the client has no particular information about what method = to use a POST would be the best guess" >>>>=20 >>>> Not sure about the SHOULD in the 415 example - using SHOULD here = makes your draft depend normatively on the 415 spec and the fact that = 415 is the code to use for the described case is inherent in the nature = of 415. No need to repeat that here. Maybe emphasize that it is an = example. >>>>=20 >>>> 3.1.2 >>>> see 3.1.1 comments :-) >>>>=20 >>>>=20 >>>> 4.2. consider s/update-form/edit-form/ ? >>>>=20 >>>> I think 4.1 and 4.2 need slight rephrasing, but I am not an = experience I-D writer. If I think of something I'll let you know. >>>>=20 >>>> Jan >>>>=20 >>>>=20 >>>>=20 >>>> On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: >>>>=20 >>>>> Updated link: = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 >>>>=20 >>>>=20 >>>>=20 >>>>> On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I've updated draft for "create-form" and "update-form" link = relations. Fixed several minor issues and added table of contents. >>>>>>=20 >>>>>> Reviews are highly appreciated. Thanks in advance! >>>>>>=20 >>>>>> Best regards, >>>>>> Ioseb >>>>>>=20 >>>>>> -- >>>>>> Ioseb Dzmanashvili >>>>>> Lead Architect >>>>>> Picktek LLC >>>>>> 24b Khazbegi ave. >>>>>> Tbilisi, 0177, Georgia >>>>>> T (+995 32) 39.58.56, F (+1 202) 315.3934 >>>>>> picktek.com >>>>>> code.ge >>>>>> github.com/ioseb >>>>>> twitter.com/iosebi >=20 From ioseb.dzmanashvili@gmail.com Wed May 16 03:23:50 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8140521F86A7 for ; Wed, 16 May 2012 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCt9TgVLlTVL for ; Wed, 16 May 2012 03:23:45 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4A8C21F8555 for ; Wed, 16 May 2012 03:23:40 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so3214347wib.13 for ; Wed, 16 May 2012 03:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=blWpH2LSkvd3f0J5z0kEh93Ri5W4c9rfQKlyc3ZsA6I=; b=rZAiY5ouAVavOnP3+HM4xxgpzVz6dvzVpmJuerB3tvaoRNlVX2i8pcZKSMI8tQRM+c HX2DnXC4O73GcoNHgnwXLKHPYvPT7t+H/rC9bHPBIRd/unpN3CS428TntzXs03vE90SE p7BoCLGXAZDziDmklCXgrsvdGc9aIGAzkNQ8T6oC0eRtQUAB93pHJrNo9vod3NnCRvCX Q/MRHfUWnaMIlhcZ4+Z72RLqR06nFvWraN+5y4Kwx/EfcvMpm79p9iTf5M8ZlXFLd3Um inB7dendjgT0bB8PfsoH3wtQJfI4TVDsR7wgGSoQKjyAiRyN+3tzCXWvg5T1YPtsugfO s0CA== Received: by 10.180.105.194 with SMTP id go2mr6528832wib.22.1337163820040; Wed, 16 May 2012 03:23:40 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id h8sm7753429wix.4.2012.05.16.03.23.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 May 2012 03:23:39 -0700 (PDT) Date: Wed, 16 May 2012 14:41:24 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <1AB2D18449E145E7831C9B8E2B331B45@gmail.com> In-Reply-To: References: <7FAAFE24-4EBD-41A3-8300-1F35D6AB94AC@nordsc.com> <89B439CF-2937-455A-9D6A-B3A09D44424C@nordsc.com> <060632DA3A334DE1A9FAD8E935D09933@gmail.com> <0202A28A7800405D975F120E0C93D635@gmail.com> <3A0410376879473F9B505648A2C2E0C9@gmail.com> <65F5DCE271C84F09A1AE1519A268C8B3@gmail.com> <777FE46B-562A-4153-AF50-166B8BD452F8@nordsc.com> <1A65802E17C24C3A9AB0F1CBF8CEC98A@gmail.com> <97C779D535114EA8BC3C5351C0DF289D@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fb38454_53e31a24_cd" Cc: link-relations@ietf.org Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-05 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 10:23:50 -0000 --4fb38454_53e31a24_cd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you very much Jan! > Why do you need to say this at all? IWO, what is missing if you drop it? > Right - and they are defined *there* - why do you want to say in your draft that one must obey other drafts? I'd be rather happy do drop this at all. I'm just not sure what exactly needs to be included in the draft and what is not(obviously this is due to my lack of experience in writing drafts) ;) > (Admittedly, I am still unsure how appropriate this language-tweaking is for I-Ds. I guess one could go on forever fiddling with the words. I lack a quality indicator, telling me that 'we are done' :-) > @Mark, Julian ... if you read this, drop me note what balance makes sense. That would be great! Best regards, Ioseb On Wednesday, May 16, 2012 at 10:55 AM, Jan Algermissen wrote: > > On May 15, 2012, at 4:33 PM, Ioseb Dzmanashvili wrote: > > > Hi Jan, > > > > Thank you very much! > > > > > > to this: "Content type specified in the form representation MUST be used for > > > > submit requests. The content type of the form representation MUST be > > > > used otherwise." > > > > > > > > > > > > > > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > > > Getting a second opinion here might be a good idea. > > > > > > > > > Maybe this? > > > > "A content type specified in the form representation MUST be used for submitting requests, or otherwise, a content type defined in the media type specification of a form MUST be used" > > Why do you need to say this at all? IWO, what is missing if you drop it? > > > > > For example form HTML forms, for data submission default content type is "application/x-www-form-urlencoded" but in some cases "multipart/form-data" can be indicated explicitly. Both cases are defined by media type spec itself. > > Right - and they are defined *there* - why do you want to say in your draft that one must obey other drafts? > > > > > > "The target IRI points to a resource that is a representation of a > > > > valid submission form." > > > > > > > > > > > > > > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > > > (Though I dislike 'creation form' here) > > > > > > > > > What about this? > > "The target IRI points to a resource where a submission form can be obtained" > > > > > Yes, I guess that works. > > (Admittedly, I am still unsure how appropriate this language-tweaking is for I-Ds. I guess one could go on forever fiddling with the words. I lack a quality indicator, telling me that 'we are done' :-) > > @Mark, Julian ... if you read this, drop me note what balance makes sense. > > Jan > > > > > > What do you think? > > > > ioseb > > On Tuesday, May 15, 2012 at 5:43 PM, Jan Algermissen wrote: > > > > > > > > On May 15, 2012, at 12:58 PM, Ioseb Dzmanashvili wrote: > > > > > > > Hi Jan, > > > > > > > > Thanks for review! > > > > > > > > Here are changes i made(i didn't submit draft yet): > > > > > > > > > Abstract > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > > s/pre-populated input// > > > > > Introduction > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" s/pre-populated input// > > > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > > > > > > > > > > > > Changed this: "This specification defines link relation types which may be used > > > > to express the relationships between a resource and an input form for > > > > constructing entry submissions, or between any kind of entry and a > > > > pre-populated input form for modifying the associated entry." > > > > to this: "This specification defines link relation types which may be used > > > > to express the relationships between a resource and an input form for > > > > constructing data submissions." > > > > > > > > > > > > > Sounds good. > > > > > > > > > > > > > > > > 3.1.1 > > > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > > > 3.1.2 > > > > > see 3.1.1 comments :-) > > > > > > > > > > > > > > > > > Chanted this: "If the media type, used for constructing submission form, supports > > > > target URI information provisioning, explicitly specified target URI > > > > MUST be used by clients for submitting the populated form. Context > > > > URI MUST be used otherwise." > > > > to this: "Target URI specified in the form representation MUST be used for > > > > submit requests. Context URI MUST be used otherwise." > > > > > > > > > > > > > Agreed. > > > > > > > > > > > -------- > > > > > > > > Changed this: "If the media type, used for constructing submission form, supports > > > > method information provisioning, explicitly specified request method > > > > MUST be used by clients for submitting the populated form. HTTP's > > > > PUT method MUST be used otherwise." > > > > to this: "Request method specified in the form representation MUST be used for > > > > submit requests. HTTP's POST method MAY be used otherwise." > > > > > > > > > > > > > Ok. > > > > > > > --------- > > > > > > > > Changed this: "If the media type, used for constructing submission form, supports > > > > content encoding information provisioning, form data MUST be encoded > > > > according to the explicitly specified encoding type before > > > > submission. The media type used for constructing form MUST be used > > > > otherwise." > > > > to this: "Content type specified in the form representation MUST be used for > > > > submit requests. The content type of the form representation MUST be > > > > used otherwise." > > > > > > > > > > > > > This sounds wrong to me. I get your point I think, but the question of what to send if the form does not tell you seems orthogonal to your draft to me. > > > > > > Getting a second opinion here might be a good idea. > > > > > > > > > > > > > > ---------------- > > > > > > > > in 3.2. changed this: "When included in a resource which represents particular entry, the > > > > "update-form" link relation identifies a target resource that > > > > represents a pre-populated form for editing associated entry." > > > > > > > > to this: "When included in a resource, the "edit-form" link relation > > > > identifies a target resource that represents the form for editing associated resource" > > > > > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > > > > > Done > > > > > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > > > > > in 4.1 changed this: "The target IRI points to a resource that is a representation of a > > > > valid submission form for the data described by the form resource" > > > > to this: "The target IRI points to a resource that is a representation of a > > > > valid submission form." > > > > > > > > > > > > > 'representation' here sounds (to me) misleading. What about 'points to a resource where a creation form can be obtained'? > > > (Though I dislike 'creation form' here) > > > > > > Anyhow - maybe yours is just good enough... > > > > > > Thanks for the quick responses. > > > > > > Jan > > > > > > > > > > > > > > ---------- > > > > > > > > in 4.2 changed this: "The target IRI points to a resource that is a representation of a > > > > valid pre-populated submission form for editing the data > > > > represented by the associated entry." > > > > to this: "The target IRI points to a resource that is a representation of a > > > > valid submission form for editing associated resource." > > > > > > > > Best regards, > > > > Ioseb > > > > > > > > On Tuesday, May 15, 2012 at 1:31 PM, Jan Algermissen wrote: > > > > > > > > > Review of http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > > > > > Abstract > > > > > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > > s/pre-populated input// > > > > > > > > > > > > > > > Introduction > > > > > > > > > > "between any kind of entry and a pre-populated input form for modifying the associated entry" > > > > > s/pre-populated input// > > > > > > > > > > Consider dropping the second paragraph or rewrite so that it does not imply that sometimes link relations would be tied to a media type (which they must never be). > > > > > > > > > > 3.1.1 > > > > > > > > > > Do not constrain the method use. It is a runtime choice the client makes. If the form media type includes method information the client will (usually) be programmed to use that , otherwise, your draft must not constrain method use. > > > > > > > > > > As a client I can try create resources using PUT as often as I desire - the server will tell me at runtime whether it worked. > > > > > > > > > > If you feel you must say something here, make it a hint along the lines of "If the client has no particular information about what method to use a POST would be the best guess" > > > > > > > > > > Not sure about the SHOULD in the 415 example - using SHOULD here makes your draft depend normatively on the 415 spec and the fact that 415 is the code to use for the described case is inherent in the nature of 415. No need to repeat that here. Maybe emphasize that it is an example. > > > > > > > > > > 3.1.2 > > > > > see 3.1.1 comments :-) > > > > > > > > > > > > > > > 4.2. consider s/update-form/edit-form/ ? > > > > > > > > > > I think 4.1 and 4.2 need slight rephrasing, but I am not an experience I-D writer. If I think of something I'll let you know. > > > > > > > > > > Jan > > > > > > > > > > > > > > > > > > > > On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > Updated link: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-05 > > > > > > > > > > > > > > > > > > > > > On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmanashvili wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I've updated draft for "create-form" and "update-form" link relations. Fixed several minor issues and added table of contents. > > > > > > > > > > > > > > Reviews are highly appreciated. Thanks in advance! > > > > > > > > > > > > > > Best regards, > > > > > > > Ioseb > > > > > > > > > > > > > > -- > > > > > > > Ioseb Dzmanashvili > > > > > > > Lead Architect > > > > > > > Picktek LLC > > > > > > > 24b Khazbegi ave. > > > > > > > Tbilisi, 0177, Georgia > > > > > > > T (+995 32) 39.58.56, F (+1 202) 315.3934 > > > > > > > picktek.com (http://picktek.com) > > > > > > > code.ge > > > > > > > github.com/ioseb (http://github.com/ioseb) > > > > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --4fb38454_53e31a24_cd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thank you very much Jan=21

=
> Why do you need to say this at all=3F IWO, what is missing if y= ou drop it=3F
> Right - and they are defined *there* - why d= o you want to say in your draft that one must obey other drafts=3F
<= /div>

I'd be rather happy do drop this at all. I'm jus= t not sure what exactly needs to be included in the draft and what is not= (obviously this is due to my lack of experience in writing drafts) ;)&nbs= p;

> (Admittedly, I am still unsure how = appropriate this language-tweaking is for I-Ds. I guess one could go on f= orever fiddling with the words. I lack a quality indicator, telling me th= at 'we are done' :-)
> =40Mark, Julian ... if you read = this, drop me note what balance makes sense.

Tha= t would be great=21

Best regards,
Iose= b
=20

On Wednesday, May 16, = 2012 at 10:55 AM, Jan Algermissen wrote:


On May 15, 2012, = at 4:33 PM, Ioseb Dzmanashvili wrote:

Hi Jan,

Thank you very= much=21

to this: =22Content type specified in the form = representation MUST be used for
submit requests. The content ty= pe of the form representation MUST be
used otherwise.=22
<= /div>

This sounds wrong to me. I get your point I think, but the que= stion of what to send if the form does not tell you seems orthogonal to y= our draft to me.
Getting a second opinion here might be a good = idea.

Maybe this=3F

=22A content type specified in the form representation M= UST be used for submitting requests, or otherwise, a content type defined= in the media type specification of a form MUST be used=22

Why do you need to say this at all=3F IWO, = what is missing if you drop it=3F


=46or example form HTML forms, for da= ta submission default content type is =22application/x-www-form-urlencode= d=22 but in some cases =22multipart/form-data=22 can be indicated explici= tly. Both cases are defined by media type spec itself.

Right - and they are defined *there* - why do y= ou want to say in your draft that one must obey other drafts=3F

=22The target IRI points to a re= source that is a representation of a
valid submission form.=22<= /div>

'representation' here sounds (to me) misleading. What a= bout 'points to a resource where a creation form can be obtained'=3F
(Though I dislike 'creation form' here)

What about this=3F
=22The target IRI points t= o a resource where a submission form can be obtained=22

Yes, I guess that works.

<= div>(Admittedly, I am still unsure how appropriate this language-tweaking= is for I-Ds. I guess one could go on forever fiddling with the words. I = lack a quality indicator, telling me that 'we are done' :-)
=40Mark, Julian ... if you read this, drop me note what balan= ce makes sense.

Jan


What do yo= u think=3F

ioseb
On Tuesday, May 15, = 2012 at 5:43 PM, Jan Algermissen wrote:


On May 15, 2012, at 12:58 PM, I= oseb Dzmanashvili wrote:

Hi Jan,

Thanks for review=21

Here are changes i made(i didn't submit draft yet):

Abstract
=22between any kind of entry and a pre-populated input form for modifyi= ng the associated entry=22
s/pre-populated input//
In= troduction
=22between any kind of entry and a pre-populated inp= ut form for modifying the associated entry=22 s/pre-populated input//
Consider dropping the second paragraph or rewrite so that it does = not imply that sometimes link relations would be tied to a media type (wh= ich they must never be).

Chan= ged this: =22This specification defines link relation types which may be = used
to express the relationships between a resource and an inp= ut form for
constructing entry submissions, or between any kind= of entry and a
pre-populated input form for modifying the asso= ciated entry.=22
to this: =22This specification defines link re= lation types which may be used
to express the relationships bet= ween a resource and an input form for
constructing data submiss= ions.=22

Sounds good.



<= /div>
3.1.1
Do not const= rain the method use. It is a runtime choice the client makes. If the form= media type includes method information the client will (usually) be prog= rammed to use that , otherwise, your draft must not constrain method use.=
As a client I can try create resources using PUT as often as I= desire - the server will tell me at runtime whether it worked.
If you feel you must say something here, make it a hint along the lines = of =22If the client has no particular information about what method to us= e a POST would be the best guess=22
Not sure about the SHOULD i= n the 415 example - using SHOULD here makes your draft depend normatively= on the 415 spec and the fact that 415 is the code to use for the describ= ed case is inherent in the nature of 415. No need to repeat that here. Ma= ybe emphasize that it is an example.
3.1.2
see 3.1.1 = comments :-)

Chanted this: =22= If the media type, used for constructing submission form, supports
<= div>target URI information provisioning, explicitly specified target URI<= /div>
MUST be used by clients for submitting the populated form. Cont= ext
URI MUST be used otherwise.=22
to this: =22Target= URI specified in the form representation MUST be used for
subm= it requests. Context URI MUST be used otherwise.=22

Agreed.


--------

Change= d this: =22If the media type, used for constructing submission form, supp= orts
method information provisioning, explicitly specified requ= est method
MUST be used by clients for submitting the populated= form. HTTP's
PUT method MUST be used otherwise.=22
t= o this: =22Request method specified in the form representation MUST be us= ed for
submit requests. HTTP's POST method MAY be used otherwis= e.=22

Ok.

---------

Changed this: =22If the media type, used for constructing submission f= orm, supports
content encoding information provisioning, form d= ata MUST be encoded
according to the explicitly specified encod= ing type before
submission. The media type used for constructin= g form MUST be used
otherwise.=22
to this: =22Content= type specified in the form representation MUST be used for
sub= mit requests. The content type of the form representation MUST be
used otherwise.=22

This so= unds wrong to me. I get your point I think, but the question of what to s= end if the form does not tell you seems orthogonal to your draft to me.

Getting a second opinion here might be a good ide= a.


=

----------------

in 3.2. cha= nged this: =22When included in a resource which represents particular ent= ry, the
=22update-form=22 link relation identifies a target res= ource that
represents a pre-populated form for editing associat= ed entry.=22

to this: =22When included in a reso= urce, the =22edit-form=22 link relation
identifies a target res= ource that represents the form for editing associated resource=22

4.2. consider s/update-fo= rm/edit-form/ =3F

Done
I think 4.1 and 4.2 need sligh= t rephrasing, but I am not an experience I-D writer. If I think of someth= ing I'll let you know.

in 4.1 chang= ed this: =22The target IRI points to a resource that is a representation = of a
valid submission form for the data described by the form r= esource=22
to this: =22The target IRI points to a resource that= is a representation of a
valid submission form.=22
=

'representation' here sounds (to me) mis= leading. What about 'points to a resource where a creation form can be ob= tained'=3F
(Though I dislike 'creation form' here)
Anyhow - maybe yours is just good enough...

Thanks for the quick responses.

Jan


<= br>
----------

in 4.2 changed this: =22= The target IRI points to a resource that is a representation of a
valid pre-populated submission form for editing the data
rep= resented by the associated entry.=22
to this: =22The target IRI= points to a resource that is a representation of a
valid submi= ssion form for editing associated resource.=22

B= est regards,
Ioseb

On Tuesday, May 15,= 2012 at 1:31 PM, Jan Algermissen wrote:


=22between any kind of entry and a pr= e-populated input form for modifying the associated entry=22
s/= pre-populated input//


Introductio= n

=22between any kind of entry and a pre-populat= ed input form for modifying the associated entry=22
s/pre-popul= ated input//

Consider dropping the second paragr= aph or rewrite so that it does not imply that sometimes link relations wo= uld be tied to a media type (which they must never be).

3.1.1

Do not constrain the method use. I= t is a runtime choice the client makes. If the form media type includes m= ethod information the client will (usually) be programmed to use that , o= therwise, your draft must not constrain method use.

<= div>As a client I can try create resources using PUT as often as I desire= - the server will tell me at runtime whether it worked.

If you feel you must say something here, make it a hint along th= e lines of =22If the client has no particular information about what meth= od to use a POST would be the best guess=22

Not = sure about the SHOULD in the 415 example - using SHOULD here makes your d= raft depend normatively on the 415 spec and the fact that 415 is the code= to use for the described case is inherent in the nature of 415. No need = to repeat that here. Maybe emphasize that it is an example.
3.1.2
see 3.1.1 comments :-)


4.2. consider s/update-form/edit-form/ =3F
I think 4.1 and 4.2 need slight rephrasing, but I am not an = experience I-D writer. If I think of something I'll let you know.

Jan



<= div>On May 14, 2012, at 9:44 AM, Ioseb Dzmanashvili wrote:

=
<= /blockquote>



On Monday, May 14, 2012 at 11:36 AM, Ioseb Dzmana= shvili wrote:

Hello,

I've updated draft for =22create-form=22= and =22update-form=22 link relations. =46ixed several minor issues and a= dded table of contents.

Reviews are highly appre= ciated. Thanks in advance=21

Best regards,
=
Ioseb

--
Ioseb Dzmanashvili
=
Lead Architect
Picktek LLC
24b Khazbegi ave.
Tbilisi, 0177, Georgia
T (+995 32) 39.58.56, =46 (+1 202= ) 315.3934
 =20 =20 =20 =20 =20

--4fb38454_53e31a24_cd-- From ioseb.dzmanashvili@gmail.com Mon May 21 02:32:27 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0AA21F85F0 for ; Mon, 21 May 2012 02:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g2S2ULATxoz for ; Mon, 21 May 2012 02:32:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B729A21F8514 for ; Mon, 21 May 2012 02:32:26 -0700 (PDT) Received: by bkty8 with SMTP id y8so4536967bkt.31 for ; Mon, 21 May 2012 02:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type; bh=EzZBzUBQFRyMb/jUxyIFlylrKlkRqUfiIYB06OnZZYE=; b=u8Hen+c5fGl1JsVM2LZCU3hEA3pzFZkiapQ8ZsV1oLTmOX8Lad3bWuohYtYAybds/T jrwJp4Xlp/8eeTAcn8DO1+Bj20SN6IEFtuP24UxaeWzhVPeQp1GkSKjVaFMKpxRT66a0 rIxS4AGNpceR0Epg+MSWPZWSP7mKg7WXdes9I8SgrR8epWQSlIBdNLEaougVnR6yD8fG EwBK8nTOPhlJufL4aWPOnfo/Kk0oTjIIl6EXsHi8KkSzx3bweRgiM47pzYW/pEQQrC+O iGomBwMT5nHNoYsbxjp/MkL3WTLmDPfKpVvxnnHJePlUpIokTQoyCi+ZZIBEOUBjrbmV aS/Q== Received: by 10.204.156.4 with SMTP id u4mr7844157bkw.6.1337592745748; Mon, 21 May 2012 02:32:25 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id zx16sm26010008bkb.13.2012.05.21.02.32.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 May 2012 02:32:24 -0700 (PDT) Date: Mon, 21 May 2012 13:50:20 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <85A0570E01EC4BD8B77F684F0A835293@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fba0fdc_7fb7e0aa_db" Subject: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-07 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 09:32:27 -0000 --4fba0fdc_7fb7e0aa_db Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everybody, Draft was updated, all previously discussed changes are included in new version: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-07 Feedback is highly appreciated, thanks in advance! Best regards, Ioseb --4fba0fdc_7fb7e0aa_db Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello everybody,

Draft was = updated, all previously discussed changes are included in new version:&nb= sp;http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-r= elation-07

=46eedback is highly appreciated,= thanks in advance=21

Best regards,
Io= seb
--4fba0fdc_7fb7e0aa_db-- From mnot@mnot.net Thu May 24 17:24:24 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874FB11E80C6 for ; Thu, 24 May 2012 17:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at09lvKmEVJI for ; Thu, 24 May 2012 17:24:24 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCA511E80B5 for ; Thu, 24 May 2012 17:24:24 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.21.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A6FEF22E257; Thu, 24 May 2012 20:24:22 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 May 2012 10:24:19 +1000 Message-Id: <89F5BD70-0220-465B-9858-436050F2F951@mnot.net> To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: "Julian F. Reschke" , Jan Algermissen Subject: [link-relations] Admin: List prefix X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:24:24 -0000 Does anyone mind if we turn the Subject prefix [link-relations] off on = this list? Regards, -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Thu May 24 22:49:11 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF321F8593 for ; Thu, 24 May 2012 22:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5nT03lzce2T for ; Thu, 24 May 2012 22:49:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4E46B21F8587 for ; Thu, 24 May 2012 22:49:10 -0700 (PDT) Received: (qmail invoked by alias); 25 May 2012 05:49:08 -0000 Received: from p5DD9682C.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.44] by mail.gmx.net (mp032) with SMTP; 25 May 2012 07:49:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+xLHAkQ5SxtA7/NC7h5AUUAsUucQkK6jKIBdgYtQ rjZXL2uQa3l+3B Message-ID: <4FBF1D52.6020503@gmx.de> Date: Fri, 25 May 2012 07:49:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mark Nottingham References: <89F5BD70-0220-465B-9858-436050F2F951@mnot.net> In-Reply-To: <89F5BD70-0220-465B-9858-436050F2F951@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Jan Algermissen , link-relations@ietf.org Subject: Re: [link-relations] Admin: List prefix X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 05:49:11 -0000 On 2012-05-25 02:24, Mark Nottingham wrote: > Does anyone mind if we turn the Subject prefix [link-relations] off on this list? > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ Nope. From ioseb.dzmanashvili@gmail.com Fri May 25 09:58:26 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0886021F8736 for ; Fri, 25 May 2012 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQZtdfabUFy4 for ; Fri, 25 May 2012 09:58:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6E21F8715 for ; Fri, 25 May 2012 09:58:25 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so746545wgb.13 for ; Fri, 25 May 2012 09:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=6ps2L5qmkYnjMZQxAuGQ6a3PQfMDqTl3QjfOFCugdjA=; b=P+eF+WO6CU9DHV1mv2rmghdPRmm5lNxKjInTLrB+LYENrBEvhzRWqVH2nz5/M9KE7P kLtB+rasCsrHntOMNu0p2m+CbquQGQsiLkfEcCya49r/plokd33v7RYhPxycNS7056q3 x55R/lb4LYlY9PU/yL6ORxSmtw9cU4ubtTqVcF18n+HSbXoHK/Ei7v28lnlz64fK6mjp DYEQcawgw5WNJ2vw0Eb/2KUFtoXQB6FYh0NCRMjV3Re4LSQ1/xbcqgOBPVuy+mdgdY11 Wkp2/R2Ch4EljNfC8DPDtQv8m1g7E3xNeNzE6xONT+gxPOBiTCXU5i6HeXXMZH903FN0 JqBQ== Received: by 10.216.208.89 with SMTP id p67mr2221262weo.155.1337965104427; Fri, 25 May 2012 09:58:24 -0700 (PDT) Received: from [192.168.1.110] ([94.240.230.4]) by mx.google.com with ESMTPS id e20sm51409567wiv.7.2012.05.25.09.58.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 May 2012 09:58:23 -0700 (PDT) Date: Fri, 25 May 2012 21:16:25 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <8FF8866F0330433D8E1ADE6D48D3788D@gmail.com> In-Reply-To: <85A0570E01EC4BD8B77F684F0A835293@gmail.com> References: <85A0570E01EC4BD8B77F684F0A835293@gmail.com> X-Mailer: sparrow 1.6 (build 1081.27) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4fbfbe69_5015cd1a_24ba" Cc: "=?utf-8?Q?julian.reschke=40gmx.de?=" Subject: Re: [link-relations] Version update notification for draft-ioseb-dzmanashvili-link-relation-07 X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:58:26 -0000 --4fbfbe69_5015cd1a_24ba Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Any feedback? Best regards, Ioseb On Monday, May 21, 2012 at 1:50 PM, Ioseb Dzmanashvili wrote: > Hello everybody, > > Draft was updated, all previously discussed changes are included in new version: http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-relation-07 > > Feedback is highly appreciated, thanks in advance! > > Best regards, > Ioseb > > --4fbfbe69_5015cd1a_24ba Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello, 

Any feedback=3F=

Best regards,
Ioseb
=20

On Monday, May 21, 201= 2 at 1:50 PM, Ioseb Dzmanashvili wrote:

Hello everybody,

Draft was = updated, all previously discussed changes are included in new version:&nb= sp;http://tools.ietf.org/html/draft-ioseb-dzmanashvili-link-r= elation-07

=46eedback is highly appreciated,= thanks in advance=21

Best regards,
Io= seb
 =20 =20 =20 =20
=20

--4fbfbe69_5015cd1a_24ba-- From mnot@mnot.net Thu May 31 18:07:38 2012 Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2415F21F852A for ; Thu, 31 May 2012 18:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1vAqA9PCrwu for ; Thu, 31 May 2012 18:07:37 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8D27121F8528 for ; Thu, 31 May 2012 18:07:37 -0700 (PDT) Received: from [10.4.229.100] (unknown [69.20.3.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1AAB822DD6D; Thu, 31 May 2012 21:07:30 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 1 Jun 2012 11:07:27 +1000 Message-Id: <05D2DE86-8B5A-4BD7-B43B-9A12A07FD5F1@mnot.net> To: link-relations@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: Mike Kelly Subject: [link-relations] NEW RELATIONs: invalidates / inv-by X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 01:07:38 -0000 We'd like to register two new relations, "invalidates" and "inv-by". See: Cheers, -- Mark Nottingham http://www.mnot.net/