This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1184 - markup validator ignores SYSTEM doctypes
Summary: markup validator ignores SYSTEM doctypes
Alias: None
Product: Validator
Classification: Unclassified
Component: check (show other bugs)
Version: 0.7.0
Hardware: All All
: P2 critical
Target Milestone: ---
Assignee: Olivier Thereaux
QA Contact: qa-dev tracking
Depends on:
Blocks: 856
  Show dependency treegraph
Reported: 2005-04-01 09:11 UTC by Olivier Thereaux
Modified: 2005-06-03 00:15 UTC (History)
0 users

See Also:

remove redundant code and rewrite core feature of sub preparse_doctype() (1.71 KB, patch)
2005-04-06 04:27 UTC, Olivier Thereaux

Description Olivier Thereaux 2005-04-01 09:11:09 UTC
0.7.0dev seems to have trouble recognizing custom DTDs, even moreso than <= 0.6.7

e.g 1)
or 2)

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.
Comment 1 Olivier Thereaux 2005-04-06 04:27:11 UTC
Created attachment 385 [details]
remove redundant code and rewrite core feature of sub preparse_doctype()
Comment 2 Olivier Thereaux 2005-05-09 05:49:36 UTC
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

- 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).
Comment 3 Olivier Thereaux 2005-06-03 00:15:15 UTC 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 (that one was rejected), but a 
minor change in regexp within preparse_doctype()