Backward compatability for VAST 2.0?

[wroberts15]

Hello again,

Just wondering if when I specify vast version 2.0 if that is actually doing anything/generating a vast document that is compatible with 2.0. I'm just wondering that if I'm overwriting the version - e.g.
var VAST = require('vast-xml')
, vast = new VAST({version : '2.0'});

• which is correctly displaying in the generated vast xml -
  if this is actually doing anything to prevent nodes that may be only available in vast 3.0?

Great package btw.

[tbuchok]

I don't remember the answer to that out of office right now. but good point -- we should probably throw on non2.0 method calls when in "old 2.0 mode" ... =

[wroberts15]

Are there any nodes that are automatically added on that are not available in 2.0 (maybe wrapper)? I tried searching on vast 2.0 vs 3.0 and couldn't find anything definitive.

[tbuchok]

come to think of it, vast 3.0 is meant to be backward compatible with vast 2.0 -- so a given feature should simply be ignored. detection and limiting by "version" might not be necessary.

did you have an actual issue come up, or just for discussion? it might be interesting to try to validate a vast 3.0 file against the vast 2.0 xsd schema. if that works, then i think we could close this.

nothing is automatically added that i can think of -- but wouldn't rule it out. there's features of 3.0 that simply don't "exist" in VAST 2.0.

[wroberts15]

It's definitely backwards compatible but I can think of one issue as of right now that may occur.

Say for example a node or a tracking event that is not present in 2.0 is specified and version is specified as 2.0 - Will that break a player/will it be rejected because it sees a node/feature unavailable in 2.0 and the version is 2.0 and for some reason cannot handle it?

[tbuchok]

ah, not sure. i think the validator would break, yea.

let's leave this issue open until we fix it. first step is to fail the case you mentioned (if it fails), then to get it to pass or throw hard when in "version 2.0" mode and adding a 3.0+ feature, as you mentioned.

[tbuchok]

first things first, looks like validating a "valid" vast 3.0 file doesn't pass 2.0 xsd validation:

pull the latest master, i just committed the 2.0.1 xsd

$ xmllint --noout --schema test/files/vast_2.0.1.xsd test/files/linear.xml

that should error. so based on your original thought: i agree that a "2.0" object that tries to do 3.0 features gets an error message (or i think i'd prefer we actually throw the error).

any thoughts?