Re: CSVW WG requests PR transition

Hi Jeni,

On re-reading this change again today, I want to say that this change is 
significantly more of an improvement than I previously realized, because 
it makes the standard metadata filename feature significantly more 
visible, even though it does not list it as a separate feature.  Sorry 
for failing to notice that previously.  I think I was thrown off by the 
word "default".  As I suggested today, this would be further improved by 
prepending the word "standard", so that it reads "standard default . . . "

Thanks,
David

On 11/10/2015 02:33 PM, Jeni Tennison wrote:
> 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 Wednesday, 18 November 2015 17:23:18 UTC