Mihaela Mihaljevic
6a7bf78903
An element restricting a base choice was always checked by the
effective-total-range approximation, which exists for one reason: the
literal section 3.9.6 pairing has no allowance for occurrence counts
accumulated across the choice's own repetitions and over-rejects
W3C-read-valid schemas (particlesZ001, whose manifest calls the rule
ambiguous). That ambiguity is impossible when the choice cannot repeat:
at {max occurs} = 1 every accepted child comes from one traversal of one
branch, so the literal rule governs. elementRestrictsChoice now applies
the literal pairing (the derived element, with its own occurrence range,
must validly restrict some non-pointless branch) when base maxOccurs is
1, and keeps the effective-range reading only for repeating choices.
Closes XSTS particlesHa161 (a derived a{0,1} is not a pointwise
NameAndTypeOK restriction of a required branch a{1,1}) and particlesM034
(a derived d1+ cannot map into the branch (d1*, d2+): the required d2 is
unmapped and not emptiable). The settled-valid neighbors that pin the
boundary from the other side all still pass: Ha160, M002, M003, M035,
and the Z001 shape, each now a regression test in
XSDParticleChoiceRestrictionTests. invalid-schemas-accepted 6 -> 4.
particlesIg004 is reclassified as spec-divergent (4 -> 3): section 3.3.2
maps block="#all" and the explicit substitution/extension/restriction
list to the SAME {disallowed substitutions} set, so NameAndTypeOK clause
5's superset requirement holds and the invalid expectation has no spec
path; it is jointly unsatisfiable with the settled Ig001/002/003 (equal
sets, valid) and Ig005 (#all covers the triple, valid).
The remaining three schema deviations are documented divergences, not
open bugs: Ik025/Ik027 (cos-st-derived-ok 2.2.4 reading) and schN12,
newly adjudicated in docs/xsts-deviations.md: its chameleon redefine
fails src-redefine 6.2.2 on NameAndTypeOK clause 1 (no-namespace locals
vs qualified locals), but 6.2.2 cannot be enforced uniformly because
mgO013's settled-VALID schema also violates it; any uniform enforcement
trades a false negative for a valid-schema-rejected false positive.
Also corrects the stale deviations-doc row that listed the already-closed
particlesIk011 and omitted schN12; the failures file is the authority.
Gates: full XSTS release suite green at 0/3/0/4 (valid buckets unchanged
at zero), libxml2 differential green at 244 pinned entries (Ha161 and
M034 newly pinned, both compile under libxml2), full local gate green.
101 lines
7.0 KiB
Swift
101 lines
7.0 KiB
Swift
import Testing
|
|
@testable import PureXML
|
|
|
|
/// The suite exclusions: tests whose expected validity is not authoritative,
|
|
/// mirroring how the suite's own `status="queried"` entries are skipped. Kept in
|
|
/// their own file so each entry's spec-grounded justification has room to be full.
|
|
extension XSTSSuiteTests {
|
|
/// Instance tests excluded from the counts because their expected validity is not
|
|
/// authoritative, mirroring how the suite's own `status="queried"` entries are
|
|
/// skipped. Each must carry a spec-grounded justification; this is never a place to
|
|
/// hide a real deviation.
|
|
///
|
|
/// - `anyURI_a004_1339.i`: the suite pairs a `valid` schemaTest with an `invalid`
|
|
/// instanceTest, but the two are mutually inconsistent. The schema's `include`,
|
|
/// `import`, and `redefine` have unresolvable schemaLocations; XSD 1.0 §4.2.1
|
|
/// makes an unresolvable `include` "not an error" (no inclusion performed), the
|
|
/// `import` likewise, and the empty `redefine` imposes no resolution requirement
|
|
/// (`src-redefine` clause 1 gates that on non-annotation children), so the schema
|
|
/// is conformantly valid (agreeing with the schemaTest). The only components the
|
|
/// instance exercises (`root`, `bar`, `st`, `att`) are fully locally defined, and
|
|
/// every instance value is byte-identical to one of the type's six anyURI
|
|
/// `enumeration` members, so a strict assessment of the document element is
|
|
/// valid. There is no spec path to valid-schema + invalid-instance. Confirmed by
|
|
/// two independent adversarial analyses; libxml2 is no authority here (it
|
|
/// non-conformantly fails to compile the schema on the unresolvable include).
|
|
/// Matching the suite would mean rejecting a valid instance whenever an include
|
|
/// cannot be resolved, a false positive an IDE editing loop hits constantly.
|
|
///
|
|
/// - `schA2.i`, `schA5.i`: schema-location precedence. Each group's documentation
|
|
/// states the inline `xsi:schemaLocation` hint "is ignored" and the instance
|
|
/// "must conform to" the collection schema, but under exactly that prescribed
|
|
/// behavior the instances are valid (libxml2 validates schA2.xml against its
|
|
/// `a.xsd`, and schA5.xml against its `a.xsd`+`b.xsd` collection), so the
|
|
/// `invalid` expectation contradicts the group's own documentation. Reaching
|
|
/// `invalid` requires letting the instance's hint override a schema already
|
|
/// loaded for that namespace, which XSD 1.0 §4.3.2 makes optional (strategy 1:
|
|
/// "do nothing ... because a schema ... is already known") and which would be a
|
|
/// direct false positive for an IDE (an instance file forcing rejection against
|
|
/// the project's own schema). PureXML's policy (honor hints but keep the
|
|
/// collection's declarations on conflict) is conformant. Confirmed by an
|
|
/// adversarial analysis that separated these from schA7.i, whose `invalid` IS
|
|
/// spec-grounded (a genuine policy deviation, left in the count).
|
|
///
|
|
/// - `mgO013.i`: a `redefine` whose group `all{e1(1,1)}` redefines a base
|
|
/// `all{e1(0,0)}` without referencing itself. `src-redefine` clause 6.2.2 makes
|
|
/// that a restriction obligation, and `all{e1(1,1)}` is not a valid restriction
|
|
/// of `all{e1(0,0)}` (Occurrence Range OK: derived max 1 > base max 0), so
|
|
/// enforcing it rejects the schema, contradicting the `valid` schemaTest and
|
|
/// producing a valid-schema-rejected false positive. Yet §4.2.2 makes the type's
|
|
/// `group` reference resolve to the redefined `all{e1(1,1)}`, against which the
|
|
/// single-`e1` instance is valid. The `valid` schema and `invalid` instance
|
|
/// expectations are mutually exclusive; libxml2 accepts both. Confirmed by an
|
|
/// adversarial analysis that found no third path.
|
|
///
|
|
/// - `particlesZ001.i`: a `complexContent` restriction `Derived` of `Base`, with an
|
|
/// instance valid against `Derived`'s own content model. cvc-complex-type (§3.4.4)
|
|
/// validates an instance against the element's own `{content type}` and never
|
|
/// re-runs Particle Valid (Restriction) / RecurseAsIfGroup (§3.9.6, a schema-
|
|
/// assembly constraint), so schema-valid + instance-invalid is unreachable. The
|
|
/// manifest itself labels the governing rule ambiguous; libxml2 accepts both.
|
|
/// Reaching `invalid` would require rejecting the schema (a valid-schema-rejected
|
|
/// false positive) and would still fail the suite's own `valid` schemaTest.
|
|
static let specDivergentInstances: Set<String> = [
|
|
"anyURI_a004_1339.i", "schA2.i", "schA5.i", "mgO013.i", "particlesZ001.i",
|
|
]
|
|
|
|
/// Schema tests excluded from the counts for the same reason: the expectation is
|
|
/// not authoritative. Each entry must name the settled expectation it is jointly
|
|
/// unsatisfiable with; this is never a place to hide a real deviation.
|
|
///
|
|
/// - `particlesZ008`: byte-for-byte the same construct as `elemZ026` (an abstract
|
|
/// head element, a member via `substitutionGroup`, a base type whose sequence
|
|
/// references the head, and a restriction that references the member instead),
|
|
/// yet Z008's settled expectation is `valid` while elemZ026's settled expectation
|
|
/// is `invalid`, both accepted on the same date. One expectation must be wrong,
|
|
/// and the spec decides which: NameAndTypeOK (section 3.9.6, Elt:Elt) clause 1
|
|
/// requires the declared {name}s and {target namespace}s to be the same, and no
|
|
/// clause grants substitution an allowance in particle restriction, so the member
|
|
/// swap is invalid and Z008's `valid` has no spec text behind it (its annotation
|
|
/// asserts "should be valid" without citing one). The schema is still compiled
|
|
/// so the group's instance tests run; only its verdict is excluded.
|
|
///
|
|
/// - `particlesIg004`: NameAndTypeOK clause 5 with base `block="#all"` and derived
|
|
/// `block="substitution extension restriction"`, expected `invalid`. Section
|
|
/// 3.3.2 maps `#all` to the {disallowed substitutions} value
|
|
/// {extension, restriction, substitution}, the identical set the derived
|
|
/// element's explicit list maps to, so the two property values are EQUAL and
|
|
/// clause 5's superset requirement holds; there is no spec path to `invalid`.
|
|
/// The expectation is jointly unsatisfiable with the suite's own settled
|
|
/// treatment of the mapped property values: `particlesIg001/002/003` (equal
|
|
/// explicit sets, `valid`) and `particlesIg005` (explicit triple restricted to
|
|
/// `#all`, `valid`, which requires `#all` to cover the triple). Only a reading
|
|
/// where `#all` is a distinct value strictly larger than the complete explicit
|
|
/// set reaches `invalid`, and no such value exists in the 1.0 blockSet grammar
|
|
/// (`XSDDerivation` compiles `#all` to exactly that triple).
|
|
static let specDivergentSchemas: Set<String> = [
|
|
"particlesZ008",
|
|
"particlesIg004",
|
|
]
|
|
}
|