Versioning

Since each OVAL Definition is validated against the OVAL Language, some sort of version information is needed to ensure that the correct version of the language is used for validation. This is necessary as older content may no longer validate against newer versions of the language, and recent content may not validate against previous versions of the language. The language version also helps tools identify the OVAL content that they can process correctly.

The three different categories of the OVAL Language (Definitions, System Characteristics, and Results) each contain multiple files, making versioning a challenge. Changes in one category will usually result in similar changes to the other categories, while changes within a component schema do not normally result in changes to the other component schemas. This dynamic brings up the question: If there is a change to the Windows schema, should the version of the Red Hat schema change?

Accepted OVAL Ideology

Single-Point Version

The accepted OVAL ideology for language versioning is a combination of the single language version and the point system. Every schema file is bound by the same version number as in the "Single Language Version" approach but the version contains both a major and minor component. These major and minor components are what allow changes to the schema to be classified as either major or minor. For example, the addition of a test in the Solaris component schema will cause a version change to every schema file but because the addition of a test does not invalidate existing content, then only the minor portion of the version will increment. More detail about what constitutes a major version change and a minor version change is described later in this document.

There is some concern that the accepted ideology forces users to update all of their schema files when a new version is released, even if it is only a minor release, affecting a component schema that they currently do not use. This is a valid concern and although no mitigation strategy exists it is worth noting that it is standard practice with the release of new versions of programming languages, such as C or Java, that developers retrieve the entire language regardless of the extent or location of changes made.

Balancing this concern is the simplicity gained by having a single language version for the collection of files in the OVAL Language, making it easier for the OVAL Community to track the changes made to the OVAL Language. Note that another advantage of this ideology is that it mitigates the disadvantage of the point system that required storing all of the versions associated with the different schema files in the definition.

What Constitutes a Language Version Change

Whenever a modification is made to the OVAL Language, the version of all the schema files must change. Modifications that do not invalidate OVAL Content that were written for previous versions of the current major release, result in a minor version change. Meanwhile, modifications that do invalidate older content result in a major version change.

For example, the addition of a new component schema, a new test in an existing schema, or even a new child element in an existing test, do not invalidate the content according to the previous major version release of the language, and therefore result in a minor version change. By contrast, the deletion of an existing test or the renaming of an existing attribute, will invalidate previously written content, and therefore, will result in a major version change.

There are cases where a major version release can be deferred. This could be done by changing the inner-workings of a test in a minor release while still supporting the previous version of the test, or by creating a new version of the test with a different name. This technique is used frequently in programming APIs where a new version of the API will be written with '_ex' or some other moniker appended to the original name. The original API is still available, but developers are encouraged to use the new extended version. This same technique can be used with the OVAL Language although use of the new test will not only be encouraged, it will be forced at the next major release of the language. Each initial major release will remove all old versions of tests and rename the newer version back to the original name. This policy will be in place to keep the meaning of the names given to elements significant and not full of outdated names that have been passed down from previous versions.

Differentiating Language Versions via Namespace

To differentiate content that has been written in previous versions of the language, the language major version will be represented in the namespace associated with the schema. For example the core definition schema might have a namespace of "http://oval.mitre.org/XMLSchema/oval-4" and the Windows definition schema might be "http://oval.mitre.org/XMLSchema/oval-4#windows".

By including the major version in the namespace, tools will be able to identify the correct major version of the language to use in validation, and therefore be able to support multiple major versions of the language at the same time.

Only the major version is included in the namespace, since including the minor version would cause all existing content to become invalid with the release of a new minor version. In addition, any namespace aware application would break with the release of a new minor version forcing tool vendors to update their code.

Minor versions of the language are differentiated using the schema_version element found in an instance document. This does mean that any application trying to determine the correct minor version will have to first parse the XML document, causing a potential performance penalty.

Previous Solutions

This section is intended to provide a discussion about the different approaches to language versioning that have been tried and/or thought about in previous versions of OVAL. Each approach is presented with a set of advantages and disadvantages. The hope is that by documenting the previous solutions, similar mistakes can be avoided in the future.

Single Language Version

One idea for language versioning was to use a single version for the entire OVAL Language and when a change is made to any of the component schemas, regardless of the language category, the version of all the schema files are updated. For example, if the current language is at version 2 and a new Windows test is added to the OVAL Definition schema, the version for each and every individual schema within the OVAL Language (including the Red Hat Systems Characteristics schema and the Debian core schema) would change to version 3.

The argument for a single language version was that when dealing with XML validation, the content either validates or does not validate, so there is no difference between major and minor changes. Unfortunately, this was not a good argument as there are changes, specifically additions to the language, which do not invalidate existing content.

An advantage of this approach is its simplicity. There is only one version number, which is very easy to track and manage from a project standpoint. Therefore, a tool is not required to account for all the versions of the different schema files that make up a definition. For example, a Windows definition would not have to maintain the core schema version and the Windows schema version required to validate it. A single version also makes it easy for tools to determine if they can talk to each other: "Do you speak Version 2? Yes. Great!"

If the advantage to the single language version approach is its simplicity, then it is also its main disadvantage. The biggest issue becomes how to update the existing language with new tests and how to add new component schemas. With a single language version, any addition would require movement to a new language version. Unfortunately, due to the nature of the language, the rapid changes that are made within computer software, and the community-based development effort, this would cause new versions to be made too frequently. Most of the time, the changes would not affect existing content, as the addition of a new test would not cause existing OVAL Definitions to be invalid. Many members of the community argued that because of this, a small change should not have such a global effect on the language version.

In addition, modifications to only one of the language categories, e.g., the System Characteristics schema, but not to the others would still result in a new version of the other categories. OVAL Community members or tools that are only concerned with OVAL Definitions will be confused when a set of definitions becomes invalid, even though no change has been made to the OVAL Definition schema. Why does my tool have to be upgraded to a new OVAL Language version when nothing has changed?

In short, the single schema version plan would require a number of version changes. It is a reality that rapid, global version changes will not be understood by the community and will give the impression of an unstable language.

Point System

Another approach considered for versioning the OVAL Language has been called "The Point System." Here, the core schemas from the different categories are given the same integer version number - for example, version 2. As part of the major version of the schema, each component schema will be given a minor version number. Note that the same minor version is shared by the corresponding component schemas in the different categories. For example, the initial release of version 2 of the OVAL Language will contain version 2.0 of the Windows component schema. If there is a modification to the Windows component schema, then the new version in all language categories will be 2.1. The other component schemas (Red Hat, Apache, etc.) will remain at version 2.0. If the core schema is updated to version 3, then all the component schema versions are updated to 3.0.

The major version of the OVAL Language advances when a change is made to any part of the schema files that would invalidate any existing content. Changes to the schema files that do not invalidate previous content (for example, the addition of new tests) will cause a minor version change to the specific component schema in which the change is made. Since the core schema has only a single version number and not a pointed number, any change (including additions) to the core schema files will require a major version change.

The advantage to this approach is that language changes that do not invalidate the current content (e.g., inclusion of a new test) would not require an update of the major version and would instead represent a minor version change. The major version number only changes when there is a change to the core schema, or when a component schema changes in such a way that it invalidates the existing OVAL content.

This allows OSs and applications to be less bound by the release schedule of the OVAL Language. New OS and application versions that require new OVAL Tests can add them and force only minor version changes within their specific component schema. Also, if an existing test needs to be modified, which would normally require a major version change, a new copy of this test can be created instead and given a new name (e.g., new_registry_test) while keeping the original test in the schema. This is similar to how new APIs are added to programming languages.

The potential problem with this approach is that it may cause some confusion among the OVAL Community about why the Windows definitions use version 2.1 and the Solaris definitions use version 2.2, when the OVAL Web Site states that the current language version is 2. With proper knowledge of the OVAL Language and help pages on the OVAL documentation, this concern can be mitigated.

Another more significant drawback is depending upon the rate at which minor changes are released, this could require tools to track numerous versions of language against definitions written for those versions. For example, a tool would need to keep track of the versions of the core schema files, the Windows component schema files, the Oracle component schema files, and so on.

Dated Version

This option has a single major version attached to the core schema files and uses a date string to version the component schemas. It is similar to the point system described in the previous section, and suffers from the same set of drawbacks. The only added benefit is that the date at which the schema was modified becomes evident by looking at the version.

Page Last Updated: June 13, 2006