Class ValidationConsumer

1. Conform to the specification of a non-validating XML parser that reads all external entities, reported using SAX2 events.
2. Report ignorable whitespace as such (through the ContentHandler interface). This is, strictly speaking, optional for nonvalidating XML processors.
3. Make SAX2 DeclHandler callbacks, with default attribute values already normalized (and without "<").
4. Make SAX2 LexicalHandler startDTD() and endDTD () callbacks.
5. Act as if the (URI)/namespace-prefixes property were set to true, by providing XML 1.0 names and all xmlns* attributes (rather than omitting either or both).

At this writing, the major SAX2 parsers (such as Ælfred2, Crimson, and Xerces) meet these requirements, and this validation module is used by the optional Ælfred2 validation support.

Note that because this is a layered validator, it has to duplicate some work that the parser is doing; there are also other cost to layering. However, because of layering it doesn't need a parser in order to work! You can use it with anything that generates SAX events, such as an application component that wants to detect invalid content in a changed area without validating an entire document, or which wants to ensure that it doesn't write invalid data to a communications partner.

Also, note that because this is a layered validator, the line numbers reported for some errors may seem strange. For example, if an element does not permit character content, the validator will use the locator provided to it. That might reflect the last character of a characters event callback, rather than the first non-whitespace character.

Of interest is the fact that unlike most currently known XML validators, this one can report some cases of non-determinism in element content models. It is a compile-time option, enabled by default. This will only report such XML errors if they relate to content actually appearing in a document; content models aren't aggressively scanned for non-deterministic structure. Documents which trigger such non-deterministic transitions may be handled differently by different validating parsers, without losing conformance to the XML specification. -->

Current limitations of the validation performed are in roughly three categories.

The first category represents constraints which demand violations of software layering: exposing lexical details, one of the first things that application programming interfaces (APIs) hide. These invariably relate to XML entity handling, and to historical oddities of the XML validation semantics. Curiously, recent (Autumn 1999) conformance testing showed that these constraints are among those handled worst by existing XML validating parsers. Arguments have been made that each of these VCs should be turned into WFCs (most of them) or discarded (popular for the standalone declaration); in short, that these are bugs in the XML specification (not all via SGML):

• The Proper Declaration/PE Nesting and Proper Group/PE Nesting VCs can't be tested because they require access to particularly low level lexical level information. In essence, the reason XML isn't a simple thing to parse is that it's not a context free grammar, and these constraints elevate that SGML-derived context sensitivity to the level of a semantic rule.
• The Standalone Document Declaration VC can't be tested. This is for two reasons. First, this flag isn't made available through SAX2. Second, it also requires breaking that lexical layering boundary. (If you ever wondered why classes in compiler construction or language design barely mention the existence of context-sensitive grammars, it's because of messy issues like these.)
• The Entity Declared VC can't be tested, because it also requires breaking that lexical layering boundary! There's also another issue: the VC wording (and seemingly intent) is ambiguous. (This is still true in the "Second edition" XML spec.) Since there is a WFC of the same name, everyone's life would be easier if references to undeclared parsed entities were always well formedness errors, regardless of whether they're parameter entities or not. (Note that nonvalidating parsers are not required to report all such well formedness errors if they don't read external parameter entities, although currently most XML parsers read them in an attempt to avoid problems from inconsistent parser behavior.)

The second category of limitations on this validation represent constraints associated with information that is not guaranteed to be available (or in one case, is guaranteed not to be available, through the SAX2 API:

• The Unique Element Type Declaration VC may not be reportable, if the underlying parser happens not to expose multiple declarations. (Ælfred2 reports these validity errors directly.)
• Similarly, the Unique Notation Name VC, added in the 14-January-2000 XML spec errata to restrict typing models used by elements, may not be reportable. (Ælfred reports these validity errors directly.)

A third category relates to ease of implementation. (Think of this as "bugs".) The most notable issue here is character handling. Rather than attempting to implement the voluminous character tables in the XML specification (Appendix B), Unicode rules are used directly from the java.lang.Character class. Recent JVMs have begun to diverge from the original specification for that class (Unicode 2.0), meaning that different JVMs may handle that aspect of conformance differently.

Note that for some of the validity errors that SAX2 does not expose, a nonvalidating parser is permitted (by the XML specification) to report validity errors. When used with a parser that does so for the validity constraints mentioned above (or any other SAX2 event stream producer that does the same thing), overall conformance is substantially improved.