Re: Locating file- and directory-specific metadata (Was: Re: Spec review request: CSV on the Web)

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