Re: CSVW WG requests PR transition

David,

It would really help if you could separate your feedback into two strands -

* useful editorial suggestions (for which, many thanks)
* outright insults ("intellectually dishonest")

... so we can process them more efficiently.

Many thanks,

Dan



On Tue, 10 Nov 2015 at 20:30 David Booth <david@dbooth.org> wrote:

> 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
> >>
> >>
> >
> >
> >
>