Re: CSVW WG requests PR transition

On 11/10/2015 03:34 PM, Dan Brickley wrote:
>
> David,
>
> It would really help if you could separate your feedback into two strands -

Sure.  I'll re-send.

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

Apologies.  I will re-word that.

Thanks,
David Booth

>
> ... so we can process them more efficiently.
>
> Many thanks,
>
> Dan
>
>
>
> On Tue, 10 Nov 2015 at 20:30 David Booth <david@dbooth.org
> <mailto: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
>     <mailto: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:46:40 UTC