- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sat, 23 May 2015 12:39:25 +0100
- To: Yakov Shafranovich <yakov-ietf@shaftek.org>, Mark Nottingham <mnot@mnot.net>
- Cc: "public-csv-wg@w3.org" <public-csv-wg@w3.org>, Public TAG List <www-tag@w3.org>
Hi, I’m a little reluctant to use Web Host Metadata as it would require processors to incorporate XML parsers. Defining a text-based .well-known format containing patterns is feasible. What if we did that and said that if such a file were missing implementations should proceed as if there were a file that contains some given patterns, ie: <{path}-metadata.json>; rel="describedBy"; type="application/csvm+json” <{path}/../metadata.json>; rel="describedBy"; type="application/csvm+json" That would retain the ease of use in an environment where access to .well-known was tricky while allowing publishers who want to have more control over their URL space (but still have no access for setting Link headers) to override the default behaviour. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com/ On 20 May 2015 at 01:35:40, Mark Nottingham (mnot@mnot.net) wrote: > > > On 20 May 2015, at 9:44 am, Yakov Shafranovich wrote: > > > > On Tue, May 19, 2015 at 1:16 PM, Jeni Tennison 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 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 Saturday, 23 May 2015 11:39:52 UTC