[Bug 13918] New: spec splitting script/mechanism doesn't remove parts of the spec that are no longer generated

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13918

           Summary: spec splitting script/mechanism doesn't remove parts
                    of the spec that are no longer generated
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: dbaron@dbaron.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


As Zack Weinberg and Ian Hickson pointed out in
http://groups.google.com/group/mozilla.dev.platform/msg/cbc7a15a35143799 , the
script that generates the split HTML5 spec doesn't seem to remove files that it
no longer generates.  (Ideally, it would add appropriate redirects, but having
a 404 is probably better than having out-of-date content.)  This affects both
the editor's draft and the TR page copy of the HTML5 spec.

For example, in the TR page copy:
http://www.w3.org/TR/2011/WD-html5-20110525/video.html#video
and
http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#video
are the same section of the spec, but the first is out of date (and the only
hints that it is out of date are (1) that it's got "Editor's draft" on the side
and (2) that it's not reachable from the table of contents.  The same problem
exists in the editor's draft at:
http://dev.w3.org/html5/spec/video.html#video
http://dev.w3.org/html5/spec/the-iframe-element.html#the-video-element

However, if somebody has a bookmark to a section of the spec, they won't notice
that their bookmark is out of date.

When sections are no longer generated by the splitter, they should be removed
(with 'cvs remove <file>; cvs commit <file>', I suspect).  Ideally, they should
be redirected (by simultaneously adding to an appropriate .htaccess), but if
that's hard, then a 404 should be returned.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 26 August 2011 14:07:24 UTC