Re: Locating file- and directory-specific metadata (Was: Re: Spec review request: CSV on the Web)

> On 20 May 2015, at 02:35, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 
>> On 20 May 2015, at 9:44 am, Yakov Shafranovich <yakov-ietf@shaftek.org> wrote:
>> 
>> On Tue, May 19, 2015 at 1:16 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
>>> On 19 May 2015 at 07:52:01, Mark Nottingham (mnot@mnot.net) wrote:
>>> 
>>> The reason that I thought this worthy of TAG discussion is because it illustrates a situation where file- and directory-specific well known locations would be very useful. This might be a need that arises in other cases, so it would be helpful for the community to have the best-practice way of addressing the requirement spelled out. This is particularly the case if the right solution is .well-known, as .well-known is currently described as being for "site-wide metadata", not metadata for individual files. Plus it's always useful to test best practice guidance against real use cases.
>>> 
>> 
>> I would like to add that RFC 6415 provide a mechanism for
>> resource-specific metata, although IMHO this is clunky. This would use
>> templates defined in a host-meta file which would be placed in the
>> ",well-known" directory.
> 
> WHD is one way to do it, but it might be simpler to just define a .well-known that indicates what the convention for per-directory / per-file metadata is; e.g.,
> 
> /.well-known/metadata-locations
> 
> contains
> 
> —%<—
> <{path}.md>; rel=foo
> —>8---
> 
> where the contents of <http://tools.ietf.org/html/rfc6570> is a URI template (<>), so that a client would know that the metadata for
> 
> /foo/bar.json
> 
> is at 
> 
> /foo/bar.json.md
> 

You could also use content negotiation on /foo/bar.json, but if you can’t control the server enough to put a HTTP header, it’s unlikely that conned will work or will be easily enabled (if at all possible).


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

        ~~Yves

Received on Wednesday, 3 June 2015 19:23:57 UTC