This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
0.7.0dev seems to have trouble recognizing custom DTDs, even moreso than <= 0.6.7 e.g 1) http://www.yoyodesign.org/doc/dtd/demo/frameset.php?yoyolng=en or 2) http://www.w3.org/Style/ 0.6.7 declares 1) invalid, but no error given, and declares 2) valid current CVS version claims "This page is not Valid (no Doctype found)!" for both.
Created attachment 385 [details] remove redundant code and rewrite core feature of sub preparse_doctype()
This bug was twofold: 1)- a recent modification in sgml.soc (the sgml catalog in the sgml-lib used by, and distributed with, the validator), aiming at giving warnings when a bogus FPI was use with a good system identifier, was in effect ignoring the system identifier, even when that should not be the case 2)- the doctype detection code (currently in check, &preparse_doctype(), previously &preparse(), and before that probably in something named detect_doctype()...) never detected the presence of a doctype in the case of a SYSTEM declaration, only PUBLIC 3)- version 0.7.0 of check is stricter with its handling of documents without recognized doctypes, and forces the fallback to a known doctype instead of accepting documents as "valid <BLANK>". This new situation is not a bug per se, rather a bug fix, but it made the issue described in point 2) apparent. Suggested fixes: - 1) was fixed by revision 1.16 of http://dev.w3.org/cvsweb/validator/htdocs/sgml-lib/sgml.soc - the collision of 2) and 3) can be fixed by changing preparse_doctype to also recognise SYSTEM doctypes. I will commit such a patch later today. - as also discussed earlier, changing the model from valid/invalid foo to no/n error(s) found would also avoid such issues, but this is not planned (yet).
http://dev.w3.org/cvsweb/validator/httpd/cgi-bin/check#rev1.416 seems to fix this by recording into $File->{Doctype} the FPI if present, the SI otherwise, both for PUBLIC and SYSTEM doctypes. The change is not http://www.w3.org/Bugs/Public/attachment.cgi?id=385 (that one was rejected), but a minor change in regexp within preparse_doctype()