XML Parser Recovery Behavior After Well-Formedness Errors Lacks Standardization

Portable Error Recovery Across XML Parsers

The XML 1.0 specification (Fifth Edition, Section 2.1) mandates that a well-formedness error is fatal and the processor must not continue normal processing. Despite this requirement, widely used parsers including Xerces, libxml2, and MSXML provide non-standard recovery modes that attempt to continue parsing after such errors.

Applications that need to process potentially malformed XML from external sources often enable these recovery flags (for example, Xerces continueAfterFatalError or libxml2 XML_PARSE_RECOVER) to avoid complete parse failure. However, the resulting document trees, error reporting, and heuristic decisions differ significantly between implementations, and no standard API or configuration exists to control recovery behavior.

This implementation-defined variance creates portability risk when switching parsers or upgrading parser versions, and recovery modes may produce trees that do not correspond to any well-formed XML document, potentially violating downstream validation or business logic.

Open Questions

• What criteria should guide the decision to enable parser-specific recovery versus rejecting malformed input outright in a security-sensitive context?
• How can an application detect and mitigate behavioral differences when the same malformed document is processed by different parsers in recovery mode?
• Are there emerging conventions or de facto standards among major parser vendors that reduce the portability gap for common error patterns?