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