thraxil.org:

Reply to: Validation, meet Unit Testing. Unit Testing, meet Validation.

Isn't this more of a job for an XML parser? What do you do with errors that come back in the HTTP response? Do you have to parse it? Here's a quick JAXP version: bq{font-family:monospace;}. DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance(); builderFactory.setNamespaceAware(true); builderFactory.setValidating(true); DocumentBuilder builder = builderFactory.newDocumentBuilder(); builder.setErrorHandler(new DefaultErrorHandler()); builder.parse(input); where *input* can be an input stream or a file. *DefaultErrorHandler* sends parse errors to System.out or an external logger. With a catalog in place to map public IDs locally, this validation can be done quickly and completely offline. I've got something similar in all of my JUnit tests that need to validate XHTML.
if you've got a validating parser locally, sure, you're probably better off using that. the W3C validator will also validate plain HTML though (if you aren't using XHTML).
Your point about HTML (as opposed to XHTML) is a good one. I forgot that others are still stuck with that. You're out of luck with an XML parser if you're trying to validate HTML.
I agree but do you invision program in the future that might do this? Using the W3C validator is real easy which is why I like it but always like to have options.
Love the JAXP version, can't believe I had never thought of doing that before!
Very cool, I am going to show this off in class. I am glad that it was noted it does not work the same with html, that would be an embarassing thing to show and not be able to tell!

formatting is with Textile syntax. Comments are not displayed until they are approved by a moderator. Moderators will not approve unless the comment contributes value to the discussion.

namerequired
emailrequired
url
remember info?