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

Re: Issue #691 on .well-known

From: Yakov Shafranovich <yakov@noom.com>
Date: Mon, 19 Oct 2015 09:17:50 -0400
Message-ID: <CAB0piBsvcxCvhi_QXpsYUKG1+ijONfEJXD9tMzCn_t=8aMpnjw@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: "public-csv-wg@w3.org" <public-csv-wg@w3.org>, public-csv-wg-comments@w3.org

I am a bit confused. Reading the current editors draft, section 5.3

"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?


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 Tuesday, 20 October 2015 05:50:42 UTC

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