W3C home > Mailing lists > Public > public-csv-wg-comments@w3.org > October 2015

Re: Issue #691 on .well-known

From: David Booth <david@dbooth.org>
Date: Mon, 19 Oct 2015 17:35:13 -0400
To: Yakov Shafranovich <yakov@noom.com>
Cc: "public-csv-wg@w3.org" <public-csv-wg@w3.org>, public-csv-wg-comments@w3.org
Message-ID: <56256211.4050609@dbooth.org>
Hi Yakov,

I am confused also.  That's what I thought the spec said (before last 
week), but last week Ivan said that the standard-URI-pattern feature had 
been *dropped* in CR.  He pointed me to the top of section 3 (Locating 
Metadata), which lists only these four mechanisms:
https://w3c.github.io/csvw/syntax/#locating-metadata
[[
1. metadata supplied by the user of the implementation that is 
processing the tabular data, see section 5.1 Overriding Metadata.
2. metadata in a document linked to using a Link header associated with 
the tabular data file, see section 5.2 Link Header.
3. metadata located through a site-wide location configuration, see 
section 5.3 Site-wide Location Configuration.
4. metadata embedded within the tabular data file itself, see section 
5.4 Embedded Metadata.
]]

However, when I look farther down at section 5.3 (Site-wide Location 
Configuration), I see that this section *does* still include the 
standard-URI-pattern feature:
[[
If no such file is located (i.e. the response results in a client error 
4xx status code or a server error 5xx status code), processors must 
proceed as if this file were found with the content:

   {+url}-metadata.json
   csv-metadata.json
]]

So apparently the standard-URI-pattern feature was *not* dropped in CR, 
though it is not listed at the *beginning* of section 5.  Therefore, 
apparently Ivan's comment about it having been dropped was incorrect:
https://github.com/w3c/csvw/issues/691#issuecomment-148780197
(Or maybe I misunderstood what he meant?)

If I am now properly understanding what is in the spec, this looks like 
good news to me, because the following option *would* be a possible path 
forward:
https://github.com/w3c/csvw/issues/691#issuecomment-148778082
[[
2. drop |.well-known| but keep the standard URI pattern;
]]

It also means that another possible resolution would be to add an ugly 
warning to the spec, roughly along the lines I previously suggested:
https://github.com/w3c/csvw/issues/691#issuecomment-148778082
[[
If |.well-known| is kept I think there should at least be a warning in 
the spec stating that the feature is controversial, that very few people 
(nobody?)[2] indicated an actual need and intent to use the feature, and 
the working group did not have time to completely consider its merits 
before the end of its charter.
]]

Or maybe it should just say: "We were forced by the TAG to add this 
kludgy feature, but please don't actually use it."   ;)

Thanks,
David Booth

On 10/19/2015 09:17 AM, Yakov Shafranovich wrote:
> David,
>
> I am a bit confused. Reading the current editors draft, section 5.3
> (https://w3c.github.io/csvw/syntax/#site-wide-location-configuration):
>
> "If no file were found at http://example.org/.well-known/csvm, the
> processor will use the default locations and try to retrieve metadata
> from http://example.org/south-west/devon.csv-metadata.json and, if
> unsuccessful, http://example.org/south-west/csv-metadata.json."
>
> The draft, as currently written, seems to read that if no "well-known"
> file is found, then the processor will follow the standard URI pattern
> you describe.
>
> What are you suggesting?
>
> Thanks,
> Yakov
>
>
> On Sat, Oct 17, 2015 at 6:34 PM, David Booth <david@dbooth.org> wrote:
>> Having considered this issue further, I am very unhappy with the way issue
>> #691 on .well-known has transpired:
>>
>>   - The WG planned to include an important feature, involving a standard URI
>> pattern, which would have been *very* helpful to the user community, by
>> helping tools to automatically locate a CSV file's metadata.
>>
>>   - A concern was raised about whether this standard-URI-pattern feature
>> would cause harmful URI squatting.
>>
>>   - The WG consulted with the TAG, and the TAG suggested that .well-known be
>> used instead -- presumably under the assumption that this feature would
>> otherwise cause URI squatting.
>>
>>   - I then looked more closely at the proposed standard-URI-pattern feature
>> and discovered that, in spite of first appearances, it would *not* actually
>> cause URI squatting.  I carefully explained this in detail[1], and asked the
>> TAG to take a deeper look.[4]
>>
>>   - In spite of my pleas, the TAG perfunctorily refused[3] to reconsider its
>> guidance.  In doing so, the TAG provided no evidence to refute my
>> explanation, nor did it offer any new rationale for its prior guidance.  All
>> recorded evidence suggests that the TAG continued to rely on its previous
>> assessment of the issue and did not even realize that URI squatting was a
>> red herring in this case.
>>
>>   - Meanwhile, in deference to the TAG's (flawed) guidance, the WG removed
>> the important standard-URI-pattern feature that would have best served the
>> user community.  Instead it added the .well-known feature -- a kludge at
>> best, which very few CSV publishers would even have the ability to use, and
>> which *nobody* has indicated an actual need and intent to use.
>>
>> This stinks.
>>
>> If .well-known is kept in the spec it will be very hard to remove in the
>> future.  Furthermore, all the recorded evidence suggests that its addition
>> to the spec was based on an incomplete understanding of the issue.
>>
>> I think the WG did almost all it could to constructively address this issue,
>> and I applaud the WG for its diligence and great work.  However I do think
>> it would have helped if the WG had pushed back harder on the TAG after the
>> URI squatting issue was shown to be a red herring.
>>
>> As a courtesy to the WG, I want to give the WG advance notice that I intend
>> to do whatever I can to block the adoption of .well-known in this spec.  I
>> very much appreciate the work that the WG has done, but I believe it would
>> better to *not* take this spec to REC than to include a kludgy feature that:
>> (a) does *not* serve the user community; (b) few CSV publishers would even
>> be able to use; (c) nobody has indicated a need and intent to use; and (d)
>> would be very difficult to remove in the future.
>>
>> Sincerely,
>> David Booth
>>
>> References
>>
>> 1. https://lists.w3.org/Archives/Public/www-tag/2015Jun/0026.html
>>
>> 2. https://lists.w3.org/Archives/Public/public-csv-wg/2015Jun/0085.html
>>
>> 3.
>> https://github.com/w3ctag/meetings/blob/gh-pages/2015/07-ber/07-16-minutes.md
>>
>> 4. https://lists.w3.org/Archives/Public/www-tag/2015Jun/0036.html
>>
>
>
>
Received on Monday, 19 October 2015 21:35:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:52 UTC