DTD default attributes missing after parser validation mode change

Question

We are preparing to migrate a small XML application to a newer parser without service interruption. The current pipeline validates documents against an internal DTD, and downstream logic relies on default attribute values declared in that DTD. The target parser documentation states that default attribute insertion occurs only during DTD validation, but it is not clear whether the new default configuration will preserve those attributes when validation is disabled or when XML Schema validation is used instead.

Because the migration must be transparent to consumers, we need to determine how to predict infoset changes for documents that depend on DTD defaults. We also need to know whether parser settings can retain default attribute injection without full DTD validation, or whether documents must be normalized before parsing.

Does the newer parser inject DTD default attributes in non-validating mode? If validation switches to XSD, are DTD-declared defaults omitted entirely? What comparison method reliably detects attribute differences between the old and new parser for these documents?

Zoha · Answer

Answer to the Question
When the newer parser is used in non‑validating mode, it does not insert the default attributes declared in a DTD. If you switch to XSD validation, the DTD is ignored entirely, and default attributes are omitted as well.
Confirmed Facts

Default attribute insertion occurs only during DTD validation.
In non‑validating mode the parser leaves those attributes absent.
When XSD validation is enabled the parser does not consult the DTD, so defaults are not added.

Likely Explanation
Some XML libraries expose a flag that forces DTD default insertion even when the parser is not validating. This behaviour is implementation‑specific and not guaranteed across all parsers. If your target parser offers such a flag, you could enable it; otherwise you must perform a DTD‑validated pass first.
Practical Steps for Migration

Identify the exact parser implementation and version you plan to use (e.g., Xerces‑J 3.2.0, libxml2 2.13.x, etc.).
Run a test XML that contains a DTD with a default attribute through the new parser in both non‑validating and DTD‑validating modes. Inspect the resulting DOM (e.g., using Element.getAttribute("name")) to confirm whether the attribute appears.
If DTD defaults are required without full validation, parse the XML with DTD validation, serialize the DOM back to XML, and feed that serialized document to downstream logic. This preserves the defaults while keeping the rest of the pipeline unchanged.
Alternatively, if the parser offers a “force‑DTD‑defaults” flag, enable it in non‑validating mode. Verify that the flag behaves as expected in your environment.

Comparison Method
To reliably detect attribute differences between the old and new parser, compare the infosets produced after parsing, not the raw text. A canonical approach is to use a DOM‑aware diff tool such as XMLUnit (Java) or a custom DOM comparison routine that normalises whitespace and ordering. The diff should report missing attributes, changed values, or element order changes that could affect downstream consumers.
What You Need to Verify
Before finalizing the migration, confirm the following:

Does the new parser expose a flag for DTD default insertion in non‑validating mode?
Is the DTD reachable (e.g., via a local copy) during the parsing pass?
Can you safely enable DTD validation without exposing XXE or other security risks?
Does the downstream logic tolerate the absence of the default attributes, or must the XML be normalised beforehand?

Once these checks are satisfied, you can proceed with confidence that consumers will receive the same attribute set as before.

DTD default attributes missing after parser validation mode change

1 answer

Answer to the Question

Confirmed Facts

Likely Explanation

Practical Steps for Migration

Comparison Method

What You Need to Verify

Your perspective belongs here.

0 question comments