VMAP and DAAST Validation Just Landed in vastlint Core

If you work in video or audio ad serving, you have met VAST: the IAB XML template that tells a player what ad to show and where to fire tracking. But VAST rarely travels alone. It usually arrives wrapped in a schedule (VMAP) or shows up with an audio sibling (DAAST), and those two formats break in production just as often as VAST does, with far less tooling watching them.

vastlint is an open-source, Rust-based linter for IAB ad tags. As of 0.5.0 it validates VMAP 1.0 and DAAST 1.0 alongside VAST 2.0 through 4.3, from the same CLI, library, and MCP server. The catalog is now 182 rules, 53 of them new for these two formats.

What shipped

There is nothing new to install or wire up. The same validate() entry point that handles a VAST tag now recognises a <vmap:VMAP> or <DAAST> root and routes the document to the right rule chain:

24 new VMAP 1.0 rules: ad-break structure, timeOffset / breakType / repeatAfter formats, <AdSource> content constraints, CDATA requirements, VMAP tracking events, and conflict detection.
29 new DAAST 1.0 rules: required <Category>, audio MediaFile attributes, <AdInteractions>, the DAAST tracking event set, audio pricing models, and detection of VAST elements that do not belong.
A new document_type field on the result (Vast, Vmap, or Daast) so you always know which chain ran.

Every rule keeps the vastlint contract: a stable ID, a default severity, a spec reference, and a docs page with examples and fix guidance.

VMAP: the where and when of ad breaks

VMAP (Video Multiple Ad Playlist) is the IAB standard a content owner uses to describe ad-break structure when they do not control the player. It was published on July 19, 2012 and has had exactly one version since. The mental model: VMAP handles the where and when of ad placement (pre-roll, mid-rolls at specific offsets, post-roll), and VAST handles the what (the creative inside each break).

A VMAP document is a playlist of <AdBreak> elements. Each break carries a timeOffset, a breakType, and an <AdSource> that either embeds a VAST document inline, points at an ad tag URI, or carries custom data. That flexibility is exactly where it breaks.

Here is a VMAP snippet that looks fine and is not:

<vmap:VMAP xmlns:vmap="http://www.iab.net/videosuite/vmap" version="1.0">
  <vmap:AdBreak timeOffset="15:00" breakType="linear">
    <vmap:AdSource id="mid-1">
      <vmap:AdTagURI templateType="vast3">
        https://ads.example.com/vast?cb=[CACHEBUSTER]&pos=mid
      </vmap:AdTagURI>
    </vmap:AdSource>
  </vmap:AdBreak>
</vmap:VMAP>

vastlint reports:

VMAP-1.0-adbreak-timeoffset-format (error): timeOffset="15:00" is not a valid hh:mm:ss[.mmm], n%, start, end, or #m value. The mid-roll will not schedule where you think.
VMAP-1.0-adtaguri-cdata (error): the AdTagURI contains an unescaped ampersand and is not inside a CDATA block, so the document stops being well-formed the moment the macro expands.

The best part: when an <AdSource> embeds VAST inline, vastlint validates that VAST with the full VAST rule chain and reports issues with /VMAP/AdBreak[i]/AdSource/VASTAdData paths plus document-absolute line and column. A wrapper problem two levels deep points straight at the break it lives in.

Common VMAP failures vastlint catches:

Malformed timeOffset that silently drops a break.
An <AdSource> with more than one payload, or none (the spec requires exactly one of <VASTAdData>, <AdTagURI>, or <CustomAdData>).
AdTagURI / CustomAdData not wrapped in CDATA.
Structurally invalid VAST inside a structurally valid VMAP.
repeatAfter that has no effect because timeOffset is start or end.

DAAST: deprecated, but the tags did not go away

DAAST (Digital Audio Ad Serving Template) is the audio counterpart the IAB released for public comment in 2014. It mirrors VAST 3.0 but swaps video assumptions for audio ones: <Category> is required, creatives carry audio MediaFiles, <VideoClicks> becomes <AdInteractions>, and the tracking event set is audio-specific.

Here is the catch: DAAST 1.0 is formally deprecated. In November 2018 the IAB merged audio support into VAST 4.1 via an optional adType attribute on <Ad>, and the recommendation since then is to serve audio with VAST 4.1 or later.

So why validate DAAST in 2026? Because the money never stopped and neither did the legacy tags. IAB and PwC put US digital audio ad spend at $8.4 billion in 2025, up 10.2% year over year, with podcast revenue alone growing 17.6% to roughly $2.9 billion. A market that large still has long-lived DAAST inventory and ad-server templates in circulation. When a DAAST tag shows up, you want to know whether it is clean, a DAAST document with VAST leftovers, or a VAST tag someone mislabeled.

Here is a VAST tag pretending to be DAAST:

<DAAST version="1.0">
  <Ad id="audio-1">
    <InLine>
      <AdTitle>Morning drive spot</AdTitle>
      <Impression><![CDATA[https://t.example.com/imp]]></Impression>
      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:30</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4">
                <![CDATA[https://cdn.example.com/spot.mp4]]>
              </MediaFile>
            </MediaFiles>
            <VideoClicks>
              <ClickThrough><![CDATA[https://example.com]]></ClickThrough>
            </VideoClicks>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</DAAST>

vastlint's verdict:

DAAST-1.0-inline-category (error): <Category> is required in DAAST and is missing.
DAAST-1.0-mediafile-audio-type (warning): the MediaFile type is video/mp4 on an audio creative.
DAAST-1.0-videoclicks-element (warning): <VideoClicks> is a VAST element; DAAST uses <AdInteractions>. This is the tell that the tag was lifted from a video flow.

Other DAAST-specific checks include the <AudioInteractions> to <AdInteractions> rename, audio pricing models (DAAST adds cpo to the usual cpm / cpc / cpe / cpv set, and requires model plus currency), required <DAASTAdTagURI> on wrappers, and [ERRORCODE] macro presence so failed audio impressions are reportable.

Why this belongs in core, not a separate tool

Ad ops teams do not deal with one format at a time. A single campaign can ship a VMAP schedule whose breaks wrap VAST 4.x creatives, while the audio line item delivers a DAAST tag. Asking people to remember which validator handles which format, and to paste tags into three different web tools, is how broken tags reach production.

Putting all three formats behind one entry point removes that decision. You hand vastlint a document, it tells you what the document is, and it validates it against the right spec with consistent rule IDs and severities. One engine, one report format, three formats covered, and it runs everywhere you already run vastlint:

CLI: validate VMAP and DAAST files in a pre-flight step or a git hook.
Library: call validate() and branch on document_type; the result shape is identical across formats.
CI: gate merges so a malformed timeOffset or a DAAST tag with VAST leftovers never reaches a release.
MCP server: an AI agent doing campaign QA can validate a playlist or an audio tag through the same tool surface it uses for VAST.

Try it

Paste a VMAP playlist or a DAAST audio tag into the validator at vastlint.org/validate. It detects the document type and returns every issue with a rule ID, severity, and the exact fix, the same way it does for VAST. vastlint is free and open source: github.com/aleksUIX/vastlint.

推荐订阅源

DEV Community