<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" targetNamespace="http://oval.mitre.org/XMLSchema/oval-common-5" elementFormDefault="qualified" version="5.1">
	<xsd:annotation>
		<xsd:documentation>The following is a description of the common types that are shared across the different schemas within Open Vulnerability and Assessment Language (OVAL).  Each type is described in detail and should provide the information necessary to understand what each represents.  This document is intended for developers and assumes some familiarity with XML.  A high level description of the interaction between these type 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 Common</schema>
		    <version>5.2</version>
		    <date>31 January 2007</date>
		</xsd:appinfo>
	</xsd:annotation>    
	<!-- =============================================================================== -->
	<!-- =============================================================================== -->
	<!-- =============================================================================== -->
	<xsd:complexType name="GeneratorType">
		<xsd:annotation>
			<xsd:documentation>The GeneratorType complex type defines an element that is used to hold information about when a particular OVAL document was compiled, what version of the schema was used, waht tool compiled the document, and what version of that tools was used..  </xsd:documentation>
			<xsd:documentation>Additional generator information is also allowed although it is not part of the official OVAL Schema.  Individual organizations can place generator information that they feel are important and these will be skipped during the validation.  All OVAL really cares about is that the stated generator information is there.</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="product_name" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>The optional product_name specifies the name of the application used to generate the file.</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="product_version" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>The optional product_version specifies the version of the application used to generate the file.</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="schema_version" type="xsd:decimal" minOccurs="1" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>The required schema_version specifies the version of the OVAL Schema that the document has been written in and that should be used for validation.</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="timestamp" type="xsd:dateTime" minOccurs="1" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>The required timestamp specifies when the particular OVAL document was compiled. The format for the timestamp is yyyy-mm-ddThh:mm:ss. Note that the timestamp element does not specify when a definition (or set of definitions) was created or modified but rather when the actual XML document that contains the definition was created. For example, the document might have pulled a bunch of existing OVAL Definitions together, each of the definitions having been created at some point in the past. The timestamp in this case would be when the combined document was created.</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="MessageType">
		<xsd:annotation>
			<xsd:documentation>The MessageType complex type defines the structure for which messages are relayed from the data collection engine.  Each message is a text string that has an associated level attribute identifying the type of message being sent.  These messages could be error messages, warning messages, debug messages, etc.  How the messages are used by tools and whether or not they are displayed to the user is up to the specific implementation.  Please refer to the description of the MessageLevelEnumeration for more information about each type of message.</xsd:documentation>
		</xsd:annotation>
		<xsd:simpleContent>
			<xsd:extension base="xsd:string">
				<xsd:attribute name="level" type="oval:MessageLevelEnumeration" use="optional" default="info"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>
	<!-- =============================================================================== -->
	<!-- ===============================  ENUMERATIONS  ================================ -->
	<!-- =============================================================================== -->
	<xsd:simpleType name="CheckEnumeration">
		<xsd:annotation>
			<xsd:documentation>The CheckEnumeration simple type defines acceptable check values, which determine how to evaluate multiple individual cases.  When used to define the relationship between objects and states, each check value defines how many of the matching objects must satisfy the given state for the test to return true.  When used to define the relationship between multiple values of entities, each check value defines how many values must be true for the entity to return true.  When used to define the relationship between entities and multiple variable values, each check value defines how many variable values must be true for the entity to return true.</xsd:documentation>
			<xsd:appinfo>
				<evaluation_documentation>Below are some tables that outline how each check attribute effects evaluation.  The far left column identifies the check attribute in question.  The middle column specifies the different combinations of individual results that the check attribute may bind together.  (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable)  For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results.  Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as is.</evaluation_documentation>
				<evaluation_chart>
               ||  num of individual results  ||
 check attr is ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 1+ | 0  | 0  | 0  | 0  | 0+ ||  True
               || 0+ | 0+ | 0+ | 0+ | 0+ | 0+ ||  False
     ALL       || 0+ | 0  | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0+ | 0  | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0+ | 0  | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
				<evaluation_chart>
               ||  num of individual results  ||
 check attr is ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ ||  True
               || 0  | 0+ | 0  | 0  | 0  | 0+ ||  False
 AT LEAST ONE  || 0  | 0+ | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0  | 0+ | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0  | 0+ | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
				<evaluation_chart>
               ||  num of individual results  ||
 check attr is ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 1  | 0+ | 0  | 0  | 0  | 0+ ||  True
               || 2+ | 0+ | 0+ | 0+ | 0+ | 0+ ||  ** False **
  ONLY ONE     || 0  | 0+ | 0  | 0  | 0  | 0+ ||  ** False **
               || 1- | 0+ | 1+ | 0+ | 0+ | 0+ ||  Error
               || 1- | 0+ | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 1- | 0+ | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
				<evaluation_chart>
               ||  num of individual results  ||
 check attr is ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 0  | 0+ | 0  | 0  | 0  | 0+ ||  True
               || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ ||  False
     NONE      || 0  | 0+ | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0  | 0+ | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0  | 0+ | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="all">
				<xsd:annotation>
				    <xsd:documentation>A value of 'all' means that a test returns true if a matching object exists and that all matching objects satisfy the data requirements for a test to evaluate to true.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="at least one">
				<xsd:annotation>
				    <xsd:documentation>A value of 'at least one' means that a test returns true if a matching object exists and at least one matching object must satisfies the data requirements for a test to evaluate to true.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="none exist">
				<xsd:annotation>
					<xsd:documentation>A value of 'none exists' means that a test evaluates to true if no matching object exists that satisfy the data requirements.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="only one">
				<xsd:annotation>
				    <xsd:documentation>A value of 'only one' means that a test evaluates to true if a matching object exists and if one, and only one, matching object satisfies the data requirements.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="DatatypeEnumeration">
		<xsd:annotation>
		    <xsd:documentation>The DatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities.  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'.  Another example is applying the 'equal' operation to '1.0.0.0' and '1.0'.  With datatype 'string' they are not equal, with datatype 'version' they are.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="binary">
				<xsd:annotation>
					<xsd:documentation>The binary datatype is used to represent data that is in raw (non-printable) form.  Values should be hex strings.  Expected operations within OVAL for binary values are 'equals' and 'not equals'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="boolean">
				<xsd:annotation>
					<xsd:documentation>The boolean datatype represent standard boolean data, either true or false.  Expected operations within OVAL for boolean values are 'equals' and 'not equals'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="evr_string">
				<xsd:annotation>
					<xsd:documentation>The evr_string datatype represents the epoch, version, and release fields as a single version string.  It has the form "EPOCH:VERSION-RELEASE".  Comparisons involving this datatype should follow the algorithm of librpm's rpmvercmp() function.  Expected operations within OVAL for evr_string values are 'equals', 'not equals', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="float">
				<xsd:annotation>
					<xsd:documentation>The float datatype describes standard float data.  Expected operations within OVAL for float values are 'equals', 'not equals', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="ios_version">
				<xsd:annotation>
					<xsd:documentation>The ios_version datatype describes Cisco IOS Train strings.  These are in essence version strings for IOS.  Please refer to Cisco's IOS Reference Guide for information on how to compare different Trains as they follow a very specific pattern.  Expected operations within OVAL for ios_version values are 'equals', 'not equals', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="int">
				<xsd:annotation>
					<xsd:documentation>The int datatype describes standard integer data.  Expected operations within OVAL for int values are 'equals', 'not equals', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'bitwise and', and 'bitwise or'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="string">
				<xsd:annotation>
					<xsd:documentation>The string datatype describes standard string data.  Expected operations within OVAL for string values are 'equals', 'not equals', 'pattern match'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="version">
				<xsd:annotation>
					<xsd:documentation>The version datatype represents a value that is a hierarchical list of integers separated by a single character delimiter.  Expected operations within OVAL for version values are 'equals', 'not equals', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'.</xsd:documentation>
					<xsd:documentation>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:documentation>Version strings with a different number of components shall be padded with zeros to make them the same size.  For example, if the version strings '1.2.3' and '6.7.8.9' are being compared, then the short one should be padded to become '1.2.3.0'.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="FamilyEnumeration">
		<xsd:annotation>
			<xsd:documentation>The FamilyEnumeration 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="ios"/>
			<xsd:enumeration value="macos"/>
			<xsd:enumeration value="unix"/>
			<xsd:enumeration value="windows"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="MessageLevelEnumeration">
		<xsd:annotation>
			<xsd:documentation>The MessageLevelEnumeration simple type defines the different levels associated with a message.  There is no specific criteria about which messages get assigned which level.  This is completely arbitrary and up to the content producer to decide what is an error message and what is a debug message.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="debug">
				<xsd:annotation>
					<xsd:documentation>Debug messages should only be displayed by a tool when run in some sort of verbose mode.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="error">
				<xsd:annotation>
					<xsd:documentation>Error messages should be recorded when there was an error that did not allow the collection of specific data.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="fatal">
				<xsd:annotation>
					<xsd:documentation>A fatal message should be recorded when an error causes the failure of more than just a single piece of data.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="info">
				<xsd:annotation>
					<xsd:documentation>Info messages are used to pass useful information about the data collection to a user.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="warning">
				<xsd:annotation>
					<xsd:documentation>A warning message reports something that might not correct but information was still collected.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="OperationEnumeration">
		<xsd:annotation>
			<xsd:documentation>The OperationEnumeration simple type defines acceptable operations.  Each operation defines how to compare entities against their actual values.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="equals">
				<xsd:annotation>
					<xsd:documentation>The 'equals' operation returns true if the actual value on the system is equal to the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="not equal">
				<xsd:annotation>
					<xsd:documentation>The 'not equal' operation returns true if the actual value on the system is not equal to the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="greater than">
				<xsd:annotation>
					<xsd:documentation>The 'greater than' operation returns true if the actual value on the system is greater than the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="less than">
				<xsd:annotation>
					<xsd:documentation>The 'less than' operation returns true if the actual value on the system is less than the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="greater than or equal">
				<xsd:annotation>
					<xsd:documentation>The 'greater than or equal' operation returns true if the actual value on the system is greater than or equal to the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="less than or equal">
				<xsd:annotation>
					<xsd:documentation>The 'less than or equal' operation returns true if the actual value on the system is less than or equal to the stated entity.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="bitwise and">
				<xsd:annotation>
					<xsd:documentation>The 'bitwise and' operation is used to determine if a specific bit is set.  It returns true if performing a BITWISE AND with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity.  For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise and' with the stated integer 4 (0100) returns 4 (0100).  Since the result is the same as the state mask, then the test returns true.  If the actual value on your machine is 1 (0001), then the 'bitwise and' with the stated integer 4 (0100) returns 0 (0000).  Since the result is not the same as the stated mask, then the test fails.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="bitwise or">
				<xsd:annotation>
					<xsd:documentation>The 'bitwise or' operation is used to determine if a specific bit is not set.  It returns true if performing a BITWISE OR with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity.  For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise or' with the stated integer 14 (1110) returns 14 (1110).  Since the result is the same as the state mask, then the test returns true.  If the actual value on your machine is 1 (0001), then the 'bitwise or' with the stated integer 14 (1110) returns 15 (1111).  Since the result is not the same as the stated mask, then the test fails.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="pattern match">
				<xsd:annotation>
					<xsd:documentation>The 'pattern match' operation 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="OperatorEnumeration">
		<xsd:annotation>
			<xsd:documentation>The OperatorEnumeration simple type defines acceptable operators.  Each operator defines how to evaluate multiple arguments.</xsd:documentation>
			<xsd:appinfo>
				<evaluation_documentation>Below are some tables that outline how each operator effects evaluation.  The far left column identifies the operator in question.  The middle column specifies the different combinations of individual results that the operator may bind together.  (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable)  For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results.  Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as is.</evaluation_documentation>
				<evaluation_chart>
               ||  num of individual results  ||
 operator is   ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 1+ | 0  | 0  | 0  | 0  | 0+ ||  True
               || 0+ | 1+ | 0+ | 0+ | 0+ | 0+ ||  False
     AND       || 0+ | 0  | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0+ | 0  | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0+ | 0  | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
				<evaluation_chart>
               ||  num of individual results  ||
 operator is   ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ ||  True
               || 0  | 1+ | 0  | 0  | 0  | 0+ ||  False
      OR       || 0  | 0+ | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0  | 0+ | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0  | 0+ | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
				<evaluation_chart>
               ||  num of individual results  ||
 operator is   ||                             ||  final result is
               || T  | F  | E  | U  | NE | NA ||
---------------||-----------------------------||------------------
               ||odd | 0+ | 0  | 0  | 0  | 0+ ||  True
               ||even| 0+ | 0  | 0  | 0  | 0+ ||  False
     XOR       || 0+ | 0+ | 1+ | 0+ | 0+ | 0+ ||  Error
               || 0+ | 0+ | 0  | 1+ | 0+ | 0+ ||  Unknown
               || 0+ | 0+ | 0  | 0  | 1+ | 0+ ||  Not Evaluated
               || 0  | 0  | 0  | 0  | 0  | 1+ ||  Not Applicable
---------------||-----------------------------||------------------</evaluation_chart>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="AND">
				<xsd:annotation>
					<xsd:documentation>The AND operator produces a true result if every argument is true.  If one or more arguments are false, the result of the AND is false.  If one or more of the arguments are unknown, and if none of the arguments are false, then the AND operator produces a result of unknown.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="OR">
				<xsd:annotation>
					<xsd:documentation>The OR operator produces a true result if one or more arguments is true.  If every argument is false, the result of the OR is false.  If one or more of the arguments are unknown, and if none of true arguments are true, then the OR operator produces a result of unknown.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="XOR">
				<xsd:annotation>
					<xsd:documentation>XOR is defined to be true if an odd number of its arguments are true, and false otherwise.  If any of the arguments are unknown, then the XOR operator produces a result of unknown.</xsd:documentation>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- =============================================================================== -->
	<!-- ================================  ID PATTERNS  ================================ -->
	<!-- =============================================================================== -->
	<xsd:simpleType name="DefinitionIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL Definition ids.  An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'def', and ending with an integer.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="oval:[A-Za-z0-9_\-\.]+:def:[1-9][0-9]*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ObjectIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL Object ids.  An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'obj', and ending with an integer.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="oval:[A-Za-z0-9_\-\.]+:obj:[1-9][0-9]*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="StateIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL State ids.  An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'ste', and ending with an integer.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="oval:[A-Za-z0-9_\-\.]+:ste:[1-9][0-9]*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="TestIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL Test ids.  An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'tst', and ending with an integer.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="oval:[A-Za-z0-9_\-\.]+:tst:[1-9][0-9]*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="VariableIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL Variable ids.  An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'var', and ending with an integer.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="oval:[A-Za-z0-9_\-\.]+:var:[1-9][0-9]*"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ItemIDPattern">
		<xsd:annotation>
			<xsd:documentation>Define the format for acceptable OVAL Item ids.  The format is an integer.  An item id is used to identify the different items found in an OVAL System Characteristics file.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:integer"/>
	</xsd:simpleType>
	<!-- =============================================================================== -->
	<!-- ================================  OTHER TYPES  ================================ -->
	<!-- =============================================================================== -->
	<xsd:simpleType name="EmptyStringType">
		<xsd:annotation>
			<xsd:documentation>The EmptyStringType simple type is a restriction of the built-in string simpleType.  The only allowed string is the empty string with a length of zero.  This type is used by certain elements to allow empty content when non-string data is accepted.  See the EntityIntType in the OVAL Definition Schema for an example of its use.</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:maxLength value="0"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- =============================================================================== -->
	<!-- =============================================================================== -->
	<!-- =============================================================================== -->
</xsd:schema>