- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 5 Nov 2013 17:22:25 -0800
- To: James M Snell <jasnell@gmail.com>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, IETF Apps Discuss <apps-discuss@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
My understanding (perhaps misplaced) was that it was there so you could replace existing links in a deterministic way. The only other way that comes to mind is to mint a new ‘id’ (or similar) attribute that identifies the instance of the link; e.g., Link: </foo>; rel=“bar”; title=“whatever”; id=abc Link: </foo>; rel=“bar”; title=“the other link to whatever”; id=def I will point out that in some use cases, it’s not unknown to have multiple links of the same type and same target URI in the same document, but with different target attributes. In these cases, Julian’s concern is valid. Regards, On 5 Nov 2013, at 5:18 pm, James M Snell <jasnell@gmail.com> wrote: > It exists because (a) I couldn't come up with any viable, non theoretical use cases where other attributes would really matter and (b) the current model works in practice for everything I've done with it. > > On Nov 5, 2013 5:13 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > On 2013-11-06 02:06, James M Snell wrote: > Give me a viable, non theoretical use case where the other target > attributes and extension parameters would make a difference and I'll > reconsider that constraint. > ... > > I'll try, but in the meantime it would be good if you could explain why the constraint is there in the first place :-) > > Best regards, Julian -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 6 November 2013 01:22:51 UTC