Ship an XSD for testng.xml alongside the DTD, and keep the two from drifting

[juherr]

Part of #3317. Supersedes #2594, whose schema is worth salvaging even though the branch is not.

Why now rather than in 2021

#2594 added an XSD but never wired it to anything: it shipped as a resource and was consumed only by a Kotlin test. Meanwhile validation itself was dead — XMLParser probed the SAX validation feature under an https identifier no parser recognises, so setValidating(true) was never reached. That is fixed in #3315, and the DTD is now genuinely enforced (warn by default). Only now does the choice of schema language actually change anything for users.

What to salvage

The XSD in #2594 is materially better than the Trang dump in #3240: attributes are typed, enumerations are hoisted into named simpleTypes reusable between suite and test, and the DTD prose is converted into real xsd:documentation. Extract it with gh pr diff 2594 --patch rather than reusing the branch, which is 494 commits behind and conflicts throughout — most of its diff is an unrelated rename of ~120 test resources, which is what actually killed it.

Scope

• Update the schema: drop junit (removed from master since), add use-global-thread-pool and share-thread-pool-for-data-providers.
• No targetNamespace. Add XSD file for validation #2594 added one without adding xmlns to any suite file, which makes a namespace-aware validator unable to resolve <suite> — almost certainly why its data provider was red. A namespace is a breaking change for every existing testng.xml and is reserved for a future 2.0 of the schema.
• Settle the cardinality question left open in review on Add XSD file for validation #2594: listeners / packages / method-selectors / suite-files should not be repeatable, and groups should join the choice so that validation stops depending on element order. That ordering constraint is the one real incompatibility the DTD imposes — it is why testng-all.xml had to be reordered in fix(xml): re-enable DTD validation and stop losing data in toXml() #3315, and it is what would bite users if the default moved to strict.
• Ship the XSD next to the DTD. The DTD stays authoritative for files carrying a <!DOCTYPE>; the XSD becomes the contract the corpus test validates against and something IDEs can complete from.
• Add a consistency test: the whole corpus must validate under both schemas. The two have already drifted once — the writer advertised testng-1.0.dtd while the reader always resolved testng-1.1.dtd (fixed in fix(xml): re-enable DTD validation and stop losing data in toXml() #3315).

Done when

• Every suite file in the corpus validates against both the DTD and the XSD.
• The serialized output of toXml() validates against the XSD, as it already must against the DTD.
• Add XSD file for validation #2594 is closed with a pointer here.

Note there is no need to rename or move any test resource for this. That is the mistake to avoid repeating.

[juherr]

Implemented, on top of #3315. Two points where the implementation deviates from the issue, both deliberate.

The cardinality bullet cannot be implemented as written

listeners / packages / method-selectors / suite-files should not be repeatable, and groups should join the choice so that validation stops depending on element order.

Those two halves are mutually exclusive in XSD 1.0, which is the only level stock JAXP supports. Order-independence over a set that also contains the repeatable test and parameter requires <xsd:choice maxOccurs="unbounded">, and that model cannot bound any of its branches to one occurrence; <xsd:all> is the construct that could, but XSD 1.0 forbids maxOccurs="unbounded" inside it. Expressing both would mean enumerating the interleavings of five singletons, which is not a schema anybody should have to read.

So it is one or the other, and this ships the ordering constraint as the DTD has it. Relaxing the order instead would have cost two things:

• xml/validation/wrong-element-order.xml, the fixture fix(xml): re-enable DTD validation and stop losing data in toXml() #3315 added to prove validation is wired in at all, becomes valid — the invalid fixture would have to be replaced by one violating something else;
• the DTD's groups? is what caught toXml() emitting two sibling <groups> elements (also fixed in fix(xml): re-enable DTD validation and stop losing data in toXml() #3315). Widening it to groups* gives that bug its silence back.

The ordering trap is real and still open. It is a change to the DTD, not to the XSD, and it deserves its own issue rather than being smuggled in behind a new file.

Everything else, as scoped

• No targetNamespace, and no elementFormDefault either — it is dead weight without a namespace. No suite file in the corpus declares an xmlns.
• junit dropped, use-global-thread-pool and share-thread-pool-for-data-providers added.
• Named simpleTypes reused between suite and test, DTD prose as xsd:documentation.
• Named testng-1.1.xsd, not testng-1.0.xsd: it mirrors the DTD the reader actually resolves.
• No test resource renamed or moved.

Three places where #2594's schema would have rejected files the DTD accepts, found by running it against the corpus rather than by reading it:

• <run> and <package> were a sequence; the DTD writes (include?,exclude?)* and testng-all.xml has a <run> with <exclude> before <include>.
• The ANY elements were tightened. <parameter> appears inside <suite-file> (parametertest/issue_581/parent_suite.xml) and inside <include> (yaml/1787.xml).
• (true | false) was mapped to xsd:boolean, which also accepts 0 and 1 — quietly looser than the DTD it mirrors. It is a named simpleType here.

Drift

Two tests, because neither alone is enough:

• XsdValidationTest validates every suite file of the corpus and every toXml() output under the XSD, mirroring what fix(xml): re-enable DTD validation and stop losing data in toXml() #3315 asserts under the DTD, plus a negative test that the DTD-invalid fixture is rejected by the XSD too. Without that last one a schema matching everything would pass the first two — which is exactly how DTD validation stayed dead for years.
• SchemaConsistencyTest compares the declarations directly: element names, attribute names, requiredness, default values, enumerated values. Content models are left out and the class says so; they are covered from the other end by the corpus.

Worth recording, since it is the kind of thing that makes a schema look wrong when it is not: Validator.validate(SAXSource) overwrites the entity resolver of the reader it is given. The first run therefore fetched the published testng-1.0.dtd over the network, which still declares junit, and 224 corpus assertions failed against a correct schema. Validating with the schema attached to the parser (DocumentBuilderFactory.setSchema, as JUnitReportsTest already does) keeps the resolver.

Not here

An OASIS XML catalog in the jar, so external tools resolve the DTD offline: #3324.