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

Re: establishing conversational context (was: Creating non-Atom LDPRs: AtomStrict & AtomRelax)

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 4 Feb 2013 07:44:15 -0500
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
CC: Henry Story <henry.story@bblfish.net>
Message-ID: <CD35683B.EBFC%erik.wilde@emc.com>
hello henry.

good stuff, as usual, and i'll send a full response later on. a brief
remark:

On 2013-02-04 11:37 , "Henry Story" <henry.story@bblfish.net> wrote:
>HTTP after all comes with a method to distinguish data and
>metadata: headers and  content. This is not super-elegant
>because the HTTP syntax is pretty awkward and its semantics
>vague - but as far as the semantics goes that is not that
>different from atom, and the advantage is that it is widely
>deployed.

HTTP does not specify a general metadata delivery architecture. it has a
select few places where  data that matters for the uniform interface of
the web can be put. and if you have metadata that matters on the protocol
level, then you shold put it into these headers (such as ETags). however,
seeing RFC 5988 as a general invitation to stuff any kind of metadata into
HTTP headers is not what this spec is about. media types should have their
ways of doing this, however they see fit (linking between data/metadata
usually is a good idea, if they are exposed as different resources, and
such describedby/describes links may be good candidates for Link: exposure
because they may be interesting for clients to traverse). ideally, you'd
like to divide things so that (in RESTspeak) the *client* can handle the
uniform interface and get what it needs to do that just from the uniform
interface level (parsing HTTP headers according to the well-defined
semantics of those headers), and the *user agent* then mostly works on
resources, and maybe some selective information exposed to it that might
be interesting for the user agent as well ("here's the expiry date of this
response.").

cheers,

dret.
Received on Monday, 4 February 2013 12:45:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC