- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 10 Nov 2015 19:33:04 +0000
- To: Yakov Shafranovich <yakov@noom.com>, David Booth <david@dbooth.org>
- Cc: "public-csv-wg@w3.org" <public-csv-wg@w3.org>, public-csv-wg-comments@w3.org
- Message-Id: <408AA60D-BB3D-44F4-AB0B-5A45C842E296@jenitennison.com>
Hi David, Yakov, I have made some changes to make it more obvious that there are default locations that will be examined, as you will have seen in: https://github.com/w3c/csvw/pull/778 David, we know these changes will not satisfy you. As we have said, we are not prepared to make the editorial changes that would satisfy you because we do not think they are necessary or helpful to include in the spec. Cheers, Jeni > On 9 Nov 2015, at 14:53, Yakov Shafranovich <yakov@noom.com> wrote: > > I have concerns about this as well. In the real world, the metadata > file approach is probably the one that will get used the most, and the > standard should be readable enough to reflect that. > > Yakov > > On Thu, Nov 5, 2015 at 3:30 PM, David Booth <david@dbooth.org> wrote: >> On 11/04/2015 10:11 PM, David Booth wrote: >>> >>> Uh . . . was anything done to address the editorial issues that I >>> raised? I don't see any changes in the current draft: >>> https://w3c.github.io/csvw/syntax/#locating-metadata >>> The specific wording that I suggested for addressing them was rejected, >>> but I neither saw any alternate wording proposed instead, nor do I now >>> see any relevant changes. The issues were: >>> >>> 1. The standard metadata filename feature is not listed at the beginning >>> of section 5 where a reader would expect it, in the itemized list of >>> "methods of locating metadata". >>> >>> 2. The title of section 5.3, which defines that feature, also fails to >>> mention it. >> >> >> For the above issues, the benefit of addressing them is that the >> standard-metadata-filename feature would be easier for the reader to find. >> Right now that feature is hidden in a section that is primarily about a >> feature that few users are likely to care about. Editorially speaking, that >> is just plain *wrong*, and we already have evidence that it is a problem, >> because both Ivan and I failed to notice that the standard-metadata-filename >> feature is actually in the spec! >> >> This is an editorial issue, and as with all editorial issues, it should be >> assessed from the *reader's* perspective. It is very easy to correct, and >> correcting it would have clear benefit to readers. If someone thinks there >> would somehow be harm in correcting it, then please say what that harm would >> be. >> >>> >>> 3. Readers are not apprised of the risks of using the .well-known feature. >> >> >> If someone is concerned that mentioning only the risks will sound unbalanced >> and be interpreted as discouraging people from using the feature, then by >> all means the benefits can also be mentioned, in order to provide a balanced >> view of the pros and cons, so that readers can make the most informed >> choices about the features they choose. If someone thinks that it would >> somehow be harmful to include a *balanced* note that points out both the >> risks and benefits of using .well-known to specify non-standard metadata >> filenames, then please say what you think that harm would be. Unless one is >> attempting to bias readers toward one feature or another by intentionally >> withholding information -- which would be intellectually dishonest -- then I >> fail to see what harm it could possibly do to include a balanced note that >> points out the risks and benefits of the feature and allows the reader to >> make a more informed choice. >> >> If someone is concerned about whether pointing out risks and benefits (or >> pros and cons) of a feature is something that belongs in a technical >> specification **at all**, then the answer to that is clearly yes,. In fact, >> standards are *required* to list known security risks of features that they >> define. >> >> Is anyone listening? >> >> David Booth >> >> >>> >>> Did I miss something? Am I looking at a wrong version? >>> >>> David Booth >>> >>> >>> On 11/04/2015 10:33 AM, Dan Brickley wrote: >>>> >>>> >>>> CSVW WG, Ivan, >>>> >>>> In today's meeting, we voted unanimously to request a transition to >>>> Proposed Recommendation. >>>> >>>> RESOLVED: The WG resolves that its work on "Model for Tabular Data and >>>> Metadata on the Web", "Metadata Vocabulary for Tabular Data", >>>> “Generating RDF from Tabular Data on the Web” and “Generating JSON from >>>> Tabular Data on the Web” is complete and requests that W3C advance them >>>> to Proposed Recommendation status. >>>> URLs: >>>> >>>> http://w3c.github.io/csvw/syntax/index.html?specStatus=PR;publishDate=2014-11-24 >>>> >>>> >>>> http://w3c.github.io/csvw/metadata/index.html?specStatus=PR;publishDate=2014-11-24 >>>> >>>> http://w3c.github.io/csvw/csv2rdf/?specStatus=PR;publishDate=2014-11-24 >>>> >>>> http://w3c.github.io/csvw/csv2rdf/?specStatus=PR;publishDate=2014-11-24#h-sotd >>>> >>>> >>>> >>>> Logs: http://www.w3.org/2015/11/04-csvw-irc#T15-20-09 >>>> >>>> Draft minutes are at http://www.w3.org/2015/11/04-csvw-minutes.html - we >>>> had some complications because WebEx would not start for us, so we >>>> conducted the meeting textually in IRC. >>>> >>>> Thanks everyone for getting us to this milestone :) >>>> >>>> cheers, >>>> >>>> Dan >> >> > -- Jeni Tennison http://www.jenitennison.com/
Received on Tuesday, 10 November 2015 19:33:34 UTC