- From: Alexandre Bertails <bertails@w3.org>
- Date: Wed, 23 Jan 2013 10:37:21 -0500
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Hi Eric, On 01/23/2013 10:30 AM, Wilde, Erik wrote: > hello alexandre. > > On 2013-01-14 20:05 , "Alexandre Bertails" <bertails@w3.org> wrote: >> On 01/14/2013 01:06 PM, Wilde, Erik wrote: >>> - depending on the complexity of your hypermedia format, the number of >>> links in resource representations can be considerable. always placing >>> all >>> of them in HTTP headers as the only option to me seems like an option >>> that >>> quickly may run into limitations of what HTTP should do, and what HTTP >>> implementations are able to do. >> Right. This should be delimited and documented. So far, I've found >> interest only in rel=meta and rel=acl. >>> so my guess is that for some "add-ons" that feel mostly orthogonal to >>> what >>> we're doing (such as the ACL example), using HTTP headers may be a good >>> option and one that allows us to decouple the LDP protocol from >>> orthogonal >>> issues. however, for the things that are at the center of the protocol. >>> i >>> am not so sure that this approach would work very well. >> What are the LDP metadata that would be "at the center of the protocol"? > > whatever we want to expose as interaction affordances. hypothetical let's > assume you GET a collection that has many members, and paging allows you > to say to only GET a list of the first 100 members. now you have at least > 100 links that you can GET. each of the entries might expose more than one > link, though, for example one link to GET the entry itself, and one link > to GET an entry's content (assuming "aggregation"). now you might have 200 > links. and these links are context-sensitive, because the link to an > entry's content must be understood in the context of that entry, otherwise > it's just a link to something random. > > my claim was than including these 200 links in HTTP headers wouldn't be > practical, and thus we need a model how these links can be exposed in the > collection resource representation. There would be 2 of them at most in the case of LDP. One for acl, one for meta, which semantics are LDP specific. The general case for transforming a Link header to its triple counterpart is very very restrictive, as the prefix would be standardized and in the http://www.w3.org/ namespace. With this technique, there is no way to materialize *any* triple through the headers, so I don't think there is any risk at all, and I still think it's a good idea. Alexandre. > > thanks and cheers, > > dret. > >
Received on Wednesday, 23 January 2013 15:37:27 UTC