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 9ACF4132446 for ; Wed, 9 Aug 2017 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=barelyenough-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43PO1_40dETj for ; Wed, 9 Aug 2017 09:59:50 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44A5132444 for ; Wed, 9 Aug 2017 09:59:48 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id e124so67313213oig.2 for ; Wed, 09 Aug 2017 09:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=barelyenough-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kc5H2cHvH7pN5H+jXBXyjaGvh/Rq8GxUA/ub6blu2Ic=; b=XFMUgBNmnqz9n0YNs4vuQ5E3SjE84PAViMS8FTtDZO/Q7ooDHx9LCtpXlpN+7cmEXa 4jn2Wec7pAtINLSW0jNt9efC7Ysa/cw/LXYUNGYzWbZ8tDyEMTs04A+Eqii2Py40fSGW VuC1p+RtxeGMzmWW9dnv5bMrx+d3EnBDbrue3T0WfEs2WybGdCmij+skGNiua9f9UgoG 6e6wrysCYXxuypjiOa+3LN24UxUedEffYVWWNhgw3MD2GnrX/KzaEHP8ilQYYyCmB1FR km7O9WcWYWzpvlNzis0dt6Hrhw7RDBP5lYc5+JmOT8XWmtmtNzRw1a2C+Uu3baDQBqjk cwkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kc5H2cHvH7pN5H+jXBXyjaGvh/Rq8GxUA/ub6blu2Ic=; b=kdPxHU0iMlnDdx85jZxSdwuX7IQaa3VDxXYiKLeH9INEe9vjusjuPoElvFp82fyHDq upBrag9N1gLCLoKXqiK2bjIguOOWxCwoWM5c3TxUAvIhcfsMfwXphLpETJsNYeUQQI+/ JAA9mjsMQznbi6kiI4rngCFWkA9o9GI2AbrMJp29zaAa0WAcJ/mt/ECm/W2DosLkyjVI cyIvxEQ9R9XTUmRiKFfVw7+h5BO5jofjulX3d1FFIodIh4M9PxzMF86JPOPsLnsnZw8b +rTjwrrKW3T0w/dYxa+imq2VvJAwyrt4Y0HErjHDLX2Xpi70Apg6v2d0BeXNTx5nh1qC Osyw== X-Gm-Message-State: AHYfb5g0GT+FPpUZbgFZJhQQwVnqbDkXTCTClYHBeqGL6aqxgmR/gRQg 8mDVO7J9WnNRnDT6TjRAMOOSJfQiU6BO X-Received: by 10.202.79.84 with SMTP id d81mr9082710oib.50.1502297988119; Wed, 09 Aug 2017 09:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.0.79 with HTTP; Wed, 9 Aug 2017 09:59:47 -0700 (PDT) In-Reply-To: <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> References: <54CA5E71-F469-4FD9-AF29-21985B454CAE@gmail.com> <32B88620-D166-4078-8721-8EFCB818E1FE@pobox.com> From: Peter Williams Date: Wed, 9 Aug 2017 10:59:47 -0600 Message-ID: Subject: Re: Request to register "identifier" relation type To: Ed Summers Cc: Herbert Van de Sompel , link-relations , Geoffrey Bilder , Michael Nelson , Simeon Warner , "John A. Kunze" Content-Type: multipart/alternative; boundary="001a113d83c4edd86b055655010c" Archived-At: X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 16:59:52 -0000 --001a113d83c4edd86b055655010c Content-Type: text/plain; charset="UTF-8" This discussion has convinced me that no existing relation is a good match for the proposed semantics. However, i am concerned that the proposed relation has taken this much discussion to understand. The confusion it generated here does not bode well for it being used properly by mere mortals. I think a more concrete name would greatly improve the usability. Finding a more concrete name will be challenging because this relation conflate several different relationships into a single name. These different semantics are called out in the I-D in sections 3.1-3.4. Having multiple relations, one for each semantic, might be another way to address the usability issues. Some of those use cases seem to be covered by existing relations. For example, `canonical` seems tailor made for the "Version Identifiers" use case. For other use cases, such as "Multi-Resource Publications" and "Persistent Identifiers", there don't seem to be any existing relations that would work. Relations for those narrower use cases would be much easier to understand and use. Peter On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers wrote: > Hi Herbert, > > > On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel > wrote: > > > > * On August 5, Ed Summers posted a question regarding applying > "bookmark" to to the WHATWG list, see > https://lists.w3.org/Archives/Public/public-whatwg-archive/ > 2017Aug/0001.html. There are no responses to this post, so far. > > There have been a few responses if you look at the list of emails for > August: > > https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Aug/ > > > * On August 9, Ed Summer posted a similar question to WHATWG/HTML > GitHub, see https://github.com/whatwg/html/issues/2899. There is a > reaction from @annevk who (1) speculates that the reason "bookmark" is not > to be used with might be in order not to overlap with "canonical" > (2) suggests the use of "canonical" :-) > > Yes, canonical seems to be the relation that most people are reaching for > initially. I did myself on reading your I-D. The fact that seasoned hands > like Kevin Marks and Anne van Kesteren are as well says something. > > > * Michael Nelson has further explored "bookmark" and has confirmed that > there effectively is a reason for not allowing "bookmark" in . It is > related to its target use case: surfacing a link for content contained in a > *part* of a page. Hence, Michael concludes that making "bookmark" usable > with will most likely not happen. @annevk's GitHub response does not > seem to contradict that. Michael based his findings on studying > http://tantek.com/log/2002/11.html#L20021128t1352 and > https://html.spec.whatwg.org/multipage/links.html#link-type-bookmark. He > may write another blog post about this, but, for now, here's how he > explained on Twitter https://twitter.com/i/moments/895081563653902336 > > Yes, it looks like that's probably where things will sit. As Anne > indicated it's likely that rel=bookmark cannot be used with because > of perceived confusion it would cause with canonical. The semantics of > parts of pages vs the page itself don't seem terribly significant to me > from an implementation perspective. Unfortunately 'identifier' will also > probably cause some confusion as well. As systems that rely on 'identifier' > get developed that will be something for them to deal with. > > Thanks for considering all the questions and tracking the conversation > over on the WHATWG list. It speaks to the spirit of what you all are trying > to achieve with this I-D. > > //Ed --001a113d83c4edd86b055655010c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This discussion has convinced me that no existing relation= is a good match for the proposed semantics. However, i am concerned that t= he proposed relation has taken this much discussion to understand. The conf= usion it generated here does not bode well for it being used properly by me= re mortals.=C2=A0

I think a more concrete name would gre= atly improve the usability. Finding a more concrete name will be challengin= g because this relation conflate several different relationships into a sin= gle name.=C2=A0These different semantics=C2=A0are called out in the I-D in = sections 3.1-3.4.

Having multiple relations, one f= or each=C2=A0semantic,=C2=A0might be another way to address the usability i= ssues.=C2=A0Some of those use cases seem to be covered by existing relation= s. For example,=C2=A0`canonical` seems tailor made for the "Version Id= entifiers" use case. For other use cases, such as "Multi-Resource= Publications" and "Persistent Identifiers", there don't= seem to be any existing relations that would work. Relations for those nar= rower use cases would be much easier to understand and use.

<= /div>
Peter

On Wed, Aug 9, 2017 at 10:17 AM, Ed Summers <= ;ehs@pobox.com> wrote:
Hi Herbert,

> On Aug 9, 2017, at 10:35 AM, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:
>
> * On August 5, Ed Summers posted a question regarding applying "b= ookmark" to <link> to the WHATWG list, see https://lists.w3.org/Archives/Public/pub= lic-whatwg-archive/2017Aug/0001.html. There are no responses to th= is post, so far.

There have been a few responses if you look at the list of emails fo= r August:

=C2=A0 =C2=A0 https://lists.w3.or= g/Archives/Public/public-whatwg-archive/2017Aug/

> * On August 9, Ed Summer posted a similar question to WHATWG/HTML GitH= ub, see https://github.com/whatwg/html/issues/2899. There is a reaction from @annevk who (1) speculates that the reason &quo= t;bookmark" is not to be used with <link> might be in order not = to overlap with "canonical" (2) suggests the use of "canonic= al" :-)

Yes, canonical seems to be the relation that most people are reachin= g for initially. I did myself on reading your I-D. The fact that seasoned h= ands like Kevin Marks and Anne van Kesteren are as well says something.

> * Michael Nelson has further explored "bookmark" and has con= firmed that there effectively is a reason for not allowing "bookmark&q= uot; in <link>. It is related to its target use case: surfacing a lin= k for content contained in a *part* of a page. Hence, Michael concludes tha= t making "bookmark" usable with <link> will most likely not= happen. @annevk's GitHub response does not seem to contradict that. Mi= chael based his findings on studying http://tantek.= com/log/2002/11.html#L20021128t1352 and https://html.spec.whatwg.org/multipage/links.html#lin= k-type-bookmark. He may write another blog post about this, but, f= or now, here's how he explained on Twitter https= ://twitter.com/i/moments/895081563653902336

Yes, it looks like that's probably where things will sit. As Ann= e indicated it's likely that rel=3Dbookmark cannot be used with <lin= k> because of perceived confusion it would cause with canonical. The sem= antics of parts of pages vs the page itself don't seem terribly signifi= cant to me from an implementation perspective. Unfortunately 'identifie= r' will also probably cause some confusion as well. As systems that rel= y on 'identifier' get developed that will be something for them to = deal with.

Thanks for considering all the questions and tracking the conversation over= on the WHATWG list. It speaks to the spirit of what you all are trying to = achieve with this I-D.

//Ed

--001a113d83c4edd86b055655010c--