Restrict BuildingSync@version to actual version

[macintoshpie]

Currently, the schema allows a user to select from a list of choices for the version attribute.

I would argue this doesn't make sense, why would version 2.3.0 of the schema allow a user to report that their instance document is x.y.z? E.g. why does our 2.3.0 schema allow a document to declare its version is 2.0.0-legacy?

Option 1:

• if @Version is present, it must equal the version of the schema you're validating against. If it's not present no worries (still a valid doc)

Option 2:

• @Version is required and it must equal the version of the schema you're validating against. If it's not present or is a different version it's an invalid document.

Option 3:

• if @Version is present in an instance, such as a.b.c, the schema, version x.y.z, asserts that x.0.0 <= a.b.c && a.b.c <= x.y.z. For example, a doc with 2.3.0 should be valid against schemas ranging from 2.0.0 to 2.3.0. This is more complex and we'd either have to use a pattern restriction (regex) to allow prerelease versions, or drop prerelease versions and do a simple min/maxincludes restriction.

[macintoshpie]

After thinking about this more, I think option 3 above (restricting from first major version to current schema) to be our best option because it allows other documents with the same major version to be validated. This does not solve the original problem of "saying the doc is 3.x while using 3.y features", but I think it's our best option.

BuildingSync makes frequent enough releases that I think it would be too inconvenient to restrict a version to a single value. But we should restrict to a major version.

[macintoshpie]

Thinking more about this, it turns out what we are currently doing (using enum for version) is probably the best option! Let's keep doing that 👍

However the version 3 schema should remove all older enums. Thus when first version is released that will be the only option in the enum

[JieXiong9119]

I think we are good to close this one.