Here you go -- this is a good stopping point, I think. This supercedes your PR #19. I did a pretty major refactoring of validate.js, but the main way you use xmllint.js is intact.
I added test cases, so now, among the ones we have in samples are:
minimal.xml - A normal, good article
not-well-formed.xml - Results in a parsing error
not-valid.xml - Well-formed, but not valid according to the DTD. This results in a validation error, and never goes to schematron.
entity-refs.xml - Uses entity refs; requires the DTD in order to be parsed. Results in no errors or warnings.
no-doctype.xml - Parses, and skips the DTD validation step, and goes straight to schematron. Results in a warning.
bad-doctype.xml - Doctype declaration has an unrecognized public id. Results in a warning.
system-id.xml - Doctype decl uses "SYSTEM", not "PUBLIC". Results in a warning, skips DTD validation and does schematron.
other-system-id.xml - Good public id, but a random system id. This should work fine, because the system id is ignored.
I think that covers all the possibilities with regards to doctype declarations. Next it will be necessary to get it to validate against RNG and Schematron.
@hubgit,
Here you go -- this is a good stopping point, I think. This supercedes your PR #19. I did a pretty major refactoring of validate.js, but the main way you use xmllint.js is intact.
You can test this at http://jats4r.org/test/validate/.
I added test cases, so now, among the ones we have in samples are:
I think that covers all the possibilities with regards to doctype declarations. Next it will be necessary to get it to validate against RNG and Schematron.