VAST 3.0 CompanionClickTracking for inline ads

[renatojf]

I noticed that the current schema is still on a _draft and it does not consider the <CompanionClickTracking> for inline ads. Is the schema something you guys will update for a final version? Should we use it as a validator to guarantee the format of the VAST 3.0 spec?

[aleksUIX]

Confirming the gap is real and still there.

vast3_draft.xsd defines two companion types, and CompanionClickTracking appears exactly once in the whole file:

• CompanionWrapper_type child elements: StaticResource, IFrameResource, HTMLResource, CreativeExtensions, TrackingEvents, CompanionClickThrough, CompanionClickTracking, AltText
• Companion_type (the InLine one) child elements: StaticResource, IFrameResource, HTMLResource, CreativeExtensions, TrackingEvents, CompanionClickThrough, AltText, AdParameters

So it is declared for wrapper companions and omitted for inline companions, while the 3.0 spec defines it for both.

Should we use it as a validator to guarantee the format of the VAST 3.0 spec?

Speaking as someone who has built VAST validation against these schemas: not on its own. This issue is one instance of a broader pattern where the VAST XSDs and the spec prose disagree, and the XSD is usually the one that is behind. Other open examples in this repo:

• VAST 4.2 missing notUsed event type #44, notUsed is in the 4.2 spec table but in no schema, including the 4.4 draft
• altText and hoverText Icon attributes missing from VAST 4.2 XSD #46, altText and hoverText on <Icon> are in the prose and in no schema
• NonLinearClickTracking in vast 4.2 is changed to only occur once #36, NonLinearClickTracking is capped at maxOccurs="1" in 4.2 while its own annotation says it is unbounded

A schema pass gets you well-formedness and structure, but it will accept tags the spec forbids and reject tags the spec permits. Anything doing conformance work ends up encoding the prose separately.

Happy to open a PR adding CompanionClickTracking to Companion_type in vast3_draft.xsd. The _draft filename is the awkward part, since it is not obvious whether the intent is to finalise that file or leave 3.0 as-is now that 4.x is current. If you can say which, I will match it.