Re: Issue #691 on .well-known

> On 21 Oct 2015, at 17:57, David Booth <david@dbooth.org> wrote:
> 
> Looking at today's resolution:
> http://www.w3.org/2015/10/21-csvw-irc#T14-13-31
> [[
> RESOLVED: we leave the .well-known mechanism in the standard, with two editorial changes (Jeni's text on clarification and the forward reference)
> ]]
> 
> Given that the standard-URI-pattern feature *is* still in the spec -- in spite of Ivan's (and my) prior misunderstanding -- I think this resolution is reasonable.  The harm of keeping the .well-known mechanism can be minimized.  However, I do have some editorial suggestions to help minimize harm and reduce misunderstandings like the one that Ivan and I had:
> 
> 1. At the beginning of section 5, insert a new item to the list of "methods of locating metadata" before item #4, to read:
> 
>  "4. metadata located through standard URI patterns, see section 5.3"
> 
> 2. Rename section 5.3 to: "Standard URI Patterns and Site-wide Location Configuration"

I am sorry, but I disagree. It is an unnecessary to bring in a new concept in the standard. There should be a forward reference to a default case, but that is where, in my view, this should stop.

> 
> 3. Add an editorial comment to section 5.3 like: "Publishers of metadata files should bear in mind that use of the .well-known feature to specify non-standard URI patterns may be confusing to users and future maintainers who may only know to look for metadata files matching the standard URI patterns, and may therefore make your metadata files harder for users to find when they look for them directly."

And I disagree again. This is not appropriate for a standard: what this actually says is "yes, there is a feature in the standard, and many people will not implement it anyway, but that is all right, so do not use this feature". This is not a text to be put into the document.

Ivan

> 
> Thanks,
> David Booth
> 
> On 10/19/2015 05:35 PM, David Booth wrote:
>> Hi Yakov,
>> 
>> I am confused also.  That's what I thought the spec said (before last
>> week), but last week Ivan said that the standard-URI-pattern feature had
>> been *dropped* in CR.  He pointed me to the top of section 3 (Locating
>> Metadata), which lists only these four mechanisms:
>> https://w3c.github.io/csvw/syntax/#locating-metadata
>> [[
>> 1. metadata supplied by the user of the implementation that is
>> processing the tabular data, see section 5.1 Overriding Metadata.
>> 2. metadata in a document linked to using a Link header associated with
>> the tabular data file, see section 5.2 Link Header.
>> 3. metadata located through a site-wide location configuration, see
>> section 5.3 Site-wide Location Configuration.
>> 4. metadata embedded within the tabular data file itself, see section
>> 5.4 Embedded Metadata.
>> ]]
>> 
>> However, when I look farther down at section 5.3 (Site-wide Location
>> Configuration), I see that this section *does* still include the
>> standard-URI-pattern feature:
>> [[
>> If no such file is located (i.e. the response results in a client error
>> 4xx status code or a server error 5xx status code), processors must
>> proceed as if this file were found with the content:
>> 
>>   {+url}-metadata.json
>>   csv-metadata.json
>> ]]
>> 
>> So apparently the standard-URI-pattern feature was *not* dropped in CR,
>> though it is not listed at the *beginning* of section 5.  Therefore,
>> apparently Ivan's comment about it having been dropped was incorrect:
>> https://github.com/w3c/csvw/issues/691#issuecomment-148780197
>> (Or maybe I misunderstood what he meant?)
>> 
>> If I am now properly understanding what is in the spec, this looks like
>> good news to me, because the following option *would* be a possible path
>> forward:
>> https://github.com/w3c/csvw/issues/691#issuecomment-148778082
>> [[
>> 2. drop |.well-known| but keep the standard URI pattern;
>> ]]
>> 
>> It also means that another possible resolution would be to add an ugly
>> warning to the spec, roughly along the lines I previously suggested:
>> https://github.com/w3c/csvw/issues/691#issuecomment-148778082
>> [[
>> If |.well-known| is kept I think there should at least be a warning in
>> the spec stating that the feature is controversial, that very few people
>> (nobody?)[2] indicated an actual need and intent to use the feature, and
>> the working group did not have time to completely consider its merits
>> before the end of its charter.
>> ]]
>> 
>> Or maybe it should just say: "We were forced by the TAG to add this
>> kludgy feature, but please don't actually use it."   ;)
>> 
>> Thanks,
>> David Booth
>> 
>> On 10/19/2015 09:17 AM, Yakov Shafranovich wrote:
>>> David,
>>> 
>>> I am a bit confused. Reading the current editors draft, section 5.3
>>> (https://w3c.github.io/csvw/syntax/#site-wide-location-configuration):
>>> 
>>> "If no file were found at http://example.org/.well-known/csvm, the
>>> processor will use the default locations and try to retrieve metadata
>>> from http://example.org/south-west/devon.csv-metadata.json and, if
>>> unsuccessful, http://example.org/south-west/csv-metadata.json."
>>> 
>>> The draft, as currently written, seems to read that if no "well-known"
>>> file is found, then the processor will follow the standard URI pattern
>>> you describe.
>>> 
>>> What are you suggesting?
>>> 
>>> Thanks,
>>> Yakov
>>> 
>>> 
>>> On Sat, Oct 17, 2015 at 6:34 PM, David Booth <david@dbooth.org> wrote:
>>>> Having considered this issue further, I am very unhappy with the way
>>>> issue
>>>> #691 on .well-known has transpired:
>>>> 
>>>>  - The WG planned to include an important feature, involving a
>>>> standard URI
>>>> pattern, which would have been *very* helpful to the user community, by
>>>> helping tools to automatically locate a CSV file's metadata.
>>>> 
>>>>  - A concern was raised about whether this standard-URI-pattern feature
>>>> would cause harmful URI squatting.
>>>> 
>>>>  - The WG consulted with the TAG, and the TAG suggested that
>>>> .well-known be
>>>> used instead -- presumably under the assumption that this feature would
>>>> otherwise cause URI squatting.
>>>> 
>>>>  - I then looked more closely at the proposed standard-URI-pattern
>>>> feature
>>>> and discovered that, in spite of first appearances, it would *not*
>>>> actually
>>>> cause URI squatting.  I carefully explained this in detail[1], and
>>>> asked the
>>>> TAG to take a deeper look.[4]
>>>> 
>>>>  - In spite of my pleas, the TAG perfunctorily refused[3] to
>>>> reconsider its
>>>> guidance.  In doing so, the TAG provided no evidence to refute my
>>>> explanation, nor did it offer any new rationale for its prior
>>>> guidance.  All
>>>> recorded evidence suggests that the TAG continued to rely on its
>>>> previous
>>>> assessment of the issue and did not even realize that URI squatting
>>>> was a
>>>> red herring in this case.
>>>> 
>>>>  - Meanwhile, in deference to the TAG's (flawed) guidance, the WG
>>>> removed
>>>> the important standard-URI-pattern feature that would have best
>>>> served the
>>>> user community.  Instead it added the .well-known feature -- a kludge at
>>>> best, which very few CSV publishers would even have the ability to
>>>> use, and
>>>> which *nobody* has indicated an actual need and intent to use.
>>>> 
>>>> This stinks.
>>>> 
>>>> If .well-known is kept in the spec it will be very hard to remove in the
>>>> future.  Furthermore, all the recorded evidence suggests that its
>>>> addition
>>>> to the spec was based on an incomplete understanding of the issue.
>>>> 
>>>> I think the WG did almost all it could to constructively address this
>>>> issue,
>>>> and I applaud the WG for its diligence and great work.  However I do
>>>> think
>>>> it would have helped if the WG had pushed back harder on the TAG
>>>> after the
>>>> URI squatting issue was shown to be a red herring.
>>>> 
>>>> As a courtesy to the WG, I want to give the WG advance notice that I
>>>> intend
>>>> to do whatever I can to block the adoption of .well-known in this
>>>> spec.  I
>>>> very much appreciate the work that the WG has done, but I believe it
>>>> would
>>>> better to *not* take this spec to REC than to include a kludgy
>>>> feature that:
>>>> (a) does *not* serve the user community; (b) few CSV publishers would
>>>> even
>>>> be able to use; (c) nobody has indicated a need and intent to use;
>>>> and (d)
>>>> would be very difficult to remove in the future.
>>>> 
>>>> Sincerely,
>>>> David Booth
>>>> 
>>>> References
>>>> 
>>>> 1. https://lists.w3.org/Archives/Public/www-tag/2015Jun/0026.html
>>>> 
>>>> 2. https://lists.w3.org/Archives/Public/public-csv-wg/2015Jun/0085.html
>>>> 
>>>> 3.
>>>> https://github.com/w3ctag/meetings/blob/gh-pages/2015/07-ber/07-16-minutes.md
>>>> 
>>>> 
>>>> 4. https://lists.w3.org/Archives/Public/www-tag/2015Jun/0036.html
>>>> 
>>> 
>>> 
>>> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704