Re: proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57)

hello henry.

On 2013-06-11 10:29 , "Henry Story" <henry.story@bblfish.net> wrote:
>What is the interaction model issue you want to make explicit?

the ability to use information just from the uniform interface (HTTP) and
be able to understand that the representation you have just received
follows some constraints, so that you can start operating under those
assumptions.

look at it from this angle: a browser is a general-purpose thing that's
actually fairly expensive to implement, because there's a lot of machinery
necessary to implement generic HTML support. you could decide to build
clients just for web pages that expose DC and make that explicit in their
HTTP interactions by indicating the use of the DC profile in the HTTP Link
header. you would end up with a much simpler implementation that would be
able to ignore most of the general-purpose HTML processing model, and
could build a working implementation that just allowed people to look at a
page's DC information, including the ability to follow links (as long as
there are DC properties that do use links).

exposing a web page's "DC-ness" by as profile URI in the link header
doesn't take anything away from the general-purpose nature of the pages.
they are still labeled as text/html and general-purpose clients can
continue to work with them as usual. all we have done is to enable a more
specific set of clients (the "DC-browsers") to easily do their job, by
exposing HTTP-level information about the fact that DC-enabled HTML pages
are more than just generic HTML pages. if we hadn't done that, DC-browsers
would have to do content sniffing, and wouldn't be able to for example
explicitly request a page as being "DC-enabled".

cheers,

dret.

Received on Tuesday, 11 June 2013 19:13:52 UTC