Re: CSVW WG requests PR transition

Well, Ivan's merge of Jeni's Pull Request has unfortunately introduced a 
bug into the spec.  The beginning of section 5, the third item in the 
list says: "3. metadata located through default paths which may be 
controlled by a site-wide location configuration".  That is not correct. 
  Default paths are *not* controlled by a site-wide location 
configuration.  Default paths are used in the *absence* of a site-wide 
location configuration.  *Non*-default paths are controlled by a 
site-wide location configuration.   I already pointed out this mistake in
https://github.com/w3c/csvw/pull/778/files
before Jeni's PR was merged, but apparently my comment was ignored.

And while I'm in this section, there is also an incomplete sentence in 
the NOTE just before section 5.1, which reads: "If there is no site-wide 
location configuration, specifies default URI patterns or paths to be 
used to locate metadata."  Perhaps that was intended to be: "If there is 
no site-wide location configuration, default URI paths may be used to 
locate metadata."
                                  --------

Maybe you are all too pissed off at me (for being so pushy) to be able 
to assess my suggestions without bias.  But I'm sorry, that's no excuse. 
  This spec is not for me, it is for the entire community, and any 
reasonable editor should be able to recognize that this spec would be 
significantly improved by making the *most* commonly used feature more 
*visible* to readers in a way that is accurate and reflects readers' 
likely use of the spec.

The continued attempt by the WG to portray the "standard metadata 
filename" feature as an inseparable part of the "site-wide location 
configuration" feature is simply intellectually dishonest.  It is *not* 
how users will see it, it is *not* historically how it developed, and it 
is *not* technically accurate.  (Technical test of separability: could 
feature X be provided without feature Y and vice versa?  Yes.)

I was disappointed that nobody on the working group felt able to stand 
up to Mark Nottingham and push back on the TAG by pointing out that the 
TAG's perception of the standard metadata filename feature's impact on 
web architecture was simply *incorrect*.  It is unfortunate that this 
architectural mis-perception has not been corrected.  But I can 
understand that others in the WG may not have had the time or 
inclination to dig into the question as deeply as I did, and from that 
perspective it was certainly understandable that the WG chose to defer 
to the TAG's guidance rather than listening to little me.  And in the 
end, the inclusion of the .well-known feature causes very little 
substantive harm -- it mostly just adds cruft -- *given* that the 
standard metadata filename feature that users *really* need is still in 
the spec.  (Thank goodness!)

I have very high personal and technical respect for all of you, and I 
very much appreciate your efforts.  You all have done an enormous amount 
of work on this spec and its implementations, whereas I am not a member 
of the WG and I have only made occasional comments here and there in my 
attempts to help.  And since this issue is purely editorial at this 
point, it really is up to you to decide how much work you are willing to 
do to benefit the spec's readership.  I won't make a stink about this if 
the WG decides to do nothing.  But I do still entreat you to think about 
this from the *reader's* and *user's* perspective.

Almost *no* users will give a rat's ass about the "site-wide location 
configuration" feature.  But *all* of them will care about the "standard 
metadata filename" feature.

I am not asking you to remove the "site-wide location configuration" 
feature.  It is there for anyone who feels the need to use it, and it 
satisfies the TAG's guidance.  But I am asking you to *please* -- for 
the sake of the community -- make more visible the feature that *all* 
users *will* care about: the "standard metadata filename" feature. 
Users will *not* think of it as a default of the "site-wide location 
configuration" feature.  They will think of it as the "standard metadata 
filename" feature.  And that, honestly, is more descriptive of what it 
really is.

Thanks for reading, and thanks again for all your hard work,
David Booth


On 11/09/2015 09:53 AM, Yakov Shafranovich 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
>>
>>
>
>
>

Received on Tuesday, 10 November 2015 20:31:00 UTC