Re: Spec review request: CSV on the Web

> On 18 Apr 2015, at 8:24 pm, Jeni Tennison <jeni@jenitennison.com> wrote:
> 
> Hello TAG,

Hi Jeni! 

Apologies for the delay.

> 
> The CSV on the Web Working Group would like to request that the TAG review the following Working Drafts:
> 
>   Model for Tabular Data and Metadata on the Web - 
>     http://www.w3.org/TR/2015/WD-tabular-data-model-20150416/
>   Metadata Vocabulary for Tabular Data -
>     http://www.w3.org/TR/2015/WD-tabular-metadata-20150416/
>   Generating JSON from Tabular Data on the Web -
>     http://www.w3.org/TR/2015/WD-csv2json-20150416/
>   Generating RDF from Tabular Data on the Web -
>     http://www.w3.org/TR/2015/WD-csv2rdf-20150416/

[…]

> 3. The model of access that we’re assuming for CSV and other tabular data files is that someone will link directly to the CSV file (as currently) and that processors will need to retrieve a metadata file about that CSV based on the location of the CSV file. Note that metadata files are file-specific; we wouldn’t expect a single metadata file that includes information about every CSV file on a particular site.
> 
> We think that the “correct” way of getting this pointer to a metadata file (given that there is no scope for embedding information within the CSV file itself) is to use a Link header that points to the metadata file, and we have specified that here [5].
> 
> However, we recognise that there are many publishing environments in which it is impossible for users to set HTTP headers, particularly on an individual file basis. We have therefore specified two other mechanisms to retrieve metadata files, used only if the URL of the original CSV file doesn’t include a query string:
> 
>   * appending ‘-metadata.json’ to the end of the URL to get file-specific metadata [6]
>   * resolving the URL ‘../metadata.json’ against the URL to get directory-level metadata [7]
> 
> Neither of these feels great: they require users who can’t use Link headers to structure their URL space in particular ways, and they use string concatenation on URLs which is horrible. However, we can’t see any better alternative to meet our requirement for what is in effect a file-specific well known URI.

More than not "feeling great", they're defined as bad practice in BCP190/RFC7320 <http://tools.ietf.org/html/rfc7320>.

Having the W3C define a static URI pattern for a metadata file would be a horrible precedent, IMO — one that would likely be used as an excuse for yet more such "conveniences." 

In <https://github.com/w3c/csvw/issues/555>, I suggested the least-worst option of using .well-known (RFC5785), so that the metadata for e.g., "/foo/bar.json" could be found at "/.well-known/whatever-metadata/foo/bar.json". That's been dismissed by the folks participating in the discussion as insufficient, so I'm getting concerned.

DKA, perhaps we could discuss this on the call this week?

Regards,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 19 May 2015 06:52:32 UTC