W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: hypermedia controls vs. payload

From: Alexandre Bertails <bertails@w3.org>
Date: Wed, 23 Jan 2013 10:37:21 -0500
Message-ID: <510003B1.1000509@w3.org>
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.


> thanks and cheers,
> dret.
Received on Wednesday, 23 January 2013 15:37:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC