Re: CSVW WG requests PR transition

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

Received on Thursday, 5 November 2015 20:30:45 UTC