Support later versions of STIX 2

[clenk]

We need to figure out how to support later versions of STIX 2 in the validator. It should probably default to the latest published version of the spec, with an option to set the version to validate against. People may want to validate against multiple versions of the spec if they are supporting multiple versions at once. Each version of the validator could have a maximum supported STIX version, or we could do something with subpackages like https://github.com/oasis-open/cti-python-stix2/issues/79. I'm leaning towards the latter.

[gtback]

I think you can have multiple git submodules that refer to the same repo (at different commits) for multiple copies of the JSON schemas. In terms of supporting multiple versions, the validator should:

• if validating a bundle, use the version specified in the bundle.
• validate against the most recent version by default (this means that we'll need a new major release for each STIX version, since behavior could be backwards-incompatible unless the specs are truly backwards compatible).
• Allow users to specify an explicit version via a command line argument or function parameter.

[clenk]

At first I was confused by "multiple submodules for the same repo" - now I understand you mean git submodules, not python submodules.

[gtback]

I updated my comment above to be a bit more clear 😀

[gtback]

@clenk: Do you think it's important to figure this out before we release a 1.0, in case it causes significant internal refactoring of the public API?

[clenk]

Yes, to be on the safe side I think so. I've been meaning to work on this for a while but haven't found the time.

EDIT: the "version-specific" stuff will mostly just be "which functions to call"

[gtback]

We'll need a major version bump anyway when we switch from validating STIX 2.0 by default to validating STIX 2.1 by default, so there's no reason this needs to be done prior to 1.0.