site-wide location configuration for metadata files

[JeniT]

fixes #555

I took a look and decided to make this as simple, and specific to CSV on the Web, as possible, to avoid delays. So the definition is just a file of URI templates.

@mnot I'd appreciate your review.

[6a6d74]

@JeniT - having read through the new section on site-wide metadata location, it all makes sense. Including the example provides extra clarity. +1 from me for merge.

[iherman]

I only have an editorial (a.k.a. bike-shedding) issue: is the variable name base the good one? Seeing, say, http://example.org/south-west/devon.csv, my reaction would be that the base is http://example.org/south-west/, rather then the whole URI. We could use the variable url (though I realize this is not ideal, because the fragment is dropped from the original URL).

But that is bike-shedding, I am o.k. with the text otherwise.

[JeniT]

I'm happy to use another name for the variable. Ones I thought of were url, href, file, csv, location, table.

[iherman]

I'm happy to use another name for the variable. Ones I thought of were url, href, file, csv, location, table.

'location' is probably most neutral…

[gkellogg]

Haven't heard back form @mnot on this. It would be nice to have consensus to commit the PR and close the issue.

[mnot]

Looks good. You might want to be a bit tighter on what "not found" means - think you mean HTTP 404 or 410. However, you should also consider:

• redirects (temp and perm)
• timeouts, network not available
• transient 5xx errors
• etc.

You may not need to go that that level of detail, just worth thinking about.

[JeniT]

@mnot do you have any suggested wording? My first reaction to your comment was to try to refer to https://fetch.spec.whatwg.org/ but I think we will have problems referring to that in a normative way.

[gkellogg]

Perhaps the paragraph could simply be the following:

In this case, processors MUST retrieve the file from the well-known URI /.well-known/csvm. (Well-known URIs are defined by [RFC5785].) If no such file is located (i.e., response to HTTP request is 4xx), processors MUST proceed as if this file were found with the content:

Alternatively, somewhat more normative:

In this case, processors MUST retrieve the file from the well-known URI /.well-known/csvm. (Well-known URIs are defined by [RFC5785].) If the response is HTTP status 404 Not Found, or any other status 4xx, processors MUST proceed as if this file were found with the content:

Status 5xx may be transient, and convey no useful information to affect processor behavior other than to fail with an error.

[iherman]

I may miss something, but... I was looking at the section with the example. The text says that

{+url}.json
csvm.json
/csvm?file={url}

may lead to http://example.org/south-west/csvm.json. Is that correct? Why would the second line expand in the base directory of the original CSV file's URI? Isn't it correct that we may need a second variable, base and that the second line in the example above should be

{base}/csvm.json

Note that this also affects the default value for the file.

[gkellogg]

The steps defined in Site-wide Location Configuration say to expand the template using url and then resolve the URL against the tabular data file.

Note that expanding a URI Template does not create an absolute URL necessarily, so it does need to be resolved against something. We specify how this is to be done explicitly.

[iherman]

Ah.

"Resolve the resulting URL against the URL of the requested tabular data file."

Indeed. I missed that; sorry for the noise!

[gkellogg]

Both the cachability of .well-known/csvm and the at-risk text can probably use some word-smithing.

[JeniT]

I have incorporated wordsmithing from this thread.

@gkellogg could you check the manifest.csv against the one in gh-pages? There were merge issues, but I couldn't locate the differences to fix them. When you're happy please merge.