- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 20 May 2015 10:35:40 +1000
- To: Yakov Shafranovich <yakov-ietf@shaftek.org>
- Cc: Jeni Tennison <jeni@jenitennison.com>, "public-csv-wg@w3.org" <public-csv-wg@w3.org>, Public TAG List <www-tag@w3.org>
> 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
Another way to do it would be to put the CSV in a package / wrapper format that contains the metadata.
Cheers,
--
Mark Nottingham https://www.mnot.net/
Received on Wednesday, 20 May 2015 00:36:10 UTC