VAST 4.4: xs:choice minOccurs=0 maxOccurs=unbounded on vastInLine_type / vastWrapper_type drops all child cardinality

[aleksUIX]

In vast_4.4.xsd on master, both vastInLine_type and vastWrapper_type wrap their children in:

<xs:choice minOccurs="0" maxOccurs="unbounded">

That compositor discards every cardinality constraint on the children it contains. The child elements still declare minOccurs="1", but inside a repeating optional xs:choice those values only govern a single selection, not the content model as a whole. The net effect is that all children become optional, all become unboundedly repeatable, and ordering is no longer constrained.

I do not think this was intended, but it may be a deliberate consequence of the CTV Ad Portfolio restructure, so I wanted to check rather than assume.

Reproduction

All three validate against vast_4.4.xsd as published on master:

xmllint --noout --schema vast_4.4.xsd empty-wrapper.xml

1. Empty <Wrapper/>: no AdSystem, no VASTAdTagURI, no Impression.

<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a"><Wrapper/></Ad>
</VAST>

2. Empty <InLine/>: no AdSystem, no AdTitle, no Impression, no Creatives.

<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a"><InLine/></Ad>
</VAST>

3. <AdSystem> repeated three times.

<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a">
    <InLine>
      <AdSystem>A</AdSystem>
      <AdSystem>B</AdSystem>
      <AdSystem>C</AdSystem>
    </InLine>
  </Ad>
</VAST>

Element order is also unconstrained, so <Impression> before <AdSystem> validates.

Comparison with 4.2

In vast_4.2.xsd, Wrapper_type extends AdDefinitionBase_type and both use xs:sequence:

Type	Compositor	AdSystem	Impression	VASTAdTagURI
4.2 AdDefinitionBase_type	xs:sequence	1..1	1..unbounded	n/a
4.2 Wrapper_type (extends above)	xs:sequence	inherited 1..1	inherited 1..unbounded	1..1
4.4 vastWrapper_type	xs:choice 0..unbounded	effectively 0..unbounded	effectively 0..unbounded	effectively 0..unbounded

The same empty <Wrapper/> correctly fails against 4.2:

Element '{http://www.iab.com/VAST}Wrapper': Missing child element(s). Expected is ( {http://www.iab.com/VAST}AdSystem ).

So 4.4 is currently more permissive here than 2.0 through 4.2, and an empty ad container is schema-valid for the first time.

Why it matters

Impression has been required on wrappers since 2.0. Anything using the XSD as a gate (ad server ingest checks, QA tooling, partner certification) will now pass 4.4 wrapper responses that cannot possibly deliver or measure an ad. It also interacts with issue #40 and the wider question of whether the XSD is meant to be usable as a validator, which came up there.

Possible direction

If the goal was "these children may appear in any order", xs:all expresses that while preserving per-element cardinality. XSD 1.0 restricts xs:all to maxOccurs="1" per particle, so repeating elements like Impression would need handling, but it keeps the required ones required. If the goal really was a fully open content model, then the prose and the schema have diverged and it would be worth saying so explicitly in the annotation.

Happy to open a PR against the 4.4 draft with a xs:all based content model for both types, or with a minimal change that just restores required AdSystem / Impression / VASTAdTagURI on vastWrapper_type, whichever direction the group prefers.

Checked against vast_4.4.xsd at master on 2026-08-09, validated with xmllint (libxml2).

[aleksUIX]

Correcting myself on the xs:all suggestion above, and adding the tradeoff matrix, because I do not think there is a free fix here.

xs:all does not work. XSD 1.0 restricts every particle inside xs:all to maxOccurs="1", and Impression has been 1..unbounded on wrappers since 2.0. Validators silently enforce the cap rather than rejecting the schema, so it fails at exactly the wrong moment:

Element 'Impression': This element is not expected.

That is a second <Impression> being rejected against an xs:all variant. So scratch that option.

I also tried the obvious hybrid, pulling the required elements into a leading xs:sequence and leaving everything else in the order-free xs:choice:

<xs:sequence>
  <xs:element name="AdSystem"     type="vastAdSystem_type"/>
  <xs:element name="VASTAdTagURI" type="vastURIElement_type"/>
  <xs:element name="Impression"   type="vastImpression_type" maxOccurs="unbounded"/>
  <xs:choice minOccurs="0" maxOccurs="unbounded">
    <!-- Error, Pricing, ViewableImpression, AdVerifications, Creatives, Extensions -->
  </xs:choice>
</xs:sequence>

That correctly rejects the empty wrapper and the wrapper with no Impression. But it introduces a new break: in 4.2 the order is AdSystem, Error, Extensions, Impression, Pricing, ViewableImpression, AdVerifications, BlockedAdCategories, Creatives, VASTAdTagURI, with VASTAdTagURI last. Under the hybrid, a wrapper written in 4.2 order fails, because VASTAdTagURI now has to appear third. Trading one compatibility break for another does not seem like an improvement.

The options, as far as I can tell

Content model	Rejects empty <Wrapper/>	Impression can repeat	Order-free	4.2-ordered docs still valid
xs:choice minOccurs="0" maxOccurs="unbounded" (current)	no	yes	yes	yes
xs:all	yes	no	yes	yes
Hybrid xs:sequence + xs:choice	yes	yes	partial	no
Full xs:sequence, 4.2 order plus the new 4.4 children	yes	yes	no	yes

Only the last row is free of new breakage, and it gives up the order independence that the xs:choice presumably existed to provide.

So the question is really: was order independence an intentional goal for 4.4, or a side effect?

• If it was a side effect, the last row is the fix and I am happy to write it, keeping the 4.2 ordering and slotting the new children in.
• If it was intentional, then XSD 1.0 cannot give both, and the honest move is to say in the annotation that the 4.4 schema is a vocabulary rather than a content model, so nobody builds an acceptance gate on it expecting otherwise. Moving to XSD 1.1 would allow xs:all with repeats, but that is a much larger decision about tooling support.

I held off opening a PR because the three viable directions are not equivalent and the choice is yours rather than mine. Say which one you want and I will send it.

Verified with libxml2 against vast_4.4.xsd at master and vast_4.2.xsd, 2026-08-09.