W3C home > Mailing lists > Public > public-webplatform@w3.org > December 2014

Re: double-check

From: PhistucK <phistuck@gmail.com>
Date: Thu, 4 Dec 2014 21:44:59 +0200
Message-ID: <CABc02_+Tz12h_5q5VJu_c_dx0TWfC6vHxdnNVVvOoJXTWNnE0w@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: Dave Gash <dave@davegash.com>, List WebPlatform public <public-webplatform@w3.org>, Eliot Graff <eliot.graff@microsoft.com>, "Doug Schepers (w3c)" <schepers@w3.org>
Since most of this API is implemented by Chrome (and Safari as well, I
think), I do not think the documentation for it should be deleted.
A prominent warning of obsoletion, low browser support and unmaintained
documentation should be added and the pages are better left as they are. If
we can remove any mark from those pages (not "Ready" and not anything else.
I think I have seen such pages), I think this should be preferred.

Once we get to a point where all of the supporting browsers remove this
feature, I think we can delete it after some grace period.


☆*PhistucK*

On Thu, Dec 4, 2014 at 9:12 PM, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> It's a good question.
>
> In general, the WPD policy (as I understand it) is that
> deprecated/obsolete status is NOT reason to delete a page.  The Docs should
> be comprehensive, real world documentation of any features someone is
> likely to come across when studying web page code.  Deprecated and obsolete
> status should be clearly indicated, and these pages should maybe be
> filtered out of topic listings and such, but they should still be there for
> historical record.
>
> HOWEVER, when it is an entire proposed API that is obsolete because the
> spec was never completed, the benefit is less clear.  We certainly don't
> want to waste time "fixing up" these pages.  However, if they are
> reasonably comprehensive to start out with, it does seem a shame to dump
> them when they might conceivably be useful as an archival reference.
>
> My recommendation is that the first priority should be to make sure that
> the obsolete status (as an abandoned experimental feature) is clearly
> indicated and that these pages aren't showing up anywhere they would be
> mistaken for active features.  That said, if the community would prefer to
> just clear out the clutter, I wouldn't put up too much of a defence.
>
> Best,
> Amelia BR
>
>
> On 4 December 2014 at 11:43, Dave Gash <dave@davegash.com> wrote:
>
>>  Hi all,
>>
>> I'm working through the remaining large batch of Almost Ready pages,
>> trying to promote as many as possible to Ready, and have a question. See this
>> search results page
>> <https://docs.webplatform.org/w/index.php?title=Special:Ask&offset=0&limit=500&q=%5B%5BState%3A%3AAlmost+Ready%5D%5D&p=format%3Dbroadtable&po=%3FState%0A&eq=no>
>> .
>>
>>
>>
>> I'm down to the *filesystem* group, some 60+ pages, and they all seem to
>> be obsolete. They reference this 2014 W3C spec
>> <http://www.w3.org/TR/file-system-api/>, which says "Work on this
>> document is discontinued..."; that discontinued status is also supported by
>> various MDN specs like this one
>> <https://developer.mozilla.org/en-US/docs/Web/API/DirectoryEntry> and this
>> one <https://developer.mozilla.org/en-US/docs/Web/API/FileEntrySync>, which
>> say "This feature is non-standard and is not on a standards track..." There
>> is even an old W3C spec
>> <http://www.w3.org/TR/2012/WD-file-system-api-20120417/> from 2012 that
>> references the 2014 "discontinued" document as the latest published version.
>>
>>
>>
>> Based on those specs, I've been marking the pages "Not Ready" and
>> including "Non-standard; deletion candidate" in the editorial notes, along
>> with the discontinued spec references. But I'm a bit uneasy about
>> invalidating that many pages at once, and want to make sure I'm reading the
>> specs correctly and taking the right action.
>>
>>
>>
>> List-ers, do you agree that the W3C specs indicate that the whole
>> filesystem page group is kaputski?
>>
>>
>>
>> Thanks,
>>
>>  Dave Gash
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Received on Thursday, 4 December 2014 19:46:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:09 UTC