W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-33 (pagination): how to structure functionality

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 12 Nov 2012 13:43:19 -0500
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, James M Snell <jasnell@gmail.com>
Message-ID: <CCC68160.BD60%erik.wilde@emc.com>
hello james.

On 2012-11-12 9:36 , "James M Snell" <jasnell@gmail.com> wrote:
>Just as an fyi to add to the discussion.. one of the Atom extensions I
>experimented with but never got around to writing up is a <link-template>
>element analogous to atom:link that uses a URI Template instead.. e.g.
> <link-template rel="next" href="http://example.org/foo{?page}" />
>In my various experiments this worked fine but it was never put into
>practice because using opaque links proved to be all that was required in
>our specific implementation(s).

as long as links can be static (i.e., don't need any runtime parameters
such as page size or page number), i agree that using static links and
fully opaque URIs is the better way to go, because less machinery is
required on the client. once you get into parametrized services, though,
there's a natural limit to this, and your design options are pretty much
to use URI templates, or push the parameters into the request body (which
then gets you into the awkward territory of designing a protocol that uses
GET with a body 
http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html ).

and an off-list request: james, any interest in spec'ing rfc5005++ with
URI templates, adding stuff such as page size and random page access, and
defining an extension model for services to also expose their own
additional parameters?

cheers,

dret.
Received on Monday, 12 November 2012 18:44:19 UTC

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