forked from OVALProject/Sandbox
-
Notifications
You must be signed in to change notification settings - Fork 0
/
oval-common-schema.xsd
781 lines (781 loc) · 68 KB
/
oval-common-schema.xsd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="http://oval.mitre.org/XMLSchema/oval-common-5" elementFormDefault="qualified" version="5.10.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.10.1</version>
<date>1/27/2012 1:22:32 PM</date>
<terms_of_use>Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included.</terms_of_use>
<sch:ns prefix="oval" uri="http://oval.mitre.org/XMLSchema/oval-common-5"/>
<sch:ns prefix="oval-def" uri="http://oval.mitre.org/XMLSchema/oval-definitions-5"/>
</xsd:appinfo>
</xsd:annotation>
<!-- =============================================================================== -->
<!-- =============================== GLOBAL ELEMENTS ============================= -->
<!-- =============================================================================== -->
<xsd:element name="deprecated_info" type="oval:DeprecatedInfoType">
<xsd:annotation>
<xsd:documentation>The deprecated_info element is used in documenting deprecation information for items in the OVAL Language. It is declared globally as it can be found in any of the OVAL schemas and is used as part of the appinfo documentation and therefore it is not an element that can be declared locally and based off a global type..</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="element_mapping" type="oval:ElementMapType">
<xsd:annotation>
<xsd:documentation>The element_mapping element is used in documenting which tests, objects, states, and system characteristic items are associated with each other. It provides a way to explicitly and programatically associate the test, object, state, and item definitions.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- =============================================================================== -->
<!-- =============================== GLOBAL TYPES ================================ -->
<!-- =============================================================================== -->
<xsd:complexType name="ElementMapType">
<xsd:annotation>
<xsd:documentation>The ElementMapType is used to document the association between OVAL test, object, state, and item entities.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="test" type="oval:ElementMapItemType" minOccurs="1">
<xsd:annotation>
<xsd:documentation>The local name of an OVAL test.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="object" type="oval:ElementMapItemType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The local name of an OVAL object.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="state" type="oval:ElementMapItemType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The local name of an OVAL state.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="item" type="oval:ElementMapItemType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>The local name of an OVAL item.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ElementMapItemType">
<xsd:annotation>
<xsd:documentation>Defines a reference to an OVAL entity using the schema namespace and element name.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="xsd:NCName">
<xsd:attribute name="target_namespace" type="xsd:anyURI" use="optional" >
<xsd:annotation>
<xsd:documentation>The target_namespace attributes indicates what XML namespace the element belongs to. If not present, the namespace is that of the document in which the ElementMapItemType instance element appears.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="DeprecatedInfoType">
<xsd:annotation>
<xsd:documentation>The DeprecatedInfoType complex type defines a structure that will be used to flag schema-defined constructs as deprecated. It holds information related to the version of OVAL when the construct was deprecated along with a reason and comment.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="version">
<xsd:annotation>
<xsd:documentation>The required version child element details the version of OVAL in which the construct became deprecated.</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]+\.[0-9]+(\.[0-9]+)?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="reason" type="xsd:string">
<xsd:annotation>
<xsd:documentation>The required reason child element is used to provide an explanation as to why an item was deprecated and to direct a reader to possible alternative structures within OVAL.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="comment" type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>The optional comment child element is used to supply additional information regarding the element's deprecated status.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<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, what tool compiled the document, and what version of that tool 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. Product names SHOULD be expressed as CPE Names according to the Common Platform Enumeration: Name Matching Specification Version 2.3.</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">
<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:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[0-9]+\.[0-9]+(\.[0-9]+)?"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="timestamp" type="xsd:dateTime">
<xsd:annotation>
<!--- TODO - Add schematron to enforce yyyy-mm-ddThh:mm:ss format -->
<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="lax">
<xsd:annotation>
<xsd:documentation>The Asset Identification specification (http://scap.nist.gov/specifications/ai/) provides a standardized way of reporting asset information across different organizations.</xsd:documentation>
<xsd:documentation>Asset Identification elements can hold data useful for identifying what tool, what version of that tool was used, and identify other assets used to compile an OVAL document, such as persons or organizations.</xsd:documentation>
<xsd:documentation>To support greater interoperability, an ai:assets element describing assets used to produce an OVAL document may appear at this point in an OVAL document.</xsd:documentation>
</xsd:annotation>
</xsd:any>
</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 are used to determine the final result of something based on the results of individual components. When used to define the relationship between objects and states, each check value defines how many of the matching objects (items except those with a status of does not exist) must satisfy the given state for the test to return true. When used to define the relationship between instances of a given entity, the different check values defines how many instances 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 xml:space="preserve">
|| num of individual results ||
check attr is || || final result is
|| T | F | E | U | NE | NA ||
---------------||-----------------------------||------------------
|| 1+ | 0 | 0 | 0 | 0 | 0+ || True
|| 0+ | 1+ | 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 xml:space="preserve">
|| num of individual results ||
check attr is || || final result is
|| T | F | E | U | NE | NA ||
---------------||-----------------------------||------------------
|| 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || True
|| 0 | 1+ | 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 xml:space="preserve">
|| 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 **
|| 0 | 1+ | 0 | 0 | 0 | 0+ || ** False **
ONLY ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error
||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown
||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated
|| 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable
---------------||-----------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| num of individual results ||
check attr is || || final result is
|| T | F | E | U | NE | NA ||
---------------||-----------------------------||------------------
|| 0 | 1+ | 0 | 0 | 0 | 0+ || True
|| 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || False
NONE SATISFY || 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 final result of true is given if all the individual results under consideration are 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 final result of true is given if at least one of the individual results under consideration is 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:appinfo>
<oval:deprecated_info>
<oval:version>5.3</oval:version>
<oval:reason>Replaced by the 'none satisfy' value. In version 5.3 of the OVAL Language, the checking of existence and state were separated into two distinct checks CheckEnumeration (state) and ExistenceEnumeration (existence). Since CheckEnumeration is now used to specify how many objects should satisfy a given state for a test to return true, and no longer used for specifying how many objects must exist for a test to return true, a value of 'none exist' is no longer needed. See the 'none satisfy' value.</oval:reason>
<oval:comment>This value has been deprecated and will be removed in version 6.0 of the language.</oval:comment>
</oval:deprecated_info>
<sch:pattern id="oval_none_exist_value_dep">
<sch:rule context="oval-def:oval_definitions/oval-def:tests/child::*">
<sch:report test="@check='none exist'">
DEPRECATED ATTRIBUTE VALUE IN: <sch:value-of select="name()"/> ATTRIBUTE VALUE:
</sch:report>
</sch:rule>
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none satisfy">
<xsd:annotation>
<xsd:documentation>A value of 'none satisfy' means that a final result of true is given if none the individual results under consideration are true.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="only one">
<xsd:annotation>
<xsd:documentation>A value of 'only one' means that a final result of true is given if one and only one of the individual results under consideration are true.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ClassEnumeration">
<xsd:annotation>
<xsd:documentation>The ClassEnumeration simple type defines the different classes of definitions. Each class defines a certain intent regarding how an OVAL Definition is written and what that definition is describing. The specified class gives a hint about the definition so a user can know what the definition writer is trying to say. Note that the class does not make a statement about whether a true result is good or bad as this depends on the use of an OVAL Definition. These classes are also used to group definitions by the type of system state they are describing. For example, this allows users to find all the vulnerability (or patch, or inventory, etc) definitions.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="compliance">
<xsd:annotation>
<xsd:documentation>A compliance definition describes the state of a machine as it complies with a specific policy. A definition of this class will evaluate to true when the system is found to be compliant with the stated policy. Another way of thinking about this is that a compliance definition is stating "the system is compliant if ...".</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="inventory">
<xsd:annotation>
<xsd:documentation>An inventory definition describes whether a specific piece of software is installed on the system. A definition of this class will evaluate to true when the specified software is found on the system. Another way of thinking about this is that an inventory definition is stating "the software is installed if ...".</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="miscellaneous">
<xsd:annotation>
<xsd:documentation>The 'miscellaneous' class is used to identify definitions that do not fall into any of the other defined classes.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="patch">
<xsd:annotation>
<xsd:documentation>A patch definition details the machine state of whether a patch executable should be installed. A definition of this class will evaluate to true when the specified patch is missing from the system. Another way of thinking about this is that a patch definition is stating "the patch should be installed if ...". Note that word SHOULD is intended to mean more than just CAN the patch executable be installed. In other words, if a more recent patch is already installed then the specified patch might not need to be installed.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="vulnerability">
<xsd:annotation>
<xsd:documentation>A vulnerability definition describes the conditions under which a machine is vulnerable. A definition of this class will evaluate to true when the system is found to be vulnerable with the stated issue. Another way of thinking about this is that a vulnerability definition is stating "the system is vulnerable if ...".</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SimpleDatatypeEnumeration">
<xsd:annotation>
<xsd:documentation>The SimpleDatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities that can be represented in a XML string field. The value may have structure and a pattern, but it is represented as string content.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="binary">
<xsd:annotation>
<xsd:documentation>The binary datatype is used to represent hex-encoded data that is in raw (non-printable) form. This datatype conforms to the W3C Recommendation for binary data meaning that each binary octet is encoded as a character tuple, consisting of two hexadecimal digits {[0-9a-fA-F]} representing the octet code. Expected operations within OVAL for binary values are 'equals' and 'not equal'.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="boolean">
<xsd:annotation>
<xsd:documentation>The boolean datatype represents standard boolean data, either true or false. This datatype conforms to the W3C Recommendation for boolean data meaning that the following literals are legal values: {true, false, 1, 0}. Expected operations within OVAL for boolean values are 'equals' and 'not equal'.</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 equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="fileset_revision">
<xsd:annotation>
<xsd:documentation>The fileset_revision datatype represents the version string related to filesets in HP-UX. An example would be 'A.03.61.00'. For more information, see the HP-UX "Software Distributor Administration Guide" (http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01919399/c01919399.pdf). Expected operations within OVAL for fileset_version values are 'equals', 'not equal', '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. This datatype conforms to the W3C Recommendation for float data meaning it is patterned after the IEEE single-precision 32-bit floating point type. The format consists of a decimal followed, optionally, by the character 'E' or 'e', followed by an integer exponent. The special values positive and negative infinity and not-a-number have are represented by INF, -INF and NaN, respectively. Expected operations within OVAL for float values are 'equals', 'not equal', '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 equal', '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. This datatype conforms to the W3C Recommendation for integer data which follows the standard mathematical concept of the integer numbers. (no decimal point and infinite range) Expected operations within OVAL for int values are 'equals', 'not equal', '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="ipv4_address">
<xsd:annotation>
<xsd:documentation>The ipv4_address datatype represents IPv4 addresses and IPv4 address prefixes (using CIDR notation). Legal values are represented in dotted-quad notation ('a.b.c.d' where 'a', 'b', 'c', and 'd' are integers from 0-255), optionally followed by a slash ('/') and either a prefix-length (an integer from 0-32) or a netmask represented in dotted-quad notation ('a.b.c.d' where 'a', 'b', 'c', and 'd' are integers from 0-255). Examples of legal values are '192.0.2.0', '192.0.2.0/32', and '192.0.2.0/255.255.255.255'. Additionally, leading zeros are permitted such that '192.0.2.0' is equal to '192.000.002.000'. Expected operations within OVAL for ipv4_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'.</xsd:documentation>
<xsd:documentation>The 'subset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a subset of the set defined by the stated entity. This means that every IP address in the set of IP addresses on the system must be present in the set of IP addresses defined in the stated entity. Otherwise, the result will be 'false'.</xsd:documentation>
<xsd:documentation>The 'superset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a superset of the set defined by the stated entity. This means that every IP address in the set of IP addresses defined in the stated entity is present in the set of IP addresses on the system. Otherwise, the result will be 'false'.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="ipv6_address">
<xsd:annotation>
<xsd:documentation>The ipv6_address datatype represents IPv6 addresses and IPv6 address prefixes (using CIDR notation). This datatype conforms to the IETF specification RFC 4291 for textual representations of IPv6 addresses and IPv6 address prefixes (See Section 2.2 and 2.3). Expected operations within OVAL for ipv6_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'.</xsd:documentation>
<xsd:documentation>The 'subset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a subset of the set defined by the stated entity. This means that every IP address in the set of IP addresses on the system must be present in the set of IP addresses defined in the stated entity. Otherwise, the result will be 'false'.</xsd:documentation>
<xsd:documentation>The 'superset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a superset of the set defined by the stated entity. This means that every IP address in the set of IP addresses defined in the stated entity is present in the set of IP addresses on the system. Otherwise, the result will be 'false'.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="string">
<xsd:annotation>
<xsd:documentation>The string datatype describes standard string data. This datatype conforms to the W3C Recommendation for string data. Expected operations within OVAL for string values are 'equals', 'not equal', 'case insensitive equals', 'case insensitive not equal', '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 non-negative integers separated by a single character delimiter. Note that any non-number character can be used as a delimiter and that different characters can be used within the same version string. So '#.#-#' is the same as '#.#.#' or '#c#c#' where '#' is any non-negative integer. Expected operations within OVAL for version values are 'equals', 'not equal', '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="ComplexDatatypeEnumeration">
<xsd:annotation>
<xsd:documentation>The ComplexDatatypeEnumeration simple type defines the complex legal datatypes that are supported in OVAL. These datatype describe the values of individual entities where the entity has some complex structure beyond simple string like content.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="record">
<xsd:annotation>
<xsd:documentation>The record datatype describes an entity with structured set of named fields and values as its content. The only allowed operation within OVAL for record values is 'equals'. Note that the record datatype is not currently allowed when using variables.</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:union memberTypes="oval:SimpleDatatypeEnumeration oval:ComplexDatatypeEnumeration"/>
</xsd:simpleType>
<xsd:simpleType name="ExistenceEnumeration">
<xsd:annotation>
<xsd:documentation>The ExistenceEnumeration simple type defines acceptable existence values, which are used to determine a result based on the existence of individual components. The main use for this is for a test regarding the existence of objects on the system.</xsd:documentation>
<xsd:appinfo>
<evaluation_documentation>Below are some tables that outline how each ExistenceEnumeration value effects evaluation of a given test. Note that this is related to the existence of an object(s) and not the object(s) compliance with a state. The left column identifies the ExistenceEnumeration value in question. The middle column specifies the different combinations of individual item status values that have been found in the system characteristics file related to the given object. (EX=exists, DE=does not exist, ER=error, NC=not collected) For example, a 1+ under EX means that one or more individual item status attributes are set to exists, while a 0 under NC means that zero individual item status attributes are set to not collected. The last column specifies what the result of the existence piece would be according to each combination of individual item status values.</evaluation_documentation>
<evaluation_chart xml:space="preserve">
|| item status value count ||
attr value || || existence piece is
|| EX | DE | ER | NC ||
---------------||---------------------------||------------------
|| 1+ | 0 | 0 | 0 || True
|| 0 | 0 | 0 | 0 || False
|| 0+ | 1+ | 0+ | 0+ || False
all_exist || 0+ | 0 | 1+ | 0+ || Error
|| 0+ | 0 | 0 | 1+ || Unknown
|| -- | -- | -- | -- || Not Evaluated
|| -- | -- | -- | -- || Not Applicable
---------------||---------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| item status value count ||
attr value || || existence piece is
|| EX | DE | ER | NC ||
---------------||---------------------------||------------------
|| 0+ | 0+ | 0 | 0+ || True
|| 1+ | 0+ | 1+ | 0+ || True
|| -- | -- | -- | -- || False
any_exist || 0 | 0+ | 1+ | 0+ || Error
|| -- | -- | -- | -- || Unknown
|| -- | -- | -- | -- || Not Evaluated
|| -- | -- | -- | -- || Not Applicable
---------------||---------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| item status value count ||
attr value || || existence piece is
|| EX | DE | ER | NC ||
---------------||---------------------------||------------------
|| 1+ | 0+ | 0+ | 0+ || True
|| 0 | 1+ | 0 | 0 || False
at_least_one_exists || 0 | 0+ | 1+ | 0+ || Error
|| 0 | 0+ | 0 | 1+ || Unknown
|| -- | -- | -- | -- || Not Evaluated
|| -- | -- | -- | -- || Not Applicable
---------------||---------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| item status value count ||
attr value || || existence piece is
|| EX | DE | ER | NC ||
---------------||---------------------------||------------------
|| 0 | 0+ | 0 | 0 || True
|| 1+ | 0+ | 0+ | 0+ || False
none_exist || 0 | 0+ | 1+ | 0+ || Error
|| 0 | 0+ | 0 | 1+ || Unknown
|| -- | -- | -- | -- || Not Evaluated
|| -- | -- | -- | -- || Not Applicable
---------------||---------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| item status value count ||
attr value || || existence piece is
|| EX | DE | ER | NC ||
---------------||---------------------------||------------------
|| 1 | 0+ | 0 | 0 || True
|| 2+ | 0+ | 0+ | 0+ || False
|| 0 | 0+ | 0 | 0 || False
only_one_exists || 0,1 | 0+ | 1+ | 0+ || Error
|| 0,1 | 0+ | 0 | 1+ || Unknown
|| -- | -- | -- | -- || Not Evaluated
|| -- | -- | -- | -- || Not Applicable
---------------||---------------------------||------------------
</evaluation_chart>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all_exist">
<xsd:annotation>
<xsd:documentation>A value of 'all_exist' means that every object defined by the description exists on the system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="any_exist">
<xsd:annotation>
<xsd:documentation>A value of 'any_exist' means that zero or more objects defined by the description exist on the system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="at_least_one_exists">
<xsd:annotation>
<xsd:documentation>A value of 'at_least_one_exists' means that at least one object defined by the description exists on the system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none_exist">
<xsd:annotation>
<xsd:documentation>A value of 'none_exist' means that none of the objects defined by the description exist on the system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="only_one_exists">
<xsd:annotation>
<xsd:documentation>A value of 'only_one_exists' means that only one object defined by the description exists on the system.</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. Since new family values can only be added with new version of the schema, the value of 'undefined' is to be used when the desired family is not available. Note that use of the undefined family value does not target all families, rather it means that some family other than one of the defined values is targeted.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="catos">
<xsd:annotation>
<xsd:documentation>The catos value describes the Cisco CatOS operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="ios">
<xsd:annotation>
<xsd:documentation>The ios value describes the Cisco IOS operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="macos">
<xsd:annotation>
<xsd:documentation>The macos value describes the Mac operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="pixos">
<xsd:annotation>
<xsd:documentation>The pixos value describes the Cisco PIX operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="undefined">
<xsd:annotation>
<xsd:documentation>The undefined value is to be used when the desired family is not available.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="unix">
<xsd:annotation>
<xsd:documentation>The unix value describes the UNIX operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="vmware_infrastructure">
<xsd:annotation>
<xsd:documentation>The vmware_infrastructure value describes VMWare Infrastructure.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="windows">
<xsd:annotation>
<xsd:documentation>The windows value describes the Microsoft Windows operating system.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</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. When the specified datatype is a string, this results in a case-sensitive comparison.</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. When the specified datatype is a string, this results in a case-sensitive comparison.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="case insensitive equals">
<xsd:annotation>
<xsd:documentation>The 'case insensitive equals' operation is meant for string data and returns true if the actual value on the system is equal (using a case insensitive comparison) to the stated entity.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="case insensitive not equal">
<xsd:annotation>
<xsd:documentation>The 'case insensitive not equal' operation is meant for string data and returns true if the actual value on the system is not equal (using a case insensitive comparison) 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. When used by an entity in an OVAL Object, the regular expression represents the unique set of matching items on the system. OVAL supports a common subset of the regular expression character classes, operations, expressions and other lexical tokens defined within Perl 5's regular expression specification. For more information on the supported regular expression syntax in OVAL see: http://oval.mitre.org/language/about/re_support_5.6.html</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="subset of">
<xsd:annotation>
<xsd:documentation>The 'subset of' operation returns true if the actual set on the system is a subset of the set defined by the stated entity.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="superset of">
<xsd:annotation>
<xsd:documentation>The 'superset of' operation returns true if the actual set on the system is a superset of the set defined by the stated entity.</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 xml:space="preserve">
|| 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 xml:space="preserve">
|| num of individual results ||
operator is || || final result is
|| T | F | E | U | NE | NA ||
---------------||-----------------------------||------------------
|| 1 | 0+ | 0 | 0 | 0 | 0+ || True
|| 2+ | 0+ | 0+ | 0+ | 0+ | 0+ || ** False **
|| 0 | 1+ | 0 | 0 | 0 | 0+ || ** False **
ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error
||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown
||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated
|| 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable
---------------||-----------------------------||------------------
</evaluation_chart>
<evaluation_chart xml:space="preserve">
|| 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 xml:space="preserve">
|| 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="ONE">
<xsd:annotation>
<xsd:documentation>The ONE operator produces a true result if one and only one argument is true. If there are more than argument is true (or if there are no true arguments), the result of the ONE is false. If one or more of the arguments are unknown, then the ONE 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 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:simpleType name="NonEmptyStringType">
<xsd:annotation>
<xsd:documentation>The NonEmptyStringType simple type is a restriction of the built-in string simpleType. Empty strings are not allowed. This type is used by comment attributes where an empty value is not allowed.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:minLength value="1"/>
</xsd:restriction>
</xsd:simpleType>
<!-- =============================================================================== -->
<!-- =============================================================================== -->
<!-- =============================================================================== -->
</xsd:schema>