Pretty much every W3C document opens with about a page and a half of redundant legalese preamble (likely stemming from its academic origins). Sometimes, this preamble changes based on when the document was written, making it both redundant and obsolete.
I propose that we (where “we” is some vague W3C-adjacent group of web developers of no specific group membership) lower the barriers to writing and maintaining specs by stripping off this dead weight, one way or another:
The idea of writing an abstract for a W3C spec seems to be some kind of vestigial organ from the days where W3C papers would be written alongside articles on particle physics in CERN research journals. Realistically, anybody who comes across a web spec is going to have some familiarity with it in context, and doesn’t need an executive summary beyond what they can glean from the title and introduction. Axing this would make specs easier to write, and quicker to read.
“Status of This Document”
This is just a long-form statement that old documents can be superseded by new ones, which is obvious to anybody who has ever worked with any kind of documented rules, anywhere. It’s completely redundant with the block that already appears at the top of all W3C-published documents that already includes “This version”, “Latest published version”, “Latest editor’s draft”, “Previous version”, “Version history”, and “Commit History”.
It includes a bunch of rules about how the document should be read that’d best be hyperlinked from somewhere else, ie. on a wiki page that describes how the W3C (and the greater web ecosystem) generally proceeds. It also includes some directives regarding contributing and feedback, which are redundant to the “Participate” heading at the top of the page.
It also includes some legal disclaimers like the document’s accordance with the W3C Patent Policy and Process Document. Just tack that stuff onto the end of “W3C liability, trademark and document use rules apply.”
The useful thing to know about a document’s status that should be included here, but isn’t, is how it’s been adopted since its introduction, by vendors (for gauging current support) and content authors (for gauging future support).