- From: Graham Klyne <gk@ninebynine.org>
- Date: Wed, 20 May 2015 10:48:21 +0100
- To: Mark Nottingham <mnot@mnot.net>, Jeni Tennison <jeni@jenitennison.com>
- CC: "public-csv-wg@w3.org" <public-csv-wg@w3.org>, www-tag@w3.org
On 20/05/2015 01:35, Mark Nottingham wrote: > I'd like to be explicit about the tradeoffs. I see three things, one of which needs to give: > > 1) The syntax of the CSV format (which currently can't convey this kind of metadata) > 2) The ability of your target audience to set metadata on their resources (e.g., HTTP headers, .well-known files) > 3) The prohibition on standards squatting in URI namespace I like your analysis here, but I'd view it slightly differently, in a way that accommodates the RFC 6415 style mentioned by Yakov. I think there's a matter of scope to which a metadata access convention applies: 1. described as part of the resource 2. described as part of the resource access transaction : 3. defined by globally applicable standard The RFC6415 approach defines one intermediary model, e.g. 2.5. metadata access URI described by host-wide convention. And I'm thinking there may be other possible scopes that don't fall foul of the URI-squatting problem (which I take to mean that the server get's to choose the form of the metadata URI). ... On a related issue, for "patterned" mechanisms I think some consideration needs to be given to the form of the primary resource URI. E.g. http://example.org/someresource.csv vs. http://example.org/someresource/ This could have an effect on the way the metadata URIs are determined with reference to the base URI. (FWIW, this is not theoretical - software I'm working primarily uses '/'-terminated forms for resource identifiers, but can also use other forms. A simple-minded relative resolution of "../metadata.example" with reference to the resource URI could yield surprising results in these cases. OTOH, resolving "./metadata.example" would yield more consistent results (for one perspective of consistency). I think the overall issue could be wider than just this example.) #g --
Received on Wednesday, 20 May 2015 09:48:50 UTC