Re: Issue #691 on .well-known

FYI, this editorial issue has not been addressed.

To address it, I have recorded a new issue
https://github.com/w3c/csvw/issues/769
and improved the proposed wording changes and created a corresponding 
pull request:
https://github.com/w3c/csvw/pull/768

Thanks,
David

On 10/21/2015 11:57 AM, David Booth 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"
>
> 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."
>
> 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
>>>>
>>>
>>>
>>>

Received on Wednesday, 28 October 2015 14:27:13 UTC