<xsd:schema targetNamespace="http://oval.mitre.org/XMLSchema/oval" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:oval="http://oval.mitre.org/XMLSchema/oval" elementFormDefault="qualified" version="4.2">
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="https://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<xsd:annotation>
<xsd:documentation>The following is a description of the elements, types, and attributes that compose the core schema for encoding Open Vulnerability and Assessment Language (OVAL) Definitions. The Core Definition Schema defines all operating system independent objects. These objects are extended and enhanced by individual family schemas, which are described in separate documents. Each of the elements, types, and attributes that make up the Core Definition Schema are described in detail and should provide the information necessary to understand what each object represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between these objects is not outlined here.</xsd:documentation>
<xsd:documentation>The OVAL Schema is maintained by The Mitre Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org.</xsd:documentation>
<xsd:appinfo>
<schema>Core Definition</schema>
<version>4.2</version>
<date>2 December 2005</date>
</xsd:appinfo>
</xsd:annotation>
<!-- =============================================================================== -->
<!-- =============================================================================== -->
<!-- =============================================================================== -->
<xsd:element name="oval">
<xsd:annotation>
<xsd:documentation>The oval element is the root of an OVAL Definition Document, and must occur exactly once. Its purpose is to bind together the four major sections of a definition - generator, definitions, tests, and variables - which are the children of the oval element. The generator section must be present and provides information about when the definition file was compiled and under what version. The optional definitions, tests, and variables sections define the specific characteristics that should be checked on a system to determine the truth value of the OVAL Definition Document.</xsd:documentation>
<xsd:documentation>The optional Signature element allows an XML Signature as defined by the W3C to be attached to the document. This allows authentication and data integrety to be provided to the user. Enveloped signatures are supported.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>none</parent_elements>
<child_elements>generator, [definitions], [tests], [variables], [Signature]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:generator" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:definitions" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval:tests" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval:variables" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:key name="definitionKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness amongst the OVAL ids differentiating the individual definition elements.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:definitions/oval:definition"/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:key name="testKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness amongst the individual test ids.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:tests/*"/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:key name="variableKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness amongst the individual variable ids.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:variables/oval:variable"/>
<xsd:field xpath="@id"/>
</xsd:key>
<xsd:keyref name="testKeyRef" refer="oval:testKey">
<xsd:annotation>
<xsd:documentation>Require each test reference in a criterion element to refer to a valid test id.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:definitions/oval:definition/oval:criteria/oval:*/oval:criterion"/>
<xsd:field xpath="@test_ref"/>
</xsd:keyref>
<xsd:keyref name="subtestKeyRef" refer="oval:testKey">
<xsd:annotation>
<xsd:documentation>Require each test reference in a subtest element to refer to a valid test id.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:tests/oval:compound_test/oval:subtest"/>
<xsd:field xpath="@test_ref"/>
</xsd:keyref>
<xsd:keyref name="variable_testKeyRef" refer="oval:variableKey">
<xsd:annotation>
<xsd:documentation>Require each variable referenced in an item element refers to a valid variable id.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval:tests/oval:variable_test/oval:item"/>
<xsd:field xpath="@variable"/>
</xsd:keyref>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================= GENERATOR ================================= -->
<!-- =============================================================================== -->
<xsd:element name="generator">
<xsd:annotation>
<xsd:documentation>The generator element is used to format information about when a particular OVAL Definition Document was compiled and what version of the schema was used. Note that the timestamp does not specify when a definition (or set of definitions) was created or modified.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval</parent_elements>
<child_elements>schema_version, timestamp</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:schema_version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:timestamp" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="schema_version" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>The schema_version element defines the version of the OVAL Schema that the document has been validated against.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>decimal</content>
<parent_elements>generator</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="timestamp" type="oval:timestamp">
<xsd:annotation>
<xsd:documentation>The timestamp element specifies the date/time at which the OVAL Definition Document was compiled. Note that the timestamp does not specify when a definition (or set of definitions) was created or modified. This timestamp can be used to differentiate between multiple OVAL files and to determine which document is the most up-to-date. The timestamp is a string in the form yyyymmddhhmmss.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>generator</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================ DEFINITIONS ================================ -->
<!-- =============================================================================== -->
<xsd:element name="definitions">
<xsd:annotation>
<xsd:documentation>The definitions element is a container for one or more definition child elements.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval</parent_elements>
<child_elements>definition</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:definition" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="definition">
<xsd:annotation>
<xsd:documentation>The definition element defines an actual OVAL Definition. It contains various metadata related child elements which describe the definition. This includes valid platforms, creation and modification dates, status information, and reference information. It also (unless the definition is deprecated) contains a criteria child element which joins individual tests together with a logical operator to specify the specific computer state being described.</xsd:documentation>
<xsd:documentation>The required id attribute is the OVAL-ID of the Definition. It has the form 'OVAL' followed by a number of digits (e.g. OVAL96). Like all ids in OVAL, it must be unique. OVAL-IDs are assigned by MITRE. The required class attribute indicates the specific class to which the definition belongs. Possible classes are: compliance, deprecated, patch, and vulnerability.</xsd:documentation>
<xsd:documentation>A definition is the key structure in OVAL. It is analogous to a logical sentence or proposition: if a computer's state matches the configuration parameters laid out in the criteria, then that computer exhibits the state described.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, class</attributes>
<content>none</content>
<parent_elements>definitions</parent_elements>
<child_elements>[affected], dates, description, [reference], status, version, [notes], [criteria]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:affected" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval:dates" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:description" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:reference" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="oval:status" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval:notes" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval:criteria" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="id" type="oval:definitionid" use="required"/>
<xsd:attribute name="class" type="oval:definitionclass" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="affected">
<xsd:annotation>
<xsd:documentation>Each OVAL Definition is written to evaluate a certain type of system. The family, platform(s), and product(s) of this target are described in the affected element whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help keep Windows definitions from being needlessly evaluated on a Red Hat machine. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section.</xsd:documentation>
<xsd:documentation>The required family attribute states the major category of operating system for which the definition is written. Each family has a corresponding family-specific definition schema which extends the Core Definition Schema.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>family</attributes>
<content>none</content>
<parent_elements>definition</parent_elements>
<child_elements>platform, [product]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:platformBase" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="oval:product" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="family" type="oval:families" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="platformBase" type="xsd:string" abstract="true">
<xsd:annotation>
<xsd:documentation>This abstract element details the specific platform(s) for which a definition has been written. It is extended by the individual family schemas to incorporate only the valid platforms for the specified family. The inclusion of a particular platform does not mean the definition is physically checking for the existence of the platform. For the actual test to be performed, the correct test must still be included in the definition’s criteria section. The valid platforms are outlined in the platform specific schemas.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>affected</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="product" type="xsd:string">
<xsd:annotation>
<xsd:documentation>This element details the specific application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the product element can be thought of as definition applying to all products. The inclusion of a particular product does not mean the definition is physically checking for the existence of the product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example 'Internet Explorer' and 'IE'. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-n</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>affected</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="dates">
<xsd:annotation>
<xsd:documentation>This element contains child elements to hold submission, modification, and status change dates associated with the definition.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>definition</parent_elements>
<child_elements>submitted, [modified], [status_change]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:submitted" minOccurs="1" maxOccurs="1"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="oval:modified"/>
<xsd:element ref="oval:status_change"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="submitted">
<xsd:annotation>
<xsd:documentation>This element identifies when a definition was submitted to the OVAL Community. A definition can only be submitted once. As children, an unbounded number of optional contributor elements outline who is credited with the submission. The required date attribute holds that actual date of the submission. It is of type date and should be of the form yyyy-mm-dd.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>date</attributes>
<content>none</content>
<parent_elements>dates</parent_elements>
<child_elements>[contributor]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:contributor" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="date" type="xsd:date" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="modified">
<xsd:annotation>
<xsd:documentation>This element identifies when a definition was modified and provides details about what modification was made. A definition can be modified an unlimited number of times. The unbounded number of optional child contributor elements outline who is credited with the modification. The required date attribute identifies when the change was actually made. It is of type date and should be of the form yyyy-mm-dd.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-n</cardinality>
<attributes>date, comment</attributes>
<content>none</content>
<parent_elements>dates</parent_elements>
<child_elements>[contributor]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:contributor" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="date" type="xsd:date" use="required"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="status_change">
<xsd:annotation>
<xsd:documentation>This element identifies when an OVAL Definition changed status. This represents the movement of a definition through the review process. This is an automatic change and not associated with an individual. The required date attribute identifies when the change was actually made. It is of type date and should be of the form yyyy-mm-dd.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-n</cardinality>
<attributes>date</attributes>
<content>string</content>
<parent_elements>dates</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="oval:status">
<xsd:attribute name="date" type="xsd:date" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="contributor">
<xsd:annotation>
<xsd:documentation>The contributor element identifies by name the member of the OVAL Community who is credited with a particular submission or modification. The optional organization attribute identifies the organization with which the contributor is affiliated.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>[organization]</attributes>
<content>none</content>
<parent_elements>modified, submitted</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="organization" type="xsd:string" use="optional"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="description" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The description element contains a textual description of the configuration state being addressed by the OVAL Definition. In the case of a definition from the vulnerability class, the reference is usually the Common Vulnerability and Exposures (CVE) Identifier, and this description field corresponds with the CVE description.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>definition</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="reference">
<xsd:annotation>
<xsd:documentation>This element links the OVAL Definition to a definitive external reference. For example, CVE Identifiers for vulnerabilities. The intended purpose for this reference is to link the definition to a variety of other sources that share this common name or identifier. Only one reference is allowed for each definition and the required source attribute serves as an indicator to the reference type.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-n</cardinality>
<attributes>source</attributes>
<content>string</content>
<parent_elements>definition</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:anyURI">
<xsd:attribute name="source" type="oval:reference_source" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="status" type="oval:status">
<xsd:annotation>
<xsd:documentation>This element contains the current status of the definition. Possible values are: ACCEPTED, DEPRECATED, DRAFT, INCOMPLETE, INITIAL SUBMISSION, and INTERIM. Status changes are managed by MITRE. Please visit the OVAL website at http://oval.mitre.org for more information about the each status.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>definition</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="version" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>This element holds the current version of the definition. Versions are integers, starting at 0 and incrementing every time a definition reaches ACCEPTED status. For example, an ACCEPTED definition with a version of 1 that is modified will return to INTERIM status for some period of time while the modifications are reviewed. During this period the definition will maintain a version of 1. When the changes have been approved, the definition status will become ACCEPTED again, but the will now have a version of 2.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>integer</content>
<parent_elements>definition</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="notes">
<xsd:annotation>
<xsd:documentation>This element is a container for one or more note child elements.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>definition, test</parent_elements>
<child_elements>note</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:note" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="note" type="xsd:string">
<xsd:annotation>
<xsd:documentation>A note contains some descriptive text about the containing definition or individual test element. It may record an unresolved question about the definition or test, document an unknown_test, or present the reasoning as to why a particular approach was taken.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>notes</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="criteria">
<xsd:annotation>
<xsd:documentation>Each definition is described by a number of tests, referenced by the individual criterion elements. The criteria element is the high level container for all the tests and represents the meat of the definition. These tests are broken up into two different categories, software and configuration. This categorization allows users to differentiate between the 'software on disk' portion of a definition and the 'how is the machine configured' portion of the definition.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>definition</parent_elements>
<child_elements>[software], [configuration]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:software" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval:configuration" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="software">
<xsd:annotation>
<xsd:documentation>Software tests describe specific conditions that exist with software on disk. For example, an OVAL definition might address a vulnerability that exists in a Microsoft Windows .dll file. The conditions about whether this .dll file actually exists on a machine are outlined in the software section. The optional operation attribute determines how to handle multiple criterion elements. Possible values are: AND, OR, XOR. A value of AND means that each criterion must be true for the software section to return true. A value of OR means that only one criterion must be true for the software section to return turn. XOR is defined to be true if an odd number of criterion are true, and false otherwise.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>[operation]</attributes>
<content>none</content>
<parent_elements>criteria</parent_elements>
<child_elements>criterion</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:criterion" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="operation" type="oval:operations" use="optional" default="AND"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="configuration">
<xsd:annotation>
<xsd:documentation>Tests under the configuration section describe conditions that violate a secure baseline or recommendation. For example, if a vulnerable Microsoft Windows .dll file is part of a specific service, then a machine might only be exploitable if that service is actually running. Even though the vulnerable file exists on the disk, the vulnerability can be mitigated by disabling the service. The test determining if the service is running would be under the configuration section. The optional operation attribute determines how to handle multiple criterion elements. Possible values are: AND, OR, XOR. A value of AND means that each criterion must be true for the configuration section to return true. A value of OR means that only one criterion must be true for the configuration section to return turn. XOR is defined to be true if an odd number of criterion are true, and false otherwise.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>[operation]</attributes>
<content>none</content>
<parent_elements>criteria</parent_elements>
<child_elements>criterion</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:criterion" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="operation" type="oval:operations" use="optional" default="AND"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="criterion">
<xsd:annotation>
<xsd:documentation>The criterion element identifies a specific test to be included in either the software or configuration section of a definition's criteria. The required test_ref attribute is the actual id of the test being referenced. The optional negate attribute signifies that the result of an individual test should be negated during analysis. For example, consider a test that returns TRUE if a specific patch is installed. By negating this test, it now analyzes to TRUE if the patch is NOT installed. The required comment attribute provides a short description of the specified test and should mirror the comment attribute of the actual test.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>test_ref, [negate], comment</attributes>
<content>none</content>
<parent_elements>software, configuration</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="test_ref" type="oval:testid" use="required"/>
<xsd:attribute name="negate" type="xsd:boolean" use="optional" default="false"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- =================================== TESTS =================================== -->
<!-- =============================================================================== -->
<xsd:element name="tests">
<xsd:annotation>
<xsd:documentation>This element is a container for one or more test child elements.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval</parent_elements>
<child_elements>test</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:test" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="test" type="oval:testType" abstract="true">
<xsd:annotation>
<xsd:documentation>This is an abstract element that is meant to be extended (via substitution groups) by the tests found in the family schemas. An actual test element is not valid. The use of this abstract class simplifies the OVAL schema and allows descriptive element names to be used in place of test. The abstract test element inherits the optional notes child element, and the id and comment attributes from the base testType. A description of the notes element can be found under the definitions section. Please refer to the "Complex Types" section of this document for a description of the testType.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, comment</attributes>
<content>none</content>
<parent_elements>tests</parent_elements>
<child_elements>[notes], (specified through extension)</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="testType">
<xsd:annotation>
<xsd:documentation>The base type of every test includes an optional notes element and two attributes. The required id attribute uniquely identifies each test, and is of the form 'xxx-#'. There is a three letter character code to help distinguish the type of test, followed by an unspecified number of digits (e.g. 'wrt-123'). The required comment attribute provides a short description of the test.</xsd:documentation>
<xsd:appinfo>
<attributes>id, comment</attributes>
<content>none</content>
<child_elements>[notes]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="oval:notes" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="id" type="oval:testid" use="required"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:complexType name="standardTestType">
<xsd:annotation>
<xsd:documentation>The standardTestType is an extension of the testType. The optional check attribute determines what group of objects to test. (For example: Should the test check that all files match a specified version or that at least one file matches the specified version?) The standardTestType is extended by individual tests in the different family schemas.</xsd:documentation>
<xsd:appinfo>
<extends>testType</extends>
<attributes>[check]</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="oval:testType">
<xsd:attribute name="check" type="oval:check" use="optional" default="all"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="objectType">
<xsd:annotation>
<xsd:documentation>The objectType is extended by the individual tests found in the different family schemas. The object section contains the child elements that describe which objects to gather data about and analyze.</xsd:documentation>
<xsd:appinfo>
<attributes>none</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="dataType">
<xsd:annotation>
<xsd:documentation>The dataType is extended by the individual tests found in the different family schemas. The data section contains the set of child elements whose values represent the testable parameters for the specified objects. The optional operation element defines the logical relation between multiple elements of the data section.</xsd:documentation>
<xsd:appinfo>
<attributes>[operation]</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:attribute name="operation" type="oval:operations" use="optional" default="AND"/>
</xsd:complexType>
<xsd:attributeGroup name="subtestAttributes">
<xsd:annotation>
<xsd:documentation>The following are the default attributes associated with every test element's children. The optional datatype determines the type of data expected. (the default datatype is 'string') The optional operator determines how the individual test cases (the child elements) should operate. (the default operator is 'equals') Both of these attributes are optional in order to keep the XML clean and readable. The default values are used most of the time and putting datatype="string" and operator="equals" for each element would muddy up the XML. The optional var_ref attribute refers the value of the child to a variable element. Some thought was given to removing the datatype attribute but it was decided that it is needed to determine how to programmatically perform the operation. For example the less than operator against '41' and '9' gives different results if doing a string compare or an integer compare. Use of the xsi:type attribute was considered, but it was decided that this would be too complex and put too much responsibility on the user to chose the correct type for a given subtest element.</xsd:documentation>
<xsd:appinfo>
<attributes>[datatype], [operator], [var_ref]</attributes>
</xsd:appinfo>
</xsd:annotation>
<xsd:attribute name="datatype" type="oval:datatypes" use="optional" default="string"/>
<xsd:attribute name="operator" type="oval:operators" use="optional" default="equals"/>
<xsd:attribute name="var_ref" type="oval:varid" use="optional"/>
</xsd:attributeGroup>
<xsd:complexType name="subtestBoolType">
<xsd:annotation>
<xsd:documentation>The subtestBoolType type is extended by the child elements of an individual test. This type provides uniformity to each child element by including the attributes found in the subtestAttributes group. This attribute is included by other subtest types and makes the same list of attributes available to all children of a test. This specific type describes simple boolean data.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes subtestAttributes)</attributes>
<content>boolean</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:boolean">
<xsd:attributeGroup ref="oval:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestIntType">
<xsd:annotation>
<xsd:documentation>The subtestIntType type is extended by the child elements of an individual test. This type provides uniformity to each child element by including the attributes found in the subtestAttributes group. This attribute is included by other subtest types and makes the same list of attributes available to all children of a test. This specific type describes simple integer data.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes subtestAttributes)</attributes>
<content>integer</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:integer">
<xsd:attributeGroup ref="oval:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestStringType">
<xsd:annotation>
<xsd:documentation>The subtestStringType type is extended by the child elements of an individual test. This type provides uniformity to each child element by including the attributes found in the subtestAttributes group. This attribute is included by other subtest types and makes the same list of attributes available to all children of a test. This specific type describes simple string data.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes subtestAttributes)</attributes>
<content>string</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attributeGroup ref="oval:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestBaseType">
<xsd:annotation>
<xsd:documentation>The subtestBaseType type is extended by the child elements of an individual test. This type provides uniformity to each child element by including the attributes found in the subtestAttributes group. This attribute is included by other subtest types and makes the same list of attributes available to all children of a test. This specific type describes complex data.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes subtestAttributes)</attributes>
<content>(anyType)</content>
<child_elements>(anyType)</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:restriction base="xsd:anyType">
<xsd:attributeGroup ref="oval:subtestAttributes"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="compound_test" substitutionGroup="oval:test">
<xsd:annotation>
<xsd:documentation>This test has been deprecated in version 4.1 of the oval-schema and will be removed completely in version 5. It is recommended that all future OVAL Content use the compound_test found in the independent schema.</xsd:documentation>
<xsd:documentation>A compound test allows multiple tests (including other compound tests) to be joined together by a logical operator. This provides flexibility in test creation and enables complex tests to be reused, serving as building blocks for future tests. The required operation attribute specifies how to logically combine the numerous subtests of a compound test. Possible values are: AND, OR, XOR. A value of AND means that each subtest must be true for the compound_test to return true. A value of OR means that only one subtest must be true for the compound_test to return true. A value of XOR means that one, and only one, subtest must be true for the compound_test to return true. A compound test extends the testType. Please refer to the "Complex Types" section of this document for a description of the testType.</xsd:documentation>
<xsd:appinfo>
<test_name>Compound Test</test_name>
<extends>testType</extends>
<valid_sections>[notes], subtest</valid_sections>
<example>
<compound_test id="cmp-0" operation="AND" comment="an example compound test">
<oval:notes>
<oval:note>This is an example test written under version 4 of the OVAL schema. It ANDs together the results of three separate tests, one of which is negated.</oval:note>
</oval:notes>
<subtest test_ref="wrt-0"/>
<subtest test_ref="wat-0" negate="true"/>
<subtest test_ref="cmp-1"/>
</compound_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval:testType">
<xsd:sequence>
<xsd:element name="subtest" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>The subtest element specifies a particular test to be referenced. The required test_ref attribute accomplishes this by linking to a valid test id. The optional 'negate' attribute signifies that the result of an individual test should be negated during analysis. For example, consider a test that returns TRUE if a specific patch is installed. By negating this test, it now analyzes to TRUE if the patch is NOT installed.</xsd:documentation>
<xsd:appinfo>
<parent_test>Compound Test</parent_test>
<cardinality>1-n</cardinality>
<content>none</content>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="test_ref" type="oval:testid" use="required"/>
<xsd:attribute name="negate" type="xsd:boolean" use="optional" default="false"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="operation" type="oval:operations" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="unknown_test" substitutionGroup="oval:test">
<xsd:annotation>
<xsd:documentation>This test has been deprecated in version 4.1 of the oval-schema and will be removed completely in version 5. It is recommended that all future OVAL Content use the unknown_test found in the independent schema.</xsd:documentation>
<xsd:documentation>An unknown test acts as a placeholder for tests whose implementation is unknown. Any information that is known about the test should be held in the notes child element that is available through the extension of the abstract test element. An unknown test extends the testType. Please refer to the "Complex Types" section of this document for a description of the testType.</xsd:documentation>
<xsd:appinfo>
<test_name>Unknown Test</test_name>
<extends>TestType</extends>
<valid_sections>[notes]</valid_sections>
<example>
<unknown_test id="ukn-0" comment="an example unknown test">
<oval:notes>
<oval:note>This is an example test written under version 4 of the OVAL schema. A description about the desired test would go here including what is unknown about it.</oval:note>
</oval:notes>
</unknown_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval:testType" />
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="variable_test" substitutionGroup="oval:test">
<xsd:annotation>
<xsd:documentation>This test has been deprecated in version 4.1 of the oval-schema and will be removed completely in version 5. It is recommended that all future OVAL Content use the variable_test found in the independent schema.</xsd:documentation>
<xsd:documentation>A variable test allows the value of a variable to be compared to a defined value. An example use would be to validate that a variable being passed in from an external source falls within a specified range.</xsd:documentation>
<xsd:appinfo>
<test_name>Variable Test</test_name>
<extends>TestType</extends>
<valid_sections>[notes], item</valid_sections>
<example>
<variable_test id="vct-0" operation="AND" comment="an example variable test">
<item variable="var-3" datatype="int" operator="greater than">6</item>
<item variable="var-3" datatype="int" operator="less than" var_ref="var-6"/>
</variable_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval:testType">
<xsd:sequence>
<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>An 'item' element defines a specific comparison to perform on a variable. The required 'variable' attribute provides a link to a variable to use. The optional datatype determines the type of data expected as the value of the 'item' element. (the default datatype is 'string') The required 'operator' attribute defines the operator to use for the comparision. The optional var_ref attribute refers the value of the item to a variable element. Note that the comparision should read: '*variable* is *operator* the value of the item'. Also note that it is implied that the datatypes of the two value being compared are the same.</xsd:documentation>
<xsd:appinfo>
<parent_test>Variable Test</parent_test>
<cardinality>1</cardinality>
<content>none</content>
<valid_datatypes>binary, boolean, component, float, int, string, version</valid_datatypes>
<valid_operators>equals, not equal, greater than, less than, greater than or equal, less than or equal, bitwise and, bitwise or, pattern match</valid_operators>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="xsd:anyType">
<xsd:attribute name="variable" type="oval:varid" use="required"/>
<xsd:attribute name="datatype" type="oval:datatypes" use="optional" default="string"/>
<xsd:attribute name="operator" type="oval:operators" use="optional" default="equals"/>
<xsd:attribute name="var_ref" type="oval:varid" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="operation" type="oval:operations" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================= VARIABLES ================================= -->
<!-- =============================================================================== -->
<xsd:element name="variables">
<xsd:annotation>
<xsd:documentation>This element is a container for one or more variable child elements.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval</parent_elements>
<child_elements>variable</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:variable" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="variable">
<xsd:annotation>
<xsd:documentation>A variable element is a reference to some value that can be used by tests to compare against. One of the main benefits of variables is that they allow tests to be compared to user-defined policy. For example, an OVAL test might check to see if a password is at least a certain number of characters, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element. This variable element refers to an external value (linked by the id) that can be passed in by the user when the OVAL definition is evaluated. The required id attribute uniquely identifies each variable. It is of the form var-#. The three letter code 'var' is followed by an unspecified number of digits, for example 'var-123'. The required datatype attribute specifies the type of value to expect in the external source. The required source attribute determines where the value of the variable will be found, either from some external source or as a constant declaration. When the source of the value is external, the id is used to link the variable element to the external source of the value. The required comment attribute provides a short description of the variable.
</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, datatype, source, comment</attributes>
<content>none</content>
<parent_elements>variables</parent_elements>
<child_elements>[restricted], [value]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="1">
<xsd:element ref="oval:restricted"/>
<xsd:element ref="oval:value"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="id" type="oval:varid" use="required"/>
<xsd:attribute name="datatype" type="oval:datatypes" use="required"/>
<xsd:attribute name="source" type="oval:variable_source" use="required"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="restricted">
<xsd:annotation>
<xsd:documentation>This element is a container of 'possible' child elements that specify any restrictions on the values of a variable. This element should only be available when the source attribute of a variable is 'external', although this is not enforced by this schema.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>variable</parent_elements>
<child_elements>possible</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval:possible" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="possible">
<xsd:annotation>
<xsd:documentation>This element outlines a possible expected value of a variable. A value that is passed in from an external source must match one of the possible values if the variable is being restricted. The required hint attribute gives a short description of what the value means. The required operator attribute specifies how to compare the actual value of the variable with the possible value.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>hint, operator</attributes>
<content>** undefined **</content>
<parent_elements>restricted</parent_elements>
<child_elements>** undefined **</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="xsd:anyType">
<xsd:attribute name="hint" type="xsd:string" use="required"/>
<xsd:attribute name="operator" type="oval:operators" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="value">
<xsd:annotation>
<xsd:documentation>If the source of a variable is constant, then the 'value' child element holds the actual value of the variable. NOTE that this element should only be (and must be) present when the source of a variable is 'constant', even though there is no way to enforce this during validation. This value should be used by all tests that reference this variable. The value can not be over-ridden by an external source.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>** undefined **</content>
<parent_elements>variable</parent_elements>
<child_elements>** undefined **</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="xsd:anyType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================= OTHER TYPES =============================== -->
<!-- =============================================================================== -->
<xsd:simpleType name="check">
<xsd:annotation>
<xsd:documentation>The check type defines acceptable check values. A value of 'all' means that all matching objects must satisfy data requirements for a test to return true. 'at least one' means that at least one matching object must satisfies the data requirements. 'none exists' means that a test returns true if no matching object exist that satisfy the data requirements. 'only one' means that a test returns true if one, and only one, matching object satisfies the data requirements.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
<xsd:enumeration value="at least one"/>
<xsd:enumeration value="none exist"/>
<xsd:enumeration value="only one"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="datatypes">
<xsd:annotation>
<xsd:documentation>This simple type defines the legal datatypes that are used to describe the values of a test's child elements. A value should be interpreted according to the specified type. This is most important during comparisons. For example, "Is '21' less than '123'?" will evaluate to true if the datatypes are 'int, but will evaluate to 'false' if the datatypes are 'string'.</xsd:documentation>
<xsd:documentation>The 'binary' datatype is used to represent data that is in raw (non-printable) form. Values should be hex strings. The 'boolean' datatype describes true or false values. The strings 'true' and 'false' are acceptable values, as are the numbers 1 and 0. The 'float', 'int', and 'string' datatypes are used to describe data of these types.</xsd:documentation>
<xsd:documentation>The component datatype represents a string value that is built from one or more component strings. Each component string is concatenated together to form the final string used by the element. The individual components can be a literal string or can a value returned from some another source, for example a registry key. If the source does not exist, i.e. the registry can not be found, then an error should be reported.</xsd:documentation>
<xsd:documentation>The rpmversion datatype represents the version of a redhat rpm. It is a string with the form epoch:version-release. If epoch is null then the string NULL is used. For example, NULL:0.9.13-1.90.1</xsd:documentation>
<xsd:documentation>The version datatype represents a value that is a hierarchical list of versions. For example '#.#.#' or '#-#-#-#' where the numbers to the left are more significant than the numbers to the right. When performing an 'equals' operation on a version datatype, you should first check the left most number for equality. If that fails, then the values are not equal. If it succeeds, then check the second left most number for equality. Continue checking the numbers from left to right until the last number has been checked. If, after testing all the previous numbers, the last number is equal then the two versions are equal. When performing other operations, such as 'less than', 'less than or equal', 'greater than, or 'greater than or equal', similar logic as above is used. Start with the left most number and move from left to right. For each number, check if it is less than the number you are testing against. If it is, then the version in question is less than the version you are testing against. If the number is equal, then move to check the next number to the right. For example, to test if 5.7.23 is less than or equal to 5.8.0 you first compare 5 to 5. They are equal so you move on to compare 7 to 8. 7 is less than 8 so the entire test succeeds and 5.7.23 is 'less than or equal' to 5.8.0. The difference between the 'less than' and 'less than or equal' operations is how the last number is handled. If the last number is reached, the check should use the given operation (either 'less than' and 'less than or equal') to test the number. For example, to test if 4.23.6 is greater than 4.23.6 you first compare 4 to 4. They are equal so you move on to compare 23 to 23. They are equal so you move on to compare 6 to 6. This is the last number in the version and since 6 is not greater than 6, the entire test fails and 4.23.6 is not greater than 4.23.6.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="binary"/>
<xsd:enumeration value="boolean"/>
<xsd:enumeration value="component"/>
<xsd:enumeration value="float"/>
<xsd:enumeration value="int"/>
<xsd:enumeration value="rpmversion"/>
<xsd:enumeration value="string"/>
<xsd:enumeration value="version"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="definitionclass">
<xsd:annotation>
<xsd:documentation>The different classes of definitions. A compliance definition describes the state of a machine as it complies with a specific policy. A patch definition details the machine state of whether a patch should be installed. A vulnerability definition described the condition under which a machine is vulnerable. A deprecated definition is placeholder for an OVAL definition that was officially accepted but has since been removed.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="compliance"/>
<xsd:enumeration value="deprecated"/>
<xsd:enumeration value="patch"/>
<xsd:enumeration value="vulnerability"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="definitionid">
<xsd:annotation>
<xsd:documentation>Define acceptable OVAL names as the string 'OVAL', followed by some number of digits.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="(OVAL[0-9]+)|(oval:[A-Za-z\-\.]+:def:[1-9][0-9]*)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="families">
<xsd:annotation>
<xsd:documentation>The families simple type is a listing of families that OVAL supports at this time.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="aix"/>
<xsd:enumeration value="apache"/>
<xsd:enumeration value="debian"/>
<xsd:enumeration value="freebsd"/>
<xsd:enumeration value="hp-ux"/>
<xsd:enumeration value="ios"/>
<xsd:enumeration value="macos"/>
<xsd:enumeration value="openbsd"/>
<xsd:enumeration value="oracle"/>
<xsd:enumeration value="os400"/>
<xsd:enumeration value="pix"/>
<xsd:enumeration value="redhat"/>
<xsd:enumeration value="solaris"/>
<xsd:enumeration value="suse"/>
<xsd:enumeration value="windows"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="operations">
<xsd:annotation>
<xsd:documentation>Define acceptable operations. XOR is defined to be true if an odd number of its arguments are true, and false otherwise.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="AND"/>
<xsd:enumeration value="OR"/>
<xsd:enumeration value="XOR"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="operators">
<xsd:annotation>
<xsd:documentation>Define acceptable operators.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="equals"/>
<xsd:enumeration value="not equal"/>
<xsd:enumeration value="greater than"/>
<xsd:enumeration value="less than"/>
<xsd:enumeration value="greater than or equal"/>
<xsd:enumeration value="less than or equal"/>
<xsd:enumeration value="bitwise and"/>
<xsd:enumeration value="bitwise or"/>
<xsd:enumeration value="pattern match">
<xsd:annotation>
<xsd:documentation>The pattern match operator allows an item to be tested against a regular expression. Patterns must comply with POSIX std 1003.2-1992, Section 2.8 - 'Regular Expression Notation'. Patterns can use both Basic and Extended Regular Expression notation.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="reference_source">
<xsd:annotation>
<xsd:documentation>The different sources for a reference</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="CVE"/>
<xsd:enumeration value="MISC"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="status">
<xsd:annotation>
<xsd:documentation>The status of an OVAL definition.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ACCEPTED"/>
<xsd:enumeration value="DEPRECATED"/>
<xsd:enumeration value="DRAFT"/>
<xsd:enumeration value="INCOMPLETE"/>
<xsd:enumeration value="INITIAL SUBMISSION"/>
<xsd:enumeration value="INTERIM"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="testid">
<xsd:annotation>
<xsd:documentation>Define acceptable test ids as a three character string followed by a hyphen and some number of digits.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="([a-z]{3}-[0-9]+)|(oval:[A-Za-z\-\.]+:tst:[1-9][0-9]*)"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="timestamp">
<xsd:annotation>
<xsd:documentation>Define acceptable timestamps as a string with the form yyyymmddhhmmss.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{14}"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="variable_source">
<xsd:annotation>
<xsd:documentation>The different sources for a variable value. An external source means the value is retrieved from somewhere outside of OVAL, say a variable file or directly from the analysis code. Think of this as when a value is passed into OVAL. A constant source means the value is declared inside of OVAL and can not be modified.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="constant"/>
<xsd:enumeration value="external"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="varid">
<xsd:annotation>
<xsd:documentation>Define acceptable variable ids as the string 'var-' followed by some number of digits.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="(var-[0-9]+)|(oval:[A-Za-z\-\.]+:var:[1-9][0-9]*)"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
|
XSD Schema Code: