- 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>
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