Vernacular

HTML Made Special

Validation Will Save Us

The short of this is that your validator is not your processor. Relying on validation in order to ensure that processing of your vernacular is interoperable is likely to create issues because the two uses of the language are different, and meant for different situations. For instance, in many cases a validator will yield an error in order to flag an input as problematic, whereas the processor might instead apply a default behaviour for input it does not understand.

Validation tools, often in the form of schemata (also known as schemas for the pedantry-challenged), seem for some people to belong to an almost mythical dimension. Not only do many appear to believe that you need a schema to “define a language” (whatever that means), but even those bereft of that error altogether too often expect a schema to be step in — cape and superpowers flapping in the wind — to fix parts of language design that they wish not to think about.

This is not to say that validators are not useful — notably for debugging or in order to test that you are producing content in the manner that you expect — but unless your processing happens to be carried out in the exact same manner as your validation they are not the magic sauce that will make your vernacular interoperable.

A schema can be useful for documentation purposes. But unless you have a very strict workflow it will be essentially useless at producing interoperability, and it certainly won‘t help your design (especially if you have to change your language to fit one validation tool‘s idiosyncratic limitations). To paraphrase the adage: a user had a problem and decided to address it using validation; now she has two problems.

↖︎ Back to list