Closed sideshowbarker closed 9 years ago
for now all there is in addition to the W3C TR categories is one "other" category. i am thinking about also adding "abandoned", which basically would cover anything that's not a W3C TR, but in a similar status as a W3C NOTE (i.e., not being worked on anymore and probably not having any impact in terms of existing or planned implementations). do you think adding such a category and then labeling "Application Lifecycle and Events" as category "abandoned" would be sufficient? i would then include those "abandoned" specs on the separate NOTEs page (https://github.com/dret/HTML5-overview/issues/19), instead of the regular page with ongoing/stable work.
i am thinking about also adding "abandoned", which basically would cover anything that's not a W3C TR
Including EDs that were floated in the WebApps WG over the years but that never went to FPWD? Because there have been a number of those. Or specs that were published completely outside the W3C but abandoned? Because again, there are a number of those.
Or don’t think this particular App Lifecycle spec should somehow be treated any differently from other drafts in other W3C WGs and outside the W3C that never went anywhere. No ED has any kind of formal standing in a WG—especially not one that was never published as FPWD.
do you think adding such a category and then labeling "Application Lifecycle and Events" as category "abandoned" would be sufficient?
I think it would not be a terrifically great idea, for the reason I outlined above. There are quite a number of specs that could end up getting put into that category.
And in the, the reality is that nobody cares about abandoned specs. Web developers especially don’t care about them. They care about specs they can actually use.
As I’ve alluded to in other comments, IMHO this overview should not attempt to be a history for spec archaeologists or something. It should just reflect what’s actually implemented or what has some hope of actually being implemented.
On 2015-08-27 9:42 , Michael[tm] Smith wrote:
i am thinking about also adding "abandoned", which basically would cover anything that's not a W3C TR
Including EDs that were floated in the WebApps WG over the years but that never went to FPWD? Because there have been a number of those. Or specs that were published completely outside the W3C but abandoned? Because again, there are a number of those.
i'd have no problem with that, so yes, if i find those specs or somebody points me to them, and they have stable URIs, i'd include them. in particular now that they appear on a different page and thus nicely separated.
Or don’t think this particular App Lifecycle spec should somehow be treated any differently from other drafts in other W3C WGs and outside the W3C that never went anywhere. No ED has any kind of formal standing in a WG—especially not one that was never published as FPWD.
yes, i do understand that. as a web architecture and standards guy, however, i am also interested to keep track of what has been attempted, even it is has been abandoned for whatever reason: history matters (to some).
I think it would not be a terrifically great idea, for the reason I outlined above. There are quite a number of specs that could end up getting put into that category.
yes, and that would be fine with me.
And in the, the reality is that nobody cares about abandoned specs. Web developers especially don’t care about them. They care about specs they can actually use.
yes, you are of course right, and i think it was a good proposal to separate the two pages. but now that they are, the developers can look at the page of specs that matter, and the historians can look at the page of stuff that people tried/proposed but that did not go anywhere.
As I’ve alluded to in other comments, IMHO this overview should not attempt to be a history for spec archaeologists or something. It should just reflect what’s actually implemented or what has some hope of actually being implemented.
i am willing to add as many disclaimers on the history page as you think are necessary top make it clear that these are not standards or ongoing work. but personally, i want to keep track of the history of things that have been attempted in the HTML5/webapp realm, because sometimes that can be interesting as well (and if only for "spec archaeologists", which i think is a neat concept).
as discussed, https://github.com/dret/HTML5-overview/commit/4d127885fc5bd59df741a5a225712cbc87d00bb5 now lists abandoned specs on the NOTEs page (which now combines all abandoned specs), and thus the "Application Lifecycle and Events" spec has disappeared from the main page. should you happen to know other abandoned specs, i'd be very glad to be pointed to them. thanks!
Oh, good—sorry, in my earlier comments I had misunderstood that you we’re saying the “abandoned specs” section should be added to the overview itself (not to the separate Notes page). I actually think putting the and "Application Lifecycle and Events" spec (and similar specs) on the Notes page is a great idea, so thanks for taking time to make this change, and I’ll try to think of other documents that could be included there.
I’ll go ahead and close this now but if you wanted it left it open for some other reason, of course feel free to re-open it.
all fine with me, and glad you're happy with the resolution. if you happen to think of more specs of the "abandoned" variety, please raise an issue or just let me know. thanks!
From https://github.com/dret/HTML5-overview/issues/23#issuecomment-124930203
Well, I personally wouldn't include that spec, since it's not been updated in more than a year, doesn't seem to have any implementor support, and at this point has no home in any W3C WGs nor anywhere.
But I won't object to it being included if you want to. At least it's in scope as far as being intended for implementation in the Web runtime and the Web security model (as opposed to the other SysApp WG drafts, which were intended for a hypothetical off-Web runtime/security-model that never materialized).
Still I think that lifecycle spec has near-zero chance of ever getting implemented across UAs (or probably any UAs), and so near-zero chance of every becoming part of the Web platform.