<xsd:schema targetNamespace="http://oval.mitre.org/XMLSchema/oval_results" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:oval_results="http://oval.mitre.org/XMLSchema/oval_results" 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) Results. The Core Results 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 Results 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 Results</schema>
<version>4.2</version>
<date>2 December 2005</date>
</xsd:appinfo>
</xsd:annotation>
<!-- =============================================================================== -->
<!-- =============================================================================== -->
<!-- =============================================================================== -->
<xsd:element name="oval_results">
<xsd:annotation>
<xsd:documentation>The root element of an OVAL Results Document binding all of the results together along with the associated test elements. It must contain exactly one generators child element and exactly one system_info child element. The other child elements are optional.</xsd:documentation>
<xsd:documentation>The oval_results element is the root of an OVAL results document, and must occur exactly once. Its purpose is to bind together the five major sections of a results file - generators, system_info, definitions, tests, and variables - which are the children of the oval_results element. The generator section must be present and provides information about when the results file was compiled and under what version. The require system_info element is used to record information about the system being described.</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>generators, system_info, [definitions], [tests], [variables], [Signature]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:generators" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:system_info" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:definitions" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:tests" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:variables" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="ds:Signature" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:key name="definitionInstanceKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness in the combination of OVAL id and instance id in order to differentiate the individual definition elements.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval_results:definitions/oval_results:definition"/>
<xsd:field xpath="@id"/>
<xsd:field xpath="@instance"/>
</xsd:key>
<xsd:key name="testVersionKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness in the combination of the individual test ids and the version of the test.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval_results:tests/*"/>
<xsd:field xpath="@id"/>
<xsd:field xpath="@version"/>
</xsd:key>
<xsd:key name="variableVersionKey">
<xsd:annotation>
<xsd:documentation>Enforce uniqueness in the combination of the individual variable ids and the version of the variable.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval_results:variables/oval_results:variable"/>
<xsd:field xpath="@id"/>
<xsd:field xpath="@version"/>
</xsd:key>
<xsd:keyref name="testVersionKeyRef" refer="oval_results:testVersionKey">
<xsd:annotation>
<xsd:documentation>Require each test reference in a criterion element to refer to a valid test id, version combination.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval_results:definitions/oval_results:definition/oval_results:criteria/oval_results:*/oval_results:criterion"/>
<xsd:field xpath="@test_ref"/>
<xsd:field xpath="@version"/>
</xsd:keyref>
<xsd:keyref name="subtestVersionKeyRef" refer="oval_results:testVersionKey">
<xsd:annotation>
<xsd:documentation>Require each test reference in a subtest element to refer to a valid test id, version combination.</xsd:documentation>
</xsd:annotation>
<xsd:selector xpath="oval_results:tests/oval_results:compound_test/oval_results:subtest"/>
<xsd:field xpath="@test_ref"/>
<xsd:field xpath="@version"/>
</xsd:keyref>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================ GENERATORS ================================= -->
<!-- =============================================================================== -->
<xsd:element name="generators">
<xsd:annotation>
<xsd:documentation>The generators element specifies information about who generated the set of OVAL definitions used in the analysis, what application collected the data used for the analysis, and what application preformed the analysis. Note that the system_characteristics generator information is optional to allow for other data sources.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval_results</parent_elements>
<child_elements>oval, system_characteristics, results</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:oval" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:system_characteristics" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:results" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="oval">
<xsd:annotation>
<xsd:documentation>Specifies the source of the OVAL Definitions.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>generators</parent_elements>
<child_elements>product_name, product_version, schema_version, timestamp</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:product_name" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:product_version" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:schema_version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:timestamp" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="system_characteristics">
<xsd:annotation>
<xsd:documentation>Specifies the application used for data collection.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>generators</parent_elements>
<child_elements>product_name, product_version, schema_version, timestamp</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:product_name" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:product_version" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:schema_version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:timestamp" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="results">
<xsd:annotation>
<xsd:documentation>Specifies the application used for analysis.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>generators</parent_elements>
<child_elements>product_name, product_version, schema_version, timestamp</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:product_name" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:product_version" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:schema_version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:timestamp" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="product_name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The name of the application used to generate this file of OVAL definitions.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>oval, system_characteristics, results</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="product_version" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The version of the product used to generate this file of OVAL definitions</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>oval, system_characteristics, results</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="schema_version" type="xsd:decimal">
<xsd:annotation>
<xsd:documentation>This 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>oval, system_characteristics, results</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="timestamp" type="oval_results:timeStamp">
<xsd:annotation>
<xsd:documentation>This element specifies the date/time at which the document was created. 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 of the form yyyymmddhhmmss.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>oval, system_characteristics, results</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================ SYSTEM INFO ================================ -->
<!-- =============================================================================== -->
<xsd:element name="system_info">
<xsd:annotation>
<xsd:documentation>The system_info element specifies general information about the system that was analyzed including information that can be used to identify the system.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_characteristics</parent_elements>
<child_elements>os_name, os_version, architecture, primary_host_name, interfaces</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:os_name" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:os_version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:architecture" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:primary_host_name" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:interfaces" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="os_name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The operating system of the machine that was analyzed.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_info</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="os_version" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The version of the operating system of the machine that was analyzed.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_info</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="architecture" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The architecture of the machine the that was analyzed.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_info</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="primary_host_name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The primary host name of the machine that was analyzed.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_info</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="interfaces">
<xsd:annotation>
<xsd:documentation>The interfaces element holds a collection of interface elements that describe each interface on the machine that was analyzed.</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>system_info</parent_elements>
<child_elements>interface</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:interface" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="interface">
<xsd:annotation>
<xsd:documentation>The interface element is used to describe an interface on a system.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>interfaces</parent_elements>
<child_elements>interface_name, ip_address, mac_address</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:interface_name" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:ip_address" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:mac_address" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="interface_name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The name of the interface</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>interface</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="ip_address" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The ip address of the interface</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>interface</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="mac_address" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The mac address of the interface</xsd:documentation>
<xsd:appinfo>
<cardinality>1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>interface</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 the results of the analysis on each OVAL definition specified.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval_results</parent_elements>
<child_elements>definition</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:definition" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="definition">
<xsd:annotation>
<xsd:documentation>The definition element describes meta-data for an the analysis results of an individual OVAL definition. It also contains a criteria element that references the individual tests that make up the definition.</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 optional instance identifier is a unique id that differentiates every unique instance of a definition in the oval results file. Languages that include OVAL might reference the same definition multiple times. Each time a different set of values is supplied for the variables, a new instance of the definition must be created. (definitions that do not use variables can only have one unique instance) The inclusion of a unique instance identifier will allow the OVAL results file to report the correct result of a definition for each combination of supplied values. The required class attribute indicates the specific class the definition belongs to. Possible classes are: compliance, deprecated, patch, vulnerability.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, [instance], class</attributes>
<content>none</content>
<parent_elements>definitions</parent_elements>
<child_elements>affected, description, reference, status, version, criteria</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:affected" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:description" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:reference" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="oval_results:status" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:version" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="oval_results:criteria" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="id" type="oval_results:definitionid" use="required"/>
<xsd:attribute name="instance" type="oval_results:instanceType" use="optional" default="1"/>
<xsd:attribute name="class" type="oval_results:definitionclass" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="affected">
<xsd:annotation>
<xsd:documentation>Each OVAL definition is written for a particular system and the target family, platform(s), and product(s) are described in the affected element. The affected element's main purpose is to provide hints for tools using OVAL definitions, e.g. so Windows definitions are not needlessly evaluated on a Red Hat machine. 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 preformed, the correct test must still be included in the definition’s criteria section.</xsd:documentation>
<xsd:documentation>The family attribute states which major category of operating system the definition is written for. Possible values are: debian, ios, redhat, solaris, or windows. More families will be added to OVAL as needed. Each family has a corresponding family-specific definition schema which extends this core OVAL 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_results:platformBase" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="oval_results:product" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="family" type="oval_results:families" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="platformBase" type="xsd:string" abstract="true">
<xsd:annotation>
<xsd:documentation>This element details a specific platform that the definition has been written for. 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 preformed, 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 a specific application, subsystem, library, etc. that the definition has been written for. 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 preformed, the correct test must still be included in the definition's criteria section.</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="description" type="xsd:string">
<xsd:annotation>
<xsd:documentation>This element contains a textual description of what the OVAL definition is testing for. In the case of a vulnerability class definition that references a CVE entry, it is recommended that the description is the same as 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-1</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_results:reference_source" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="status" type="oval_results:status">
<xsd:annotation>
<xsd:documentation>This element contains the current status of the definition. Possible values are: ACCEPTED, DEPRECATED, DRAFT, INCOMPLETE, INITIAL SUBMISSION, INTERIM. Please refer to the oval website for a description of each of these statuses. Status changes are managed by MITRE.</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 (ie, an ACCEPTED version 1 definition which requires modification will return to INTERIM status, remaining at version 1, and will move to version 2 when the changes have been approved and it has become ACCEPTED again).</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="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:documentation>The optional result attribute holds the result of the analysis as a whole: either true, false, or error. This result assumes that both the software and configuration section are used in the determination. If this is not the case, then this result should be left out. Some tools will only evaluate the software section, or only evaluate the configuration section, and would then rely solely on the result attribute associated with that section.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>result</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_results:software" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="oval_results:configuration" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="result" type="oval_results:resultType" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="software">
<xsd:annotation>
<xsd:documentation>Software tests describe specific conditions that exists with software on disk. For example, an OVAL definition might talk about a vulnerability that exists in a .dll file. The conditions about whether this .dll file actually exists on a machine are outlined in the software section.</xsd:documentation>
<xsd:documentation>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. A value of XOR means that one, and only one, criterion must be true for the software section to return true. The required result attribute holds the result of the analysis, either true, false, or error.</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_results:criterion" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="operation" type="oval_results:operations" use="optional" default="AND"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="configuration">
<xsd:annotation>
<xsd:documentation>Configuration tests describe conditions about whether something can actually be exploited due to how the machine is setup. For example, if a vulnerable .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 test determining if the service is running would be under the configuration section.</xsd:documentation>
<xsd:documentation>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. A value of XOR means that one, and only one, criterion must be true for the configuration section to return true. The required result attribute holds the result of the analysis, either true, false, or error.</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_results:criterion" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="operation" type="oval_results:operations" use="optional" default="AND"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="criterion">
<xsd:annotation>
<xsd:documentation>This element specifies a specific tests to be included in either the software or configuration section of a definition's criteria. The required 'test_ref' attribute is actual id of the test being linked to. The optional version attribute signifies which version of the test was used during analysis. Different versions of a test can be encounted if a test contains a variable reference and different values for the variable are used in different definition instances. The optional 'negate' attribute signifies that a failed result of the test should be looked for instead of a successful result. For example, the test might normally return true if the patch is installed. By setting negate equal to true, what we get is the test element will return 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. The required result attribute holds the result of the analysis, either true, false, or error.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>test_ref, [version], [negate], comment, result</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_results:testid" use="required"/>
<xsd:attribute name="version" type="oval_results:versionType" use="optional" default="1"/>
<xsd:attribute name="negate" type="xsd:boolean" use="optional" default="false"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- =================================== TESTS =================================== -->
<!-- =============================================================================== -->
<xsd:element name="tests">
<xsd:annotation>
<xsd:documentation>The tests element acts as a container for the detailed results of each test required by the specified OVAL definitions.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval_results</parent_elements>
<child_elements>test</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:test" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="test" type="oval_results:testType" abstract="true">
<xsd:annotation>
<xsd:documentation>This is an abstract element that is meant to be extended (via substitution groups) by the different 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 id and comment attribute from the its base testType.</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, comment, [version]</attributes>
<content>none</content>
<parent_elements>tests</parent_elements>
<child_elements>(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 a notes element and two attributes. The required id attribute uniquely identifies each test. It is of the form 'xxx-#'. The three letter character code helps distinguish the type of test. This is followed by an unspecified number of digits. For example 'wrt-123'. The optional version attribute differentiates between different version of a test. This can happen when a test includes a variable reference and different values for that variable are used by different definitions. The required comment attribute provides a short description of the test.</xsd:documentation>
<xsd:appinfo>
<attributes>id, comment, [version]</attributes>
<content>none</content>
<child_elements>[message]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="oval_results:message" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="oval_results:testid" use="required"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
<xsd:attribute name="version" type="oval_results:versionType" use="optional" default="1"/>
</xsd:complexType>
<xsd:element name="message" type="xsd:string">
<xsd:annotation>
<xsd:documentation>Holds a message from the analysis engine. For example, an error message.</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>string</content>
<parent_elements>test</parent_elements>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<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 result attribute holds the result of the analysis, either true, false, or error. The standardTestType is extended by individual tests in the different family schemas.</xsd:documentation>
<xsd:appinfo>
<extends>testType</extends>
<attributes>[check], result</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="oval_results:testType">
<xsd:attribute name="check" type="oval_results:check" use="optional" default="all"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="definitionObjectType">
<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 determine which objects to apply the test to.</xsd:documentation>
<xsd:appinfo>
<attributes>none</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="definitionDataType">
<xsd:annotation>
<xsd:documentation>This dataType is extended by the individual tests found in the different family schemas. The data section contains the child elements that define the desired traits to test each object in the object section against. The optional operation element defines the logical relation between the multiple elements of the data.</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_results:operations" use="optional" default="AND"/>
</xsd:complexType>
<xsd:complexType name="testedObjectType">
<xsd:annotation>
<xsd:documentation>This base type is extended by the individual tests found in the schemas of unique families. The tested_object section contains the subtests that show which objects were tested on a system. The result attribute specified the result of the OVAL analysis on the specified object. The object_id is present to allow for a reference to an external document containing the data about the object.</xsd:documentation>
<xsd:appinfo>
<attributes>result, [status], [object_id]</attributes>
<content>none</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
<xsd:attribute name="status" type="oval_results:statusType" use="optional" default="exists"/>
<xsd:attribute name="object_id" type="xsd:string" use="optional"/>
</xsd:complexType>
<xsd:attributeGroup name="subtestAttributes">
<xsd:annotation>
<xsd:documentation>The following are the default attributes associated with every element in the defintion_object or definition_data section of a test. 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. The optional version attribute signifies which version of the variable was used during analysis. Different versions of a variable can be encounted if different values for the variable are used in different definition instances.</xsd:documentation>
<xsd:appinfo>
<attributes>[datatype], [operator], [var_ref], [version]</attributes>
</xsd:appinfo>
</xsd:annotation>
<xsd:attribute name="datatype" type="oval_results:datatypes" use="optional" default="string"/>
<xsd:attribute name="operator" type="oval_results:operators" use="optional" default="equals"/>
<xsd:attribute name="var_ref" type="oval_results:varid" use="optional"/>
<xsd:attribute name="version" type="oval_results:versionType" use="optional" default="1"/>
</xsd:attributeGroup>
<xsd:complexType name="subtestBoolType">
<xsd:annotation>
<xsd:documentation>Describes simple boolean data along with the standard subtest attributes.</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_results:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestIntType">
<xsd:annotation>
<xsd:documentation>Describes simple integer data along with the standard subtest attributes.</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_results:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestStringType">
<xsd:annotation>
<xsd:documentation>Describes simple string data along with the standard subtest attributes.</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_results:subtestAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="subtestBaseType">
<xsd:annotation>
<xsd:documentation>Describes complex data data along with the standard subtest attributes.</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_results:subtestAttributes"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:attributeGroup name="testedAttributes">
<xsd:annotation>
<xsd:documentation>The following are the default attributes associated with every element in the tested_object section. The datatype attribute determines signifies whether the object was originally part of a pattern match or literal string. (the default datatype is 'string') The datatype attribute is optional in order to keep the XML clean and readable. The default value is used most of the time and putting datatype="literal" for each element would muddy up the XML.</xsd:documentation>
<xsd:appinfo>
<attributes>[datatype]</attributes>
</xsd:appinfo>
</xsd:annotation>
<xsd:attribute name="datatype" type="oval_results:objectDatatypes" use="optional" default="literal"/>
</xsd:attributeGroup>
<xsd:complexType name="testedBoolType">
<xsd:annotation>
<xsd:documentation>Describes simple boolean data along with the standard tested attributes.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes testedAttributes)</attributes>
<content>boolean</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:boolean">
<xsd:attributeGroup ref="oval_results:testedAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="testedIntType">
<xsd:annotation>
<xsd:documentation>Describes simple integer data along with the standard tested attributes.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes testedAttributes)</attributes>
<content>integer</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:integer">
<xsd:attributeGroup ref="oval_results:testedAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="testedStringType">
<xsd:annotation>
<xsd:documentation>Describes simple string data along with the standard tested attributes.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes testedAttributes)</attributes>
<content>string</content>
<child_elements>none</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attributeGroup ref="oval_results:testedAttributes"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="testedBaseType">
<xsd:annotation>
<xsd:documentation>Describes complex data data along with the standard tested attributes.</xsd:documentation>
<xsd:appinfo>
<attributes>(includes testedAttributes)</attributes>
<content>(anyType)</content>
<child_elements>(anyType)</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:restriction base="xsd:anyType">
<xsd:attributeGroup ref="oval_results:testedAttributes"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="compound_test" substitutionGroup="oval_results: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. The required result attribute specifies the result of the OVAL analysis on this group of subtests. A compound test extends the testType.</xsd:documentation>
<xsd:appinfo>
<test_name>Compound Test</test_name>
<extends>compoundTestType</extends>
<valid_sections>[message], subtest</valid_sections>
<example>
<compound_test id="cmp-0" operation="AND" comment="an example compound test" version="1" result="1">
<subtest test_ref="wrt-0" version="1" result="0"/>
<subtest test_ref="wat-0" version="1" negate="true" result="1"/>
<subtest test_ref="cmp-1" version="1" result="1"/>
</compound_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval_results: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. The required result attribute holds the result of the analysis, either true, false, or error.</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_results:testid" use="required"/>
<xsd:attribute name="version" type="oval_results:versionType" default="1"/>
<xsd:attribute name="negate" type="xsd:boolean" use="optional" default="false"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="operation" type="oval_results:operations" use="required"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="unknown_test" substitutionGroup="oval_results: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. The required result attribute holds the result of the analysis, either true, false, or error.</xsd:documentation>
<xsd:appinfo>
<test_name>Unknown Test</test_name>
<extends>TestType</extends>
<valid_sections>[message]</valid_sections>
<example>
<unknown_test id="ukn-0" comment="an example unknown test" version="1" result="0">
</unknown_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval_results:testType">
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="variable_test" substitutionGroup="oval_results: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>[message], item</valid_sections>
<example>
<variable_test id="vct-0" operation="AND" comment="an example variable test" version="1" result="1">
<item variable="var-3" version="1" datatype="int" operator="greater than" result="0">6</item>
<item variable="var-3" version="1" datatype="int" operator="less than" result="1">78</item>
</variable_test>
</example>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="oval_results: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_results:varid" use="required"/>
<xsd:attribute name="variable_version" type="oval_results:versionType" use="optional" default="1"/>
<xsd:attribute name="datatype" type="oval_results:datatypes" use="optional" default="string"/>
<xsd:attribute name="operator" type="oval_results:operators" use="optional" default="equals"/>
<xsd:attribute name="var_ref" type="oval_results:varid" use="optional"/>
<xsd:attribute name="version" type="oval_results:versionType" use="optional" default="1"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="operation" type="oval_results:operations" use="required"/>
<xsd:attribute name="result" type="oval_results:resultType" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- =============================================================================== -->
<!-- ================================= VARIABLES ================================= -->
<!-- =============================================================================== -->
<xsd:element name="variables">
<xsd:annotation>
<xsd:documentation>The variables element is a container for different values of the variables required by the specified OVAL definitions..</xsd:documentation>
<xsd:appinfo>
<cardinality>0-1</cardinality>
<attributes>none</attributes>
<content>none</content>
<parent_elements>oval_results</parent_elements>
<child_elements>variable</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results: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 was be found, either from some external source or as a constant declaration. The required comment attribute provides a short description of the variable.
</xsd:documentation>
<xsd:appinfo>
<cardinality>1-n</cardinality>
<attributes>id, [version], datatype, source, comment</attributes>
<content>none</content>
<parent_elements>variables</parent_elements>
<child_elements>[value]</child_elements>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="oval_results:value" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="id" type="oval_results:varid" use="required"/>
<xsd:attribute name="version" type="oval_results:versionType" use="optional" default="1"/>
<xsd:attribute name="datatype" type="oval_results:datatypes" use="required"/>
<xsd:attribute name="source" type="oval_results:variable_source" use="required"/>
<xsd:attribute name="comment" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="value">
<xsd:annotation>
<xsd:documentation>The 'value' element holds the actual value of the variable used during analysis.</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>Define acceptable check types. 'all' means to check that all matching object satisfy data requirements. 'at least one' means that at least one matching object satisfies the data requirements. 'none exists' means that no matching object exists that satisfy the data requirements. 'only one' means that 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 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="component"/>
<xsd:enumeration value="binary"/>
<xsd:enumeration value="boolean"/>
<xsd:enumeration value="float"/>
<xsd:enumeration value="int"/>
<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 platforms.</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="instanceType">
<xsd:annotation>
<xsd:documentation>Instance ids are simply positive integers.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="objectDatatypes">
<xsd:annotation>
<xsd:documentation>Define acceptable data types for an element in an tested_object section.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="literal"/>
<xsd:enumeration value="pattern match"/>
</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: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="resultType">
<xsd:annotation>
<xsd:documentation>Define acceptable result values.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:enumeration value="-1"/>
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
</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="statusType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="error"/>
<xsd:enumeration value="exists"/>
<xsd:enumeration value="does not exist"/>
</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="uknResultType">
<xsd:annotation>
<xsd:documentation>Define acceptable result value for an unknown_test.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:enumeration value="-1"/>
</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:simpleType name="versionType">
<xsd:annotation>
<xsd:documentation>Version numbers are simply inetegers greater than or equal to 0.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
|
XSD Schema Code: