- 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:09 UTC