From ioseb.dzmanashvili@gmail.com Tue Apr 10 11:52: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 0FE4911E80B8 for ; Tue, 10 Apr 2012 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q0=0.303, SARE_URI_EQUALS=1.666] 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 NeFk8GP0Uy3y for ; Tue, 10 Apr 2012 11:52:09 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3211E80F2 for ; Tue, 10 Apr 2012 11:51:53 -0700 (PDT) Received: by wern13 with SMTP id n13so96126wer.13 for ; Tue, 10 Apr 2012 11:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=quSTluonS/vgeMjLO5kukI7RCBbr3EohC9TGCCiJWjs=; b=PGSFfKLtWUPMW0Rp3mHncRX0ZJVTak23dV5LB2eYKU3u/4yZJy+9fSsOwCEyMcke+D Qeh/GYSj+D2PBN04RR7Br16sc8gpT5h3kRi25STSuAgQrhpDsLuGMFufFuVzX31uC94V t6uzvAYObFmfareidckcOtn9nt7R8KW8PGnwxGSvVrxxM6vx7RwTM+FsCMER8mVZO0un NfTmoR1mDDyHZdVn5lhmrsfFJfM10I07ZumYXQ+72/kZiy+hn9aeNm0RflPovh+xDzu7 YkZYXcx3fZ0frXOHoq7b2onsgRw2ooqr8I4XlfdNqjC0bH2ESxQ+7p1nkhBW/WyR5/yN Uihw== Received: by 10.216.134.226 with SMTP id s76mr7038257wei.115.1334083909630; Tue, 10 Apr 2012 11:51:49 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id e6sm39413436wix.8.2012.04.10.11.51.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:51:48 -0700 (PDT) Date: Tue, 10 Apr 2012 23:08:27 +0400 From: Ioseb Dzmanashvili To: link-relations@ietfa.amsl.com Message-ID: <3F3C8471EA914700A81917469112E02F@gmail.com> In-Reply-To: <20120410185059.D6F0A11E813C@ietfa.amsl.com> References: <20120410185059.D6F0A11E813C@ietfa.amsl.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f84852b_7e1219c8_51a" Subject: [link-relations] =?utf-8?q?Confirm=3A_link-relations=40ietfa=2Eam?= =?utf-8?q?sl=2Ecom=3AO5MtqNT4SBEw=3Ab=5FUbN3y5L3RZRMcHabU6Vo4LDNLRVUCv4nk?= =?utf-8?q?-Hg?= 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, 10 Apr 2012 18:53:44 -0000 --4f84852b_7e1219c8_51a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday, April 10, 2012 at 10:50 PM, link-relations@ietfa.amsl.com wrote: > > Confirmation of list posting -- confirmation ID: O5MtqNT4SBEw > > The ietf.org (http://ietf.org) mailing-list server has received a list posting from > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) to link-relations@ietfa.amsl.com (mailto:link-relations@ietfa.amsl.com) with the subject > 'Re: Confirm: > =?utf-8?Q?=3D=3Futf-8=3FQ=3Flink-relations=3D40ietfa.amsl.com (http://3D40ietfa.amsl.com)=3D3A6MqE9oT4SAeA=3D3A6c5fX3otHaKI2OIGV6r5KOPZOq6y3Y1oEclsJg=3F=3D?=' > > As the sender address isn't subscribed to the list, and has not been > confirmed earlier, we have to request a confirmation of the address. > To confirm the address, send a message to link-relations@ietfa.amsl.com (mailto:link-relations@ietfa.amsl.com), > with the same subject line as this message. > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form. The reply's additional "Re:" is ok.) > > If you do not wish your posting to the list to go through, simply > disregard this message. Questions to postmaster@ietf.org (mailto:postmaster@ietf.org). > > --4f84852b_7e1219c8_51a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On T= uesday, April 10, 2012 at 10:50 PM, link-relations=40ietfa.amsl.com wrote= :

Confirmation of l= ist posting -- confirmation ID: O5MtqNT4SBEw

The= ietf.org mailing-list server has rec= eived a list posting from
'Re: Confirm:
=3D=3Futf-8=3FQ=3F=3D= 3D=3D3=46utf-8=3D3=46Q=3D3=46link-relations=3D3D40ietfa.amsl.com=3D3D3A6MqE9oT4SAeA=3D3D3A6c5fX3otHa= KI2OIGV6r5KOPZOq6y3Y1oEclsJg=3D3=46=3D3D=3F=3D'

= As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address= .
To confirm the address, send a message to link-relations=40ietfa.amsl.com,<= /div>
with the same subject line as this message.

(Simply sending a 'reply' to this message should work from most ema= il
interfaces, since that usually leaves the subject line in th= e right
form. The reply's additional =22Re:=22 is ok.)

If you do not wish your posting to the list to go throu= gh, simply
disregard this message. Questions to postmaster=40ietf.org.
=20 =20 =20 =20
=20

--4f84852b_7e1219c8_51a-- From ioseb.dzmanashvili@gmail.com Tue Apr 10 12:08:28 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 007E711E80F4 for ; Tue, 10 Apr 2012 12:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.381, 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 Y8fJk-mpuy6K for ; Tue, 10 Apr 2012 12:08:27 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id EEB8911E80DF for ; Tue, 10 Apr 2012 12:08:26 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3361708wgb.1 for ; Tue, 10 Apr 2012 12:08:26 -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=NuB71s5n/PAhiLoDUmMYXcHP60z1PUB61pmnD3QDwk4=; b=wxh5+8RKKD1DeMFgHszp3KJtJ95MrVkzAaPBf5a2N8doLQ1k7jfBw3OsSTEmduEkm+ yXfpGLoEs2gZfepidhiIyIO3GNVDUVbMOBgFMi3HUqJJYKjHoM+8T2llLwgHZPvinSye XBiPzIXwXbnHrtZhk/772ExCK+f1nJ3j5hgkuOfjrlQfQWzdoqOFT+064NQKwJVurb0T QZUy+LllIc1XErDjmf6px0aH+MakT8DNIfIeinFenEhv0/gAtj3ZcnCJ+5mxSGQhk5Yr 8tuitVHxT+iV/ftv01wmUvVrGv660HHgwZTKuCW+F6qSFxfOWHid/HRNWO+Xm5UO5dT1 Brqg== Received: by 10.180.98.8 with SMTP id ee8mr9663688wib.14.1334084906012; Tue, 10 Apr 2012 12:08:26 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id k6sm39499594wiy.7.2012.04.10.12.08.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 12:08:25 -0700 (PDT) Date: Tue, 10 Apr 2012 23:25:03 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f84890f_1514a0af_51a" Subject: [link-relations] NEW RELATION: form 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, 10 Apr 2012 19:08:28 -0000 --4f84890f_1514a0af_51a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, I've submitted new draft of the 'form' link relation type:http://datatracker.ietf.org/submit/status/40699/b546af566ca2a9264b9f7d36582d9bdb/ Description: - The link relation is intentionally generic, and it can be used with multiple media types in a wide variety of use cases. - When included in a resource which represents a collection, the 'form' link relation identifies a target resource that represents the form for adding a new member to the context collection. - When included in a resource which represents a member of a collection, the 'form' link relation identifies a target resource that represents a pre-populated form for editing the context resource. Could you please review? 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 --4f84890f_1514a0af_51a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear All,

I've submitte= d new draft of the 'form' link relation type:http://datatracker.ietf.org/submit/s= tatus/40699/b546af566ca2a9264b9f7d36582d9bdb/

Description:
- The link relation is intentionally generi= c, and it can be used with  multiple media types in a wide variety o= f use cases.
- When included in a resource which rep= resents a collection, the 'form'  link relation identifies a ta= rget resource that represents the form for adding a new member to th= e context collection.
- When included in a resource w= hich represents a member of a collection, the 'form' link relation i= dentifies a target resource that represents a pre-populated form for= editing the context resource.

Could = you please review=3F
Thanks in advance=21

<= div>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
picktek.com=
code.ge
github.com/ioseb
twitter.com/ioseb= i
--4f84890f_1514a0af_51a-- From svartman95@gmail.com Tue Apr 10 12:45: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 CD02C11E8132 for ; Tue, 10 Apr 2012 12:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lZPL+Z2Lxdiz for ; Tue, 10 Apr 2012 12:45:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19511E812A for ; Tue, 10 Apr 2012 12:45:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so132666ghb.31 for ; Tue, 10 Apr 2012 12:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w2djzjEMCS9UKn/RCwkKx4YV5fJPLag9FoYREIx6NiI=; b=nPBsY9Pn5nOQ7jND2gXdxNXbslcQokihozxTmBFfXolCCBM07bKP8QSj21ozxbvklM NVU1radNgThamERWK9Cko45D8ol4bjVqHpeILe4DndtJfJl40o8xjRsR/AC5p3Tb4O/Y kpdUA/5BIaoacAqeunLdcZDrGoz1/Q8GmWJh/8+ULg8sVsPDSVv2B6/moJmx5oHb3oh7 f4kCMtO0PL+RiXa9zM+8KEgWpW2rEegkfy9bwF0ENsEtBFgEtd1g54IYhcwyKUh0UiRV wu9rkwM7Gz05FomtmBeGvhSA4szN5TesPMmesUpVasyAHtMtFKwHgKP3wAmbmWYDf8H6 U74Q== MIME-Version: 1.0 Received: by 10.60.3.99 with SMTP id b3mr17652302oeb.72.1334087126845; Tue, 10 Apr 2012 12:45:26 -0700 (PDT) Received: by 10.60.118.68 with HTTP; Tue, 10 Apr 2012 12:45:26 -0700 (PDT) In-Reply-To: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> Date: Tue, 10 Apr 2012 19:45:26 +0000 Message-ID: From: Bjartur Thorlacius To: Ioseb Dzmanashvili Content-Type: text/plain; charset=UTF-8 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 19:45:27 -0000 On 4/10/12, Ioseb Dzmanashvili wrote: > - When included in a resource which represents a collection, the 'form' > link relation identifies a target resource that represents the form for > adding a new member to the context collection. > - When included in a resource which represents a member of a collection, the > 'form' link relation identifies a target resource that represents a > pre-populated form for editing the context resource. > What about hierarchical collections, collections of collections? Than member collections would be both members and collections making this relation ambiguous. From ioseb.dzmanashvili@gmail.com Tue Apr 10 13:12:39 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 AC90011E8131 for ; Tue, 10 Apr 2012 13:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=1.133, 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 RFpzOeLOs6pC for ; Tue, 10 Apr 2012 13:12:39 -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 3143E21F8501 for ; Tue, 10 Apr 2012 13:12:38 -0700 (PDT) Received: by bkuw5 with SMTP id w5so170854bku.31 for ; Tue, 10 Apr 2012 13:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fan95UbA9kT6v8wpLD7lYdHDI+4nWGnQrnU9jnMazyo=; b=LbUKg2tDhHuWPxfya3w4eC98aor8VIHet/5T1Fkmv6aPz38JLoK0R5L40Lux0R9boE Jk8oQPTylHykB9rJnDUiryrCqlio5y0t/ZERuEa0sL/RfscNcU8bR0U7r/XurkR2RmfP sVTqbbe5dE4JDDSPyVGa2ocBhWIURdOAZCeZN53ix1azPJMWxqIkovS40eyaoeLaK+3S uY5LSZiRCDWzBMPYm3cE3ZOUPs4PGDWVbaUfTZn2/IT7bKrRgBerU9vw/7zxH1PySrY0 aOhmPuM09bBuK4VBTGQQK1mfD0R0i4DSCG8JSEJJ+/FgoEgnq3kNMkWnRKMoPxUL2EWd Cxcg== MIME-Version: 1.0 Received: by 10.204.156.139 with SMTP id x11mr5331368bkw.59.1334088757172; Tue, 10 Apr 2012 13:12:37 -0700 (PDT) Received: by 10.204.70.4 with HTTP; Tue, 10 Apr 2012 13:12:37 -0700 (PDT) In-Reply-To: References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> Date: Wed, 11 Apr 2012 00:12:37 +0400 Message-ID: From: Ioseb Dzmanashvili To: Bjartur Thorlacius Content-Type: multipart/alternative; boundary=0015175dd714785bad04bd58bef2 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 20:12:39 -0000 --0015175dd714785bad04bd58bef2 Content-Type: text/plain; charset=ISO-8859-1 Hi Bjartur, Thanks for response! > What about hierarchical collections, collections of collections? Than > member collections would be both members and collections making this > relation ambiguous. Good question, though I do not think it's a problem. It depends where you put the link. Same question will be relevant to the *edit* relation, though it depends where you put it. For example, if I have collection which contains other collections, it doesn't necessarily mean that top level collection is directly writable and it's reasonable to put *form* links inside sub collections and this will mean "add new item/entry to the collection". On another hand, if sub collections contain entries, putting *form* link on entry level will mean "edit this particular entry". If there is some extremely complicated hierarchy of collections it's questionable whether this thing is writable/editable on it's own rights IMHO. It's very easy to create complicated structures with XML/JSON though it doesn't mean that whole hierarchy is manageable through single form. Again, in my opinion it completely depends on design and intent. Best regards, Ioseb On Tue, Apr 10, 2012 at 11:45 PM, Bjartur Thorlacius wrote: > On 4/10/12, Ioseb Dzmanashvili wrote: > > - When included in a resource which represents a collection, the 'form' > > link relation identifies a target resource that represents the form for > > adding a new member to the context collection. > > - When included in a resource which represents a member of a collection, > the > > 'form' link relation identifies a target resource that represents a > > pre-populated form for editing the context resource. > > > What about hierarchical collections, collections of collections? Than > member collections would be both members and collections making this > relation ambiguous. --0015175dd714785bad04bd58bef2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0Bjartur,

Thanks for response!

<= div>
> What about hierarchical collections, collections of collectio= ns? Than
>=A0member collections would be both members and coll= ections making this
>=A0relation ambiguous.

Good question, tho= ugh I do not think it's a problem. It depends where you put the link. S= ame question will be relevant to the *edit* relation, though it depends whe= re you put it.=A0

For example, if I have collection which contains other = collections, it doesn't necessarily mean that top level collection is d= irectly writable and it's reasonable to put *form* links inside sub col= lections and this will mean "add new item/entry to the collection"= ;. On another hand, if sub collections contain entries, putting *form* link= on entry level will mean "edit this particular entry".=A0

If there is some extremely complicated hierarchy of col= lections it's questionable whether this thing is writable/editable on i= t's own rights IMHO. It's very easy to create complicated structure= s with XML/JSON though it doesn't mean that whole hierarchy is manageab= le through single form.

Again, in my opinion it completely depends on design an= d intent.

Best regards,
Ioseb

<= div class=3D"gmail_quote">On Tue, Apr 10, 2012 at 11:45 PM, Bjartur Thorlac= ius <svartman9= 5@gmail.com> wrote:
On 4/10/12, Ioseb Dzmanash= vili <ioseb.dzmanashvili= @gmail.com> wrote:
> - When included in a resource which represents a collection, the '= form'
> link relation identifies a target resource that represents the form fo= r
> adding a new member to the context collection.
> - When included in a resource which represents a member of a collectio= n, the
> 'form' link relation identifies a target resource that represe= nts a
> pre-populated form for editing the context resource.
>
What about hierarchical collections, collections of collections? Than=
member collections would be both members and collections making this
relation ambiguous.
--0015175dd714785bad04bd58bef2-- From svartman95@gmail.com Tue Apr 10 13:44: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 6C25B21F859F for ; Tue, 10 Apr 2012 13:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BxjhhaEpWrsI for ; Tue, 10 Apr 2012 13:44:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC23D21F8598 for ; Tue, 10 Apr 2012 13:44:36 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so277456obb.31 for ; Tue, 10 Apr 2012 13:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h25z1RgGxJZOUJIcrb7izMb2gBgqqHW+0TfDOEYy8sI=; b=05m8RaBrFwGphwRNBUnZKvpYJxUNP2vBEiBtaUyrWnV0J6+KbUVKxD8dI7BYTxfSbH br9GXPhItzjqNvaF+ptdqSDB8mbWYK5S/tqPTfHyF9klSPFX//ihRDghFjhNzwKAUwiS zxr9ceiAxaCI1PuU2UiEq+bEnoE1GXrHl5gDeRBaPH8qlxNfPS7hnAA7KFYrwCdclBG5 IvPT4nEcg3rg33wrumK274GbONAG70HmOD8tqUmaXx+eGZmXYMFe4fpM24/RemdB4HK6 B08FrwtPBO63aWrVcsRZ1Oqdtwdv0UxBEp1I8HsPEc1c4YUojknyQp3Q0Tnj97nDRpBr k/9A== MIME-Version: 1.0 Received: by 10.60.36.100 with SMTP id p4mr18112027oej.42.1334090676545; Tue, 10 Apr 2012 13:44:36 -0700 (PDT) Received: by 10.60.118.68 with HTTP; Tue, 10 Apr 2012 13:44:36 -0700 (PDT) In-Reply-To: References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> Date: Tue, 10 Apr 2012 20:44:36 +0000 Message-ID: From: Bjartur Thorlacius To: Ioseb Dzmanashvili Content-Type: text/plain; charset=UTF-8 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 20:44:37 -0000 On 4/10/12, Ioseb Dzmanashvili wrote: >> What about hierarchical collections, collections of collections? Than >> member collections would be both members and collections making this >> relation ambiguous. > > Good question, though I do not think it's a problem. It depends where you > put the link. Same question will be relevant to the *edit* relation, though > it depends where you put it. > > For example, if I have collection which contains other collections, it > doesn't necessarily mean that top level collection is directly writable and > it's reasonable to put *form* links inside sub collections and this will > mean "add new item/entry to the collection". On another hand, if sub > collections contain entries, putting *form* link on entry level will mean > "edit this particular entry". > So, if the context represents a collection, the target is instructions (a form) for adding a member to the collection, and if not, it's synonymus with the edit link relation? First of all, modifying resources is so common that it should be standardized as much as is practical. Firstly, it must be possible to link to more alterable representations of the resource. Secondly, modified versions must be redistributable. The latter is usually realized by sending the modified version to whomever served the original. The alterable version may be in a specialized format improbably already understood by the user agent, but that shouldn't be too much of an issue if it has an unique media type. Then the server may accept modified versions using a standard protocol. But none of that has much to do with collections. I propose a more specific link relation: add or append. The new link relation would have the semantics you described of a form for adding a new member to a collection, but not a form for modifying a resource. From ioseb.dzmanashvili@gmail.com Tue Apr 10 14:02: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 C697811E8153 for ; Tue, 10 Apr 2012 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.633, 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 NH-OBtrvJhjw for ; Tue, 10 Apr 2012 14:02:59 -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 A0A1111E814B for ; Tue, 10 Apr 2012 14:02:58 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so187284wib.13 for ; Tue, 10 Apr 2012 14:02:57 -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=UxwCbl0LbtMlPEkC3oin1i3N4lM+L648th17VarBdf4=; b=D02OKEHIPVKAiXPvheRCvMzbg4uh2iJi8LmjYbIUW1VdDIobxH3sI7Bsie1zbTsvLz cWljWfK2PEewmy0rrl6sHnbMqJx0VFnlw0YuV067yNXZmyrr+G3VoCouOFCQMTxVOxHM OlvCvtFFzRO0XETQLvyu5DcXLNMWPJukvPsqCAZw+J+hkGvmNTBGpowH/nwMC1zNtto9 rkvyDjiUDoZktmvSJQ51DA8pSo5N5+Nk0v3DGKdNNVOEde/7e/PU6zH64O20wwpcko20 XRDDQtbBGELcA+iboajTmRrz6/ILo4/ulLlHFnHJfG7PHi0EQUcGM2hc2djRq6eQJdtZ wQUA== Received: by 10.180.80.9 with SMTP id n9mr10351340wix.4.1334091777768; Tue, 10 Apr 2012 14:02:57 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id gd4sm1713556wib.6.2012.04.10.14.02.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 14:02:57 -0700 (PDT) Date: Wed, 11 Apr 2012 01:19:34 +0400 From: Ioseb Dzmanashvili To: Bjartur Thorlacius Message-ID: <90681541C3F542E58FA3E266158898EA@gmail.com> In-Reply-To: References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f84a3e6_1e022be9_51a" Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 21:02:59 -0000 --4f84a3e6_1e022be9_51a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline > So, if the context represents a collection, the target is instructions > (a form) for adding a member to the collection, and if not, it's > synonymus with the edit link relation? Exactly. Though with one difference, it doesn't necessarily mean that creation *form* and edit *form* are exactly same i.e. edit form MAY have different structure depending on purpose of a resource. > First of all, modifying resources is so common that it should be > standardized as much as is practical. Firstly, it must be possible to > link to more alterable representations of the resource. Secondly, > modified versions must be redistributable. The latter is usually > realized by sending the modified version to whomever served the > original. I'm not sure I understand what you mean here. How it can be possible in all cases for all media types to just modify representation and send it back? Does it imply that all kinds of representations in all cases contain sufficient amount of information which give flexibility to agents to just modify and send back to owner? > The alterable version may be in a specialized format improbably > already understood by the user agent, but that shouldn't be too much > of an issue if it has an unique media type. Then the server may accept > modified versions using a standard protocol. First of all not all representations of resources are self contained enough and doesn't give agents enough information regarding data types of particular attributes of the resource. > But none of that has much to do with collections. I propose a more specific link relation: add or append. "add" or "append" what? property? image? video? It's a way confusing compared to very generic *form* which is way clear and well understood by everyone IMHO. > The new link relation would have the semantics you described of a form for adding a new member to a collection, but not a form for modifying a resource. *form* doesn't lack this semantics. ioseb On Wednesday, April 11, 2012 at 12:44 AM, Bjartur Thorlacius wrote: > So, if the context represents a collection, the target is instructions > (a form) for adding a member to the collection, and if not, it's > synonymus with the edit link relation? > > First of all, modifying resources is so common that it should be > standardized as much as is practical. Firstly, it must be possible to > link to more alterable representations of the resource. Secondly, > modified versions must be redistributable. The latter is usually > realized by sending the modified version to whomever served the > original. > > The alterable version may be in a specialized format improbably > already understood by the user agent, but that shouldn't be too much > of an issue if it has an unique media type. Then the server may accept > modified versions using a standard protocol. > > But none of that has much to do with collections. I propose a more > specific link relation: add or append. > > The new link relation would have the semantics you described of a form > for adding a new member to a collection, but not a form for modifying > a resource. --4f84a3e6_1e022be9_51a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
> So, if the context represents a collection= , the target is instructions
> (a form) for adding a member = to the collection, and if not, it's
> synonymus with the edi= t link relation=3F

Exactly. Though with one diff= erence, it doesn't necessarily mean that creation *form* and edit *form* = are exactly same i.e. edit form MAY have different structure depending on= purpose of a resource.

> =46irst of all, mod= ifying resources is so common that it should be 
> stan= dardized as much as is practical. =46irstly, it must be possible to
=
> link to more alterable representations of the resource. Secondl= y,
> modified versions must be redistributable. The latter i= s usually
> realized by sending the modified version to whom= ever served the
> original.

I'm not= sure I understand what you mean here. How it can be possible in all case= s for all media types to just modify representation and send it back=3F D= oes it imply that all kinds of representations in all cases contain suffi= cient amount of information which give flexibility to agents to just modi= fy and send back to owner=3F 

> The alte= rable version may be in a specialized format improbably
> al= ready understood by the user agent, but that shouldn't be too much
<= div>> of an issue if it has an unique media type. Then the server may = accept
> modified versions using a standard protocol.
<= div>
=46irst of all not all representations of resources ar= e self contained enough and doesn't give agents enough information regard= ing data types of particular attributes of the resource.

> But none of that has much to do with collections. I propose= a more specific link relation: add or append.

=22= add=22 or =22append=22 what=3F property=3F image=3F video=3F It's a way c= onfusing compared to very generic *form* which is way clear and well unde= rstood by everyone IMHO.

> The new link relat= ion would have the semantics you described of a form for adding a new mem= ber to a collection, but not a form for modifying a resource.
*= form* doesn't lack this semantics.

ioseb =20

On Wednesday, April 11= , 2012 at 12:44 AM, Bjartur Thorlacius wrote:

So, if the context represents a collection= , the target is instructions
(a form) for adding a member to th= e collection, and if not, it's
synonymus with the edit link rel= ation=3F

=46irst of all, modifying resources is = so common that it should be
standardized as much as is practica= l. =46irstly, it must be possible to
link to more alterable rep= resentations of the resource. Secondly,
modified versions must = be redistributable. The latter is usually
realized by sending t= he modified version to whomever served the
original.
=
The alterable version may be in a specialized format impro= bably
already understood by the user agent, but that shouldn't = be too much
of an issue if it has an unique media type. Then th= e server may accept
modified versions using a standard protocol= .

But none of that has much to do with collectio= ns. I propose a more
specific link relation: add or append.

The new link relation would have the semantics you = described of a form
for adding a new member to a collection, bu= t not a form for modifying
a resource.
=20 =20 =20 =20
=20

--4f84a3e6_1e022be9_51a-- From svartman95@gmail.com Tue Apr 10 14:57: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 82B9711E80B5 for ; Tue, 10 Apr 2012 14:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cc+5PYNIzYn6 for ; Tue, 10 Apr 2012 14:57:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6591221F84F6 for ; Tue, 10 Apr 2012 14:57:30 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so364080obb.31 for ; Tue, 10 Apr 2012 14:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3kw25Sp8ui+0jJWQECehFZ70oJ2n7ZBPFbORCzvVQ20=; b=lK2GjMI0VsoIS3d81/5Nvnb/6++bZ13fQNvU/pJXXYux9GdNTPsSmnEDdOpTX5clAJ uuJFmq5VrM7eSsulle+juuswEinFwqmz6EqiLARWbJOTYgmMtYWe9QYtMhDv33Ej1jy3 t7/BbfodJUbrhH5+SWw5qJ3wOXMctXt0WFg1cOr7IWRvDHVm+Tpd/E+gYTnFSQypSEmQ OyX+jHFtcWYTLExgVcEF7kdoZX17glgnwpGo1k42rCe3nsTuZ0yswXt8aLDeKbQAJCVm O7SrulW9VHnUEUZs/s7XHEnz0DaD58moTJIhQ9UhWFQ/8TmN59DYFGLDKV6aBPEQ2T1P 25Dw== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr18361733oea.52.1334095050063; Tue, 10 Apr 2012 14:57:30 -0700 (PDT) Received: by 10.60.118.68 with HTTP; Tue, 10 Apr 2012 14:57:29 -0700 (PDT) In-Reply-To: <90681541C3F542E58FA3E266158898EA@gmail.com> References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> <90681541C3F542E58FA3E266158898EA@gmail.com> Date: Tue, 10 Apr 2012 21:57:29 +0000 Message-ID: From: Bjartur Thorlacius To: Ioseb Dzmanashvili Content-Type: text/plain; charset=UTF-8 Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 21:57:35 -0000 On 4/10/12, Ioseb Dzmanashvili wrote: >> First of all, modifying resources is so common that it should be >> standardized as much as is practical. Firstly, it must be possible to >> link to more alterable representations of the resource. Secondly, >> modified versions must be redistributable. The latter is usually >> realized by sending the modified version to whomever served the >> original. > > I'm not sure I understand what you mean here. How it can be possible in all > cases for all media types to just modify representation and send it back? That's most certainly not guaranteed. Some resources are pracrically immutable, for example. And "sending back" is often not possible; in which case users typically share or forward. > Does it imply that all kinds of representations in all cases contain > sufficient amount of information which give flexibility to agents to just > modify and send back to owner? > Nope. The owner may not care at all for modifications of representations. But we should have some way to link to more alterable representations. A wiki might for example wish to provide both HTML representation of documents and their wikitext source. An application might want to serve both compact JavaScripts and, say, verbose Java sources they were translated from. Same with raster graphics and vector sources, etc. >> The alterable version may be in a specialized format improbably >> already understood by the user agent, but that shouldn't be too much >> of an issue if it has an unique media type. Then the server may accept >> modified versions using a standard protocol. > > First of all not all representations of resources are self contained enough > and doesn't give agents enough information regarding data types of > particular attributes of the resource. > That can be solved either by supplying a schema containing said information, or by providing an alterable version of the resource. >> But none of that has much to do with collections. I propose a more >> specific link relation: add or append. > > "add" or "append" what? property? image? video? It's a way confusing > compared to very generic *form* which is way clear and well understood by > everyone IMHO. > Search form? Comment form? Given access to an incomprehensive collection of funny videos of cats, an user might want to add a video to the collection, yes. Note that we already have the relation *search* for search forms. >> The new link relation would have the semantics you described of a form for >> adding a new member to a collection, but not a form for modifying a >> resource. > *form* doesn't lack this semantics. > No, but *form* confusingly has two definitions; it has different semantics depending on context. As one of the definitions is equivalent to the definition of the registered link relation *edit*, it would be simpler to narrow *form* to a single definition. From ioseb.dzmanashvili@gmail.com Tue Apr 10 15:26:19 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 9412B11E8125 for ; Tue, 10 Apr 2012 15:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=0.563, 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 cPY8m+tomTVd for ; Tue, 10 Apr 2012 15:26:18 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id DC45411E80EA for ; Tue, 10 Apr 2012 15:26:17 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3492603wib.1 for ; Tue, 10 Apr 2012 15:26: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=PysLBiFhqNG+0ZrmzgwVXgYyee1kzjw7XHzyQtQFFvY=; b=xt9RlqJNDpE6DUaVPD+RpTaQC/uk1GGApZ318a1++dOjVuTItxCQeWr1rjZdo8jO5m YjSs1JjMEQwCf+ufkUpiHTwJJtoe/OGZZiKd295xMr7e2fL2Df146L54TE+Z30G3LME8 MqiPbIMPqh264Kr1zYkjy2G7r0U1zGC+qbG7QLKlMc9ll6G9bCG2bbzjT3PNDGuDN/h3 5YrDVhLwh+Zo3ekf/FSU2MCOGKGbFIfRhH8oW7ZGc3bMhpYSLVOJ/ot8HqvRy8EIydpy XyeN2B0HkJUv2eLRcGsBfhSgFCjO3rqQbMsCPyv3t0FaCJ5Vqg8sNRLZDUkcmaeVVwZ9 phMA== Received: by 10.180.106.9 with SMTP id gq9mr10671960wib.17.1334096777057; Tue, 10 Apr 2012 15:26:17 -0700 (PDT) Received: from local.local ([176.73.174.236]) by mx.google.com with ESMTPS id ff9sm40647712wib.2.2012.04.10.15.26.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 15:26:16 -0700 (PDT) Date: Wed, 11 Apr 2012 02:42:55 +0400 From: Ioseb Dzmanashvili To: Bjartur Thorlacius Message-ID: <081873B1BA2944AD9D303C0583D37F41@gmail.com> In-Reply-To: References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> <90681541C3F542E58FA3E266158898EA@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f84b76f_1a0ed871_51a" Cc: link-relations@ietf.org Subject: Re: [link-relations] NEW RELATION: form 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, 10 Apr 2012 22:26:19 -0000 --4f84b76f_1a0ed871_51a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline > That can be solved either by supplying a schema containing said > information, or by providing an alterable version of the resource. That's why I propose *form* relation. Defining the link: on the resource MAY refer to the *form* resource based on HTML5's rich form elements OR xforms OR some extended variation of Collection+JSON *template*, this will imply schema, it avoids statically defined schema and fulfill all other needs. > Search form? Comment form? - Search form is for building templated queries and has nothing to do with sending data to the server with POST/PUT/PATCH methods. - Comment form is most likely will be defined under /comments collection and collection purpose itself will strengthen the exact meaning of write *form*. > Given access to an incomprehensive collection of funny videos of cats, > an user might want to add a video to the collection, yes. Yes but this definitely means that there is a collection of videos and video + it's additional attributes can be happily POSTed to the collection. One thing that worries me in this discussion is that *context* and *media types* are not respected. In my opinion these arguments are relevant to some very custom handcrafted(not even proprietary media types) "representations" of applicatoin/xml and application/json types rather than properly designed media types. If this is the case both applicatoin/xml and application/json lack any hypermedia abilities by default and it's very easy to mess up. > Note that we already have the relation *search* for search forms. Again this has nothing to do with *write* forms. *search* is a query not a write request. > No, but *form* confusingly has two definitions; it has different > semantics depending on context. As one of the definitions is > equivalent to the definition of the registered link relation *edit*, > it would be simpler to narrow *form* to a single definition. I do not agree. First of all *edit* as defined by AtomPub has triple meaning: fetch/modify/delete. And in AtomPub's case most likely it refers to the same *entry* as regular read link, and structure of the representation is same. Important factor here is support of DELETE method which refers to the same resource as well. In case of *form* a) there is no restriction of the URI of the form; and b) semantics I propose imply that form SHOULD contain comprehensive information describing resource + contain values, and this in most cases imply that *read* representation and pre-populated *edit* form representation will be different and this is the key here. ioseb On Wednesday, April 11, 2012 at 1:57 AM, Bjartur Thorlacius wrote: > On 4/10/12, Ioseb Dzmanashvili wrote: > > > First of all, modifying resources is so common that it should be > > > standardized as much as is practical. Firstly, it must be possible to > > > link to more alterable representations of the resource. Secondly, > > > modified versions must be redistributable. The latter is usually > > > realized by sending the modified version to whomever served the > > > original. > > > > > > > > > I'm not sure I understand what you mean here. How it can be possible in all > > cases for all media types to just modify representation and send it back? > > > > That's most certainly not guaranteed. Some resources are pracrically > immutable, for example. And "sending back" is often not possible; in > which case users typically share or forward. > > > Does it imply that all kinds of representations in all cases contain > > sufficient amount of information which give flexibility to agents to just > > modify and send back to owner? > > > > Nope. The owner may not care at all for modifications of > representations. But we should have some way to link to more alterable > representations. A wiki might for example wish to provide both HTML > representation of documents and their wikitext source. An application > might want to serve both compact JavaScripts and, say, verbose Java > sources they were translated from. Same with raster graphics and > vector sources, etc. > > > > The alterable version may be in a specialized format improbably > > > already understood by the user agent, but that shouldn't be too much > > > of an issue if it has an unique media type. Then the server may accept > > > modified versions using a standard protocol. > > > > > > > > > First of all not all representations of resources are self contained enough > > and doesn't give agents enough information regarding data types of > > particular attributes of the resource. > > > > That can be solved either by supplying a schema containing said > information, or by providing an alterable version of the resource. > > > > But none of that has much to do with collections. I propose a more > > > specific link relation: add or append. > > > > > > > > > "add" or "append" what? property? image? video? It's a way confusing > > compared to very generic *form* which is way clear and well understood by > > everyone IMHO. > > > > Search form? Comment form? > Given access to an incomprehensive collection of funny videos of cats, > an user might want to add a video to the collection, yes. > Note that we already have the relation *search* for search forms. > > > > The new link relation would have the semantics you described of a form for > > > adding a new member to a collection, but not a form for modifying a > > > resource. > > > > > > > *form* doesn't lack this semantics. > > > > No, but *form* confusingly has two definitions; it has different > semantics depending on context. As one of the definitions is > equivalent to the definition of the registered link relation *edit*, > it would be simpler to narrow *form* to a single definition. > > --4f84b76f_1a0ed871_51a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
> That can be solved either by supplying a s= chema containing said
> information, or by providing an alte= rable version of the resource.

That's why I prop= ose *form* relation. Defining the link:
<link href=3D=22...=22= rel=3D=22form=22 type=3D=22=5BSPECI=46IC=5FMEDIA=5FTYPE=5FHERE=5D=22 /&g= t; 
on the resource MAY refer to the *form* resource based= on HTML5's rich form elements OR xforms OR some extended variation of Co= llection+JSON *template*, this will imply schema, it avoids statically de= fined schema and fulfill all other needs.

> S= earch form=3F Comment form=3F

- Search form is f= or building templated queries and has nothing to do with sending data to = the server with POST/PUT/PATCH methods. 
- Comment form is= most likely will be defined under /comments collection and collection pu= rpose itself will strengthen the exact meaning of write *form*.

> Given access to an incomprehensive collection of fun= ny videos of cats,
> an user might want to add a video to th= e collection, yes.

Yes but this definitely means= that there is a collection of videos and video + it's additional attribu= tes can be happily POSTed to the collection. 

One thing that worries me in this discussion is that *context* and *me= dia types* are not respected. In my opinion these arguments are relevant = to some very custom handcrafted(not even proprietary media types) =22repr= esentations=22 of applicatoin/xml and application/json types rather than = properly designed media types. If this is the case both applicatoin/xml a= nd application/json lack any hypermedia abilities by default and it's ver= y easy to mess up. 

> Note that we alrea= dy have the relation *search* for search forms.

= Again this has nothing to do with *write* forms. *search* is a query not = a write request.

> No, but *form* confusingly= has two definitions; it has different
> semantics depending= on context. As one of the definitions is
> equivalent to th= e definition of the registered link relation *edit*,
> it wo= uld be simpler to narrow *form* to a single definition.

I do not agree. =46irst of all *edit* as defined by AtomPub has t= riple meaning: fetch/modify/delete. And in AtomPub's case most likely it = refers to the same *entry* as regular read link, and structure of the rep= resentation is same. Important factor here is support of DELETE method wh= ich refers to the same resource as well.

In case= of *form* a) there is no restriction of the URI of the form; and b) sema= ntics I propose imply that form SHOULD contain comprehensive information = describing resource + contain values, and this in most cases imply that *= read* representation and pre-populated *edit* form representation will be= different and this is the key here. 

ioseb=
=20

On Wednesday, April 11= , 2012 at 1:57 AM, Bjartur Thorlacius wrote:

On 4/10/12, Ioseb Dzmanashvili &= lt;ioseb.dzmanashvi= li=40gmail.com> wrote:
=46irst of all, modifying resources = is so common that it should be
standardized as much as is pract= ical. =46irstly, it must be possible to
link to more alterable = representations of the resource. Secondly,
modified versions mu= st be redistributable. The latter is usually
realized by sendin= g the modified version to whomever served the
original.

I'm not sure I understand what you m= ean here. How it can be possible in all
cases for all media typ= es to just modify representation and send it back=3F
That's most certainly not guaranteed. Some resources are pracric= ally
immutable, for example. And =22sending back=22 is often no= t possible; in
which case users typically share or forward.

Does it imply th= at all kinds of representations in all cases contain
sufficient= amount of information which give flexibility to agents to just
modify and send back to owner=3F
Nope. The = owner may not care at all for modifications of
representations.= But we should have some way to link to more alterable
represen= tations. A wiki might for example wish to provide both HTML
rep= resentation of documents and their wikitext source. An application
<= div>might want to serve both compact JavaScripts and, say, verbose Java
sources they were translated from. Same with raster graphics and=
vector sources, etc.

The alterable versio= n may be in a specialized format improbably
already understood = by the user agent, but that shouldn't be too much
of an issue i= f it has an unique media type. Then the server may accept
modif= ied versions using a standard protocol.

=
=46irst of all not all representations of resources are self c= ontained enough
and doesn't give agents enough information rega= rding data types of
particular attributes of the resource.
That can be solved either by supplying a schema = containing said
information, or by providing an alterable versi= on of the resource.

But none of that has much to do= with collections. I propose a more
specific link relation: add= or append.

=22add=22 or =22a= ppend=22 what=3F property=3F image=3F video=3F It's a way confusing
=
compared to very generic *form* which is way clear and well understo= od by
everyone IMHO.
Search form=3F= Comment form=3F
Given access to an incomprehensive collection = of funny videos of cats,
an user might want to add a video to t= he collection, yes.
Note that we already have the relation *sea= rch* for search forms.

=
The new link relation would = have the semantics you described of a form for
adding a new mem= ber to a collection, but not a form for modifying a
resource.
*form* doesn't lack this semantics.
No, but *form* confusingly has two definitions; it ha= s different
semantics depending on context. As one of the defin= itions is
equivalent to the definition of the registered link r= elation *edit*,
it would be simpler to narrow *form* to a singl= e definition.
=20 =20 =20 =20 =20

--4f84b76f_1a0ed871_51a-- From ioseb.dzmanashvili@gmail.com Thu Apr 12 08:58: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 C574921F86A2 for ; Thu, 12 Apr 2012 08:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=1.308, 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 hK1ZlmGDqRwX for ; Thu, 12 Apr 2012 08:58:55 -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 47E5721F8653 for ; Thu, 12 Apr 2012 08:58:55 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4865953wib.13 for ; Thu, 12 Apr 2012 08:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=7xeu2SSkWhDAZQ19MPqEu2gZRO1kKRzg8dXpHzxVfCg=; b=09FpZShCiAXNHEW2SD9V8fhNkGoWZ4kAcUU/LB1MKYG7LtVcH3+doIrB9MNErfdn2a idgmb4wSij7Xpck8hLo+yycWcR1MGLisDQffisiQ+PwFtX1ZVQajcnAA2P0vYWQMEu8e 1u/pgWl3PKxcogXb88T9M/WKstlJ9aO41UVyKzFxTC3+c//YgrelBVYbEgAljjrQ3Miq 6SFVWI9UjzjnD/hG44uzOyJUTe+498b0djyBYGg9z9NAaH7aKNqqa4+NoPWm188NBADr 2BQalhqSJMZqRMtQilyGVfKdPPjgBwLqD6ZopgZbZujE7Fgc/c0262VOMLYSl8wic+jP RJOg== Received: by 10.180.91.168 with SMTP id cf8mr7215037wib.0.1334246334244; Thu, 12 Apr 2012 08:58:54 -0700 (PDT) Received: from local.local ([94.240.230.4]) by mx.google.com with ESMTPS id j3sm22898227wiw.1.2012.04.12.08.58.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 08:58:52 -0700 (PDT) Date: Thu, 12 Apr 2012 20:15:34 +0400 From: Ioseb Dzmanashvili To: link-relations@ietf.org Message-ID: <9075AD4970DB4A8EB4070FF6B2B1DFA2@gmail.com> In-Reply-To: <081873B1BA2944AD9D303C0583D37F41@gmail.com> References: <54CBD3F584864ADA821C3BF9CE47D5E5@gmail.com> <90681541C3F542E58FA3E266158898EA@gmail.com> <081873B1BA2944AD9D303C0583D37F41@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4f86ffa6_65fd275f_51a" Subject: Re: [link-relations] NEW RELATION: form 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, 12 Apr 2012 15:58:56 -0000 --4f86ffa6_65fd275f_51a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone, Any feedback? Thanks! Best regards, Ioseb On Wednesday, April 11, 2012 at 2:42 AM, Ioseb Dzmanashvili wrote: > > That can be solved either by supplying a schema containing said > > information, or by providing an alterable version of the resource. > > That's why I propose *form* relation. Defining the link: > > on the resource MAY refer to the *form* resource based on HTML5's rich form elements OR xforms OR some extended variation of Collection+JSON *template*, this will imply schema, it avoids statically defined schema and fulfill all other needs. > > > Search form? Comment form? > > - Search form is for building templated queries and has nothing to do with sending data to the server with POST/PUT/PATCH methods. > - Comment form is most likely will be defined under /comments collection and collection purpose itself will strengthen the exact meaning of write *form*. > > > Given access to an incomprehensive collection of funny videos of cats, > > an user might want to add a video to the collection, yes. > > Yes but this definitely means that there is a collection of videos and video + it's additional attributes can be happily POSTed to the collection. > > One thing that worries me in this discussion is that *context* and *media types* are not respected. In my opinion these arguments are relevant to some very custom handcrafted(not even proprietary media types) "representations" of applicatoin/xml and application/json types rather than properly designed media types. If this is the case both applicatoin/xml and application/json lack any hypermedia abilities by default and it's very easy to mess up. > > > Note that we already have the relation *search* for search forms. > > Again this has nothing to do with *write* forms. *search* is a query not a write request. > > > No, but *form* confusingly has two definitions; it has different > > semantics depending on context. As one of the definitions is > > equivalent to the definition of the registered link relation *edit*, > > it would be simpler to narrow *form* to a single definition. > > I do not agree. First of all *edit* as defined by AtomPub has triple meaning: fetch/modify/delete. And in AtomPub's case most likely it refers to the same *entry* as regular read link, and structure of the representation is same. Important factor here is support of DELETE method which refers to the same resource as well. > > In case of *form* a) there is no restriction of the URI of the form; and b) semantics I propose imply that form SHOULD contain comprehensive information describing resource + contain values, and this in most cases imply that *read* representation and pre-populated *edit* form representation will be different and this is the key here. > > ioseb > > On Wednesday, April 11, 2012 at 1:57 AM, Bjartur Thorlacius wrote: > > > On 4/10/12, Ioseb Dzmanashvili wrote: > > > > First of all, modifying resources is so common that it should be > > > > standardized as much as is practical. Firstly, it must be possible to > > > > link to more alterable representations of the resource. Secondly, > > > > modified versions must be redistributable. The latter is usually > > > > realized by sending the modified version to whomever served the > > > > original. > > > > > > > > > > > > > I'm not sure I understand what you mean here. How it can be possible in all > > > cases for all media types to just modify representation and send it back? > > > > > > > That's most certainly not guaranteed. Some resources are pracrically > > immutable, for example. And "sending back" is often not possible; in > > which case users typically share or forward. > > > > > Does it imply that all kinds of representations in all cases contain > > > sufficient amount of information which give flexibility to agents to just > > > modify and send back to owner? > > > > > > > Nope. The owner may not care at all for modifications of > > representations. But we should have some way to link to more alterable > > representations. A wiki might for example wish to provide both HTML > > representation of documents and their wikitext source. An application > > might want to serve both compact JavaScripts and, say, verbose Java > > sources they were translated from. Same with raster graphics and > > vector sources, etc. > > > > > > The alterable version may be in a specialized format improbably > > > > already understood by the user agent, but that shouldn't be too much > > > > of an issue if it has an unique media type. Then the server may accept > > > > modified versions using a standard protocol. > > > > > > > > > > > > > First of all not all representations of resources are self contained enough > > > and doesn't give agents enough information regarding data types of > > > particular attributes of the resource. > > > > > > > That can be solved either by supplying a schema containing said > > information, or by providing an alterable version of the resource. > > > > > > But none of that has much to do with collections. I propose a more > > > > specific link relation: add or append. > > > > > > > > > > > > > "add" or "append" what? property? image? video? It's a way confusing > > > compared to very generic *form* which is way clear and well understood by > > > everyone IMHO. > > > > > > > Search form? Comment form? > > Given access to an incomprehensive collection of funny videos of cats, > > an user might want to add a video to the collection, yes. > > Note that we already have the relation *search* for search forms. > > > > > > The new link relation would have the semantics you described of a form for > > > > adding a new member to a collection, but not a form for modifying a > > > > resource. > > > > > > > > > > *form* doesn't lack this semantics. > > > > > > > No, but *form* confusingly has two definitions; it has different > > semantics depending on context. As one of the definitions is > > equivalent to the definition of the registered link relation *edit*, > > it would be simpler to narrow *form* to a single definition. > > > > > > > > --4f86ffa6_65fd275f_51a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello everyone,

Any feedback=3F 
=

Thanks=21

Best regards= ,
Ioseb
=20

On Wednesday, April 11= , 2012 at 2:42 AM, Ioseb Dzmanashvili wrote:

> That can be solved either by supplying a s= chema containing said
> information, or by providing an alte= rable version of the resource.

That's why I prop= ose *form* relation. Defining the link:
<link href=3D=22...=22= rel=3D=22form=22 type=3D=22=5BSPECI=46IC=5FMEDIA=5FTYPE=5FHERE=5D=22 /&g= t; 
on the resource MAY refer to the *form* resource based= on HTML5's rich form elements OR xforms OR some extended variation of Co= llection+JSON *template*, this will imply schema, it avoids statically de= fined schema and fulfill all other needs.

> S= earch form=3F Comment form=3F

- Search form is f= or building templated queries and has nothing to do with sending data to = the server with POST/PUT/PATCH methods. 
- Comment form is= most likely will be defined under /comments collection and collection pu= rpose itself will strengthen the exact meaning of write *form*.

> Given access to an incomprehensive collection of fun= ny videos of cats,
> an user might want to add a video to th= e collection, yes.

Yes but this definitely means= that there is a collection of videos and video + it's additional attribu= tes can be happily POSTed to the collection. 

One thing that worries me in this discussion is that *context* and *me= dia types* are not respected. In my opinion these arguments are relevant = to some very custom handcrafted(not even proprietary media types) =22repr= esentations=22 of applicatoin/xml and application/json types rather than = properly designed media types. If this is the case both applicatoin/xml a= nd application/json lack any hypermedia abilities by default and it's ver= y easy to mess up. 

> Note that we alrea= dy have the relation *search* for search forms.

= Again this has nothing to do with *write* forms. *search* is a query not = a write request.

> No, but *form* confusingly= has two definitions; it has different
> semantics depending= on context. As one of the definitions is
> equivalent to th= e definition of the registered link relation *edit*,
> it wo= uld be simpler to narrow *form* to a single definition.

I do not agree. =46irst of all *edit* as defined by AtomPub has t= riple meaning: fetch/modify/delete. And in AtomPub's case most likely it = refers to the same *entry* as regular read link, and structure of the rep= resentation is same. Important factor here is support of DELETE method wh= ich refers to the same resource as well.

In case= of *form* a) there is no restriction of the URI of the form; and b) sema= ntics I propose imply that form SHOULD contain comprehensive information = describing resource + contain values, and this in most cases imply that *= read* representation and pre-populated *edit* form representation will be= different and this is the key here. 

ioseb=
=20

On Wednesday, April 11= , 2012 at 1:57 AM, Bjartur Thorlacius wrote:

On 4/10/12, Ioseb Dzmanashvili &= lt;ioseb.dzmanashvi= li=40gmail.com> wrote:
=46irst of all, modifying resources = is so common that it should be
standardized as much as is pract= ical. =46irstly, it must be possible to
link to more alterable = representations of the resource. Secondly,
modified versions mu= st be redistributable. The latter is usually
realized by sendin= g the modified version to whomever served the
original.

I'm not sure I understand what you m= ean here. How it can be possible in all
cases for all media typ= es to just modify representation and send it back=3F
That's most certainly not guaranteed. Some resources are pracric= ally
immutable, for example. And =22sending back=22 is often no= t possible; in
which case users typically share or forward.

Does it imply th= at all kinds of representations in all cases contain
sufficient= amount of information which give flexibility to agents to just
modify and send back to owner=3F
Nope. The = owner may not care at all for modifications of
representations.= But we should have some way to link to more alterable
represen= tations. A wiki might for example wish to provide both HTML
rep= resentation of documents and their wikitext source. An application
<= div>might want to serve both compact JavaScripts and, say, verbose Java
sources they were translated from. Same with raster graphics and=
vector sources, etc.

The alterable versio= n may be in a specialized format improbably
already understood = by the user agent, but that shouldn't be too much
of an issue i= f it has an unique media type. Then the server may accept
modif= ied versions using a standard protocol.

=
=46irst of all not all representations of resources are self c= ontained enough
and doesn't give agents enough information rega= rding data types of
particular attributes of the resource.
That can be solved either by supplying a schema = containing said
information, or by providing an alterable versi= on of the resource.

But none of that has much to do= with collections. I propose a more
specific link relation: add= or append.

=22add=22 or =22a= ppend=22 what=3F property=3F image=3F video=3F It's a way confusing
=
compared to very generic *form* which is way clear and well understo= od by
everyone IMHO.
Search form=3F= Comment form=3F
Given access to an incomprehensive collection = of funny videos of cats,
an user might want to add a video to t= he collection, yes.
Note that we already have the relation *sea= rch* for search forms.

=
The new link relation would = have the semantics you described of a form for
adding a new mem= ber to a collection, but not a form for modifying a
resource.
*form* doesn't lack this semantics.
No, but *form* confusingly has two definitions; it ha= s different
semantics depending on context. As one of the defin= itions is
equivalent to the definition of the registered link r= elation *edit*,
it would be simpler to narrow *form* to a singl= e definition.
=20 =20 =20 =20

=20 =20 =20 =20 =20

--4f86ffa6_65fd275f_51a--