-
Notifications
You must be signed in to change notification settings - Fork 188
/
common-3.xsd
9881 lines (9314 loc) · 466 KB
/
common-3.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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Copyright (c) 2010-2014 Evolveum
~
~ Licensed under the Apache License, Version 2.0 (the "License");
~ you may not use this file except in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
-->
<xsd:schema targetNamespace="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:tns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3"
xmlns:a="http://prism.evolveum.com/xml/ns/public/annotation-3"
xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
elementFormDefault="qualified"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="2.0">
<xsd:annotation>
<xsd:documentation>
<p>
This is a common schema for midPoint project. It contains all the
data types that the stock midPoint is using
This file contains more that a common schema in fact. It contains
all the objects, even parts of what is known as identity schema and
model schema in midPoint.
</p>
See
<a href="https://wiki.evolveum.com/display/midPoint/Data+Model">https://wiki.evolveum.com/display/midPoint/Data+Model</a>
for more details.
<p>Version: 3.1-SNAPSHOT</p>
<p>Recommended namespace prefix: (default), c</p>
</xsd:documentation>
<xsd:appinfo>
<jaxb:globalBindings>
<xjc:typeSubstitution type="complex"/>
<xjc:serializable uid="201105211233"/>
</jaxb:globalBindings>
</xsd:appinfo>
</xsd:annotation>
<xsd:import namespace="http://www.w3.org/2001/XMLSchema"
schemaLocation="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
Importing the schema of XSD schema definition explicitly. This causes that we can use "strict" matching
for the xsd:schema elements used in runtime.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation="http://www.w3.org/2001/04/xmlenc#">
<xsd:annotation>
<xsd:documentation>
The XML Encryption schema. Used for "protected" data types (property encryption).
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/annotation-3"
schemaLocation="http://prism.evolveum.com/xml/ns/public/annotation-3">
<xsd:annotation>
<xsd:documentation>
Common prism annotations used in various XSD schemas.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/types-3"
schemaLocation="http://prism.evolveum.com/xml/ns/public/types-3">
<xsd:annotation>
<xsd:documentation>
Prism data types.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!-- <xsd:import namespace="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3" -->
<!-- schemaLocation="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3"> -->
<!-- <xsd:annotation> -->
<!-- <xsd:documentation> -->
<!-- Capabilities -->
<!-- </xsd:documentation> -->
<!-- </xsd:annotation> -->
<!-- </xsd:import> -->
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/query-3"
schemaLocation="http://prism.evolveum.com/xml/ns/public/query-3">
<xsd:annotation>
<xsd:documentation>
Prism data types.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import namespace="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
schemaLocation="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3">
<xsd:annotation>
<xsd:documentation>
This is a hack. It should not be here. And it will be gone as soon as we remove a deprecated functionality
in ResourceObjectPatternType.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!-- ################################## -->
<!-- ## Common Schema Layer ## -->
<!-- ################################## -->
<!-- See https://wiki.evolveum.com/display/midPoint/Common+Schema -->
<xsd:element name="displayName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<p>
Human readable name. This name may be displayed in tools and GUIs
to provide more pleasant user experience, as the XML data type names
or object names may look quite frightening.</p>
<p>
The "displayName" should contain a value that is readable for almost any
user. It is never used in the "logic", it is used only for display purposes.
</p>
<p>
The use of national characters is in "displayName" is fully supported.
</p>
<p>
DisplayName is reused in several location, but the meaning is still the same.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<p>
Free-form textual description of the object. It is supposed to describe
the object or a construct that it is attached to.
</p>
<p>
Anything that the system administrator wants may be here. The system
will not interpret the information except for displaying it and allow
user to edit it.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="ignore" type="xsd:boolean" default="true">
<xsd:annotation>
<xsd:documentation>
<p>
Presence of this element signifies that the structure that contains it should
be ignored. If this element is present in the attribute definition, the attribute
should be ignored. If it appears in the object class definition, the entire object
class should be ignored. "Ignored" means that the system should pretend that the
structure does not exist at all.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Basic Object Types -->
<xsd:complexType name="ObjectType" abstract="true">
<xsd:annotation>
<xsd:documentation>
<p>
Common supertype for all identity objects. Defines basic properties
that each object must have to live in our system (identifier, name).
</p>
<p>
Objects consists of identifier and name (see definition below)
and a set of properties represented as XML elements in the
object's body. The properties are represented as first-level
XML elements (tags) of the object XML representation and may
be also contained in other tags (e.g. extension, attributes)
that are marked by a propertyContainer annotation. The QName
(namespace and local name) of the element holding the property
is considered to be a property name.
</p>
<p>
Single-value properties must appear as a none or one instance
of the XML element holding the value.
</p>
<p>
Multi-value properties must appear as none or more instances of
the same XML element. Multi-valued properties are regarded as
unordered sets. Duplicate values are allowed, but duplicates
should not be preserved by the implementations. The implementations
should reduce duplicate values to a single value if it is
possible and efficient.
</p>
<p>
If an element for a specific property does not appear in the
object it means that the property value is undefined (property
does not exists). This is a different state as compared to
passing an empty XML element. Empty XML element means that the
property exists, but has an empty (null) value. Implementations
must be able to handle undefined (non-existent) properties, but
may NOT be able to handle empty (null) values. The use of empty
(null) values is DISCOURADGED.
</p>
<p>
It is not mandated by this specification how to pass ordered
lists and multi-value properties with duplicates. However it is
recommended to use single value properties with appropriate complex
XML data structures to hold such data.
</p>
<p>
The following XML snippet is an example of the object (omitting
namespace definitions, but assuming default namespace to be the
target namespace of this schema definition):
</p>
<pre>
<![CDATA[
<user oid="d3adm3a4" version="42">
<name>foobar</name>
<extension>
<foo:geekName>F00 B4r</foo:geekName>
<org:guild>Societus Geekus Europeus</org:guild>
<org:guild>Basset User Group</org:guild>
<pet:pet><pet:species>dog</pet:species><pet:breed>basset</pet:breed><pet:name>Doggie</pet:name></pet:pet>
<pet:pet><pet:species>mouse</pet:species><pet:breed>logitech</pet:breed><pet:name>Mousee</pet:name></pet:pet>
<com:shoppingPreferences>
<com:tShirt><com:size>XXL</com:size><com:color>#000000</com:color></com:tShirt>
<com:tie><com:preference>no thanks</com:preference></com:tie>
</com:shoppingPreferences>
</extension>
<fullName>Foo Bar</fullName>
<givenName>Foo</givenName>
<familyName>Bar</familyName>
</user>
]]></pre>
<p>
The above example describes an object with identifier "d3adm3a4",
name "foobar" and type defined by its top-level element User that
corresponds to URI "http://midpoint.evolveum.com/xml/ns/identity/1#User".
The object has 7 properties. Three of them are standard
properties defined by this schema:
</p>
<p>
Standard properties "fullName", "givenName" and "familyName"
in default namespace. These are single-valued string properties.
</p>
<p>
All the other properties are non-standard "extended" properties,
but they are considered equal to the standard attributes. They are
quarantined in the <extension> tag only to avoid XSD unique
particle attribution (UPA) problems. In the above example the
non-standard properties are:
</p>
<p>
Property "geekName" in namespace defined by "foo" prefix. This is also
single-valued string property.
</p>
<p>
Multi-valued non-standard property "guild". It is a string property
with multiple values. Multiple values are represented by providing
multiple instances of XML elements in the document.
Such properties are typically used for roles, groups, etc.
</p>
<p>
Complex property "pet". This property is defined by
complex XML type, using XML sub-elements to
represent structured data. Note that the use of XML attributes
is discouraged in the properties, although it might be possible in
some cases. This is also multi-valued property.
</p>
<p>
Complex property "shoppingPreferences". This property is using
complex XML type to form a structure of XML elements to
represent data. This is a single-valued property.
Note that the sub-elements "tShirt" and "tie" are NOT considered
to be properties.
</p>
<p>
QName-URI mapping:
</p>
<p>
For the purpose of this schema and all components that are using it,
URIs and QNames are considered equivalent. This is required by WWW
architecture and also helps avoid some drawbacks and bugs in XML-related
implementations that usually do not deal QNames well.
</p>
<p>
The QNames are mapped to URIs by concatenating namespace URI and a local
name. If URI does not end with slash (/) or hash (#) character, slash is
concatenated to the URI before adding the local name. The URI-QName
mapping is the reverse process.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:container/>
<a:object/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="t:ObjectType">
<xsd:sequence>
<xsd:element name="name" type="t:PolyStringType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>
Human-readable, mutable name of the object. It
may also be an identifier (login name, group name).
Should be unique in the respective context of
interpretation. E.g. the name of the UserType subtype
should be unique in the whole system.
The name of the AccountType subtype should be unique in the
scope of resource (target system) that it belongs to.
</p>
<p>
This may not be human-readable in a sense to display
to a common end-user. It is intended to be displayed to
IDM system administrator. Therefore it may contain quite
a "ugly" structures such as LDAP DN or URL.
</p>
<p>
Name is considered to be ordinary property of the object.
Therefore it can be changed by invoking usual modifyObject
operations. However, change of the name may have side
effects (rename process).
</p>
<p>
Name is mutable. It can change any time. However, a special
handling may be needed in some cases (e.g. "rename" provisioning flow).
</p>
<p>
Although name is specified as optional by this schema, it
is in fact mandatory for most object types. The reason for
specifying the name as optional is that the name may be
generated by the system instead of supplied by the clients.
However, all objects stored in the repository must have a name.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>Name</a:displayName>
<a:displayOrder>0</a:displayOrder>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element ref="tns:description" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>
Free-form textual description of the object.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>Description</a:displayName>
<a:displayOrder>10</a:displayOrder>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="fetchResult" type="tns:OperationResultType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>
Result of the operation that fetched this instance of the object.
It is mostly used to indicate that the object is not complete or
there is some problem with the object. This is used instead of
exception if the object is part of larger structures (lists as in
list/search operations or composite objets). If not present then
the "SUCCESS" state is assumed.
</p>
<p>
This field is TRANSIENT. It must only be used in runtime. It should
never be stored in the repository.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:operational/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element ref="tns:extension" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Container that provides generic extensibility mechanism.
Almost any extension property can be placed in this container.
The extension is treated exactly the same as other object
properties by the code (storage, modifications, etc), except
that the system may not be able to understand their meaning.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>Extension</a:displayName>
<a:displayOrder>1000</a:displayOrder>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="parentOrg" type="tns:OrgType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:appinfo>
<a:objectReference>tns:parentOrgRef</a:objectReference>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="parentOrgRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<p>
Set of the orgs (organizational units, projects, teams) that the object relates to.
This usually means that the object belongs to them but it may have other meanings as well
(e.g. user manages an organizational unit).
</p>
</xsd:documentation>
<xsd:appinfo>
<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="trigger" type="tns:TriggerType" minOccurs="0" maxOccurs="unbounded">
</xsd:element>
<xsd:element name="metadata" type="tns:MetadataType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Meta-data about object creation, modification, etc.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:operational/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="tenantRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Reference to the tenant to which this object belongs. It is a computed value set automatically
by midPoint. It is determined from the organizational structure. Even though this value is
compted it is also stored in the repository due to performance reasons.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
System-wide immutable identifier for the object.
Will be probably quite long and not human-readable. It
should not be displayed to user. It has no meaning
outside of IDM system and should not be directly
passed to any third-party systems.
This identifier must be unique in the entire system.
This attribute is immutable.
It cannot be changed. Any operation attempting
to change this identifier must fail.
OID is not property and therefore cannot be "addressed"
in usual operations.
OID must be provided for all objects that are persistently
stored. There may be detached objects without OID.
Such objects have the same structure as normal objects,
they are just not stored in the repository. E.g.
object that are only stored on resource and are
not replicated in the repository. Such objects
do not have OID therefore their XML representation
cannot contain oid attribute.
The OID should be unique in both time and space. That
means that OIDs must be unique in the whole system
in any moment and should not be re-used. If an object is
deleted, the OID of that object should not be used by
a new object. The reason is to avoid problems with stale
links pointing to a wrong object and appearing valid.
However, this is not a strict requirement. Some marginal
probability of OID reuse is tolerated. The recommended
practice is to add some randomness to the process of
OID generation.
This attribute is NOT (necessarily) ASN.1 OID and should not
be confused with it.
The attribute is named "oid" meaning object identifier.
It is not named "id" to avoid confusion with xml:id
attribute as it is easy to confuse these two if
namespace prefix is omitted. The confusion with ASN.1
OID id not likely.
The oid is XML attribute of this object instead of
element because it has special purpose of identifying
the object. It is also immutable, therefore we do not
need to handle changes to it.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="version" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
Version for optimistic locking.
Contains the version in which this object was read from the
repository, fetched from the resource, etc.
Type of the version attribute is string, not integer to provide
flexibility for various versioning schemes in implementation
(e.g. ETags). The type really does not matter, the only
things that matters is if the version is the same or different.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="object" type="tns:ObjectType"/>
<xsd:complexType name="ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Reference to an object. It contains OID of the object that it
refers to.
</xsd:documentation>
<xsd:appinfo>
<a:objectReference/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
<xsd:element name="filter" type="q:SearchFilterType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Filter that can be used to dynamically lookup the reference OID e.g. during imports.
It must not be used for normal operations and references with the filter must not
be stored in the repository.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
Target of the reference.
Optional only during imports. The objects stored in the repository must have the OID
value filled in.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="type" type="xsd:QName" use="optional">
<xsd:annotation>
<xsd:documentation>
XSD type of the reference target object.
It should be provided if the type is known (e.g. when
reading object from the repository).
The primary reason for this is to have some kind of
type safety but especially to be able to use
this in the XPaths that specify what references to resolve.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="relation" type="xsd:QName" use="optional">
<xsd:annotation>
<xsd:documentation>
The relation or a "role" of this reference. It may further specify
the meaning of the reference. E.g. it may specify whether the objects
linked by the reference are analogous, form a composition, aggregation, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="objectRef" type="tns:ObjectReferenceType"/>
<xsd:complexType name="ExtensionType">
<xsd:annotation>
<xsd:documentation>
Place for non-standard object properties. The
elements placed here will be handled exactly
like the elements in the object body.
It must NOT contain standard elements.
</xsd:documentation>
<xsd:appinfo>
<a:container/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax">
</xsd:any>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:long" use="optional"/>
</xsd:complexType>
<xsd:element name="extension" type="tns:ExtensionType" />
<xsd:complexType name="GenericObjectType">
<xsd:annotation>
<xsd:documentation>
<p>
Generic object for storing unknown (unexpected) object types.
</p>
<p>
The generic object should be used if there is a need to
store a custom object (e.g KangarooType) at deployment-time.
The properties of such custom objects are to be placed in the
extension part of this object. The schema is not checked or
enforced for this type of objects if technically possible.
</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectType">
<xsd:sequence>
<xsd:element name="objectType" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
<p>
Type of the stored object.
This attribute contains URI defining the type (class) of
stored object. The URI that maps to a QName of an object
XML element should be used if possible (see QName
mapping above). However this is not mandatory and the
implementation must be able to work with any URI.
</p>
<p>
Object type may be changed, but the possible values may
be constrained by the implementation. E.g. the implementation
may allow to change the object type only to the subtype or
supertype, or it may fail if the attributes of the object
does not conform to the schema constraints defined for the
new type.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="genericObject" type="tns:GenericObjectType" substitutionGroup="tns:object"/>
<xsd:complexType name="TriggerType">
<xsd:annotation>
<xsd:documentation>
Defines triggers for an object. Trigger is an action that should take place
at specified time or under some other condition.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:container/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="timestamp" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
The time when a trigger needs to be activated.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="handlerUri" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Handler URI indirectly specifies which class is responsible to handle the task. The handler will
to be used to handle trigger activation.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:long" use="optional"/>
</xsd:complexType>
<xsd:complexType name="MetadataType">
<xsd:annotation>
<xsd:documentation>
<p>
Meta-data about data creation, modification, etc.
It may apply to objects but also parts of the object (e.g. assignments).
</p>
<p>
Mata-data only apply to successful operations. That is obvious for create, but it also applies
to modify. For obvious reasons there are no metadata about delete.
We keep no metadata about reading. That would be a huge performance hit.
</p>
<p>
These data are informational only. They should not be used for security purposes (use auditing
subsystem for that). But presence of metadata simplifies system administration and may provide
some basic information "at the glance" which may be later confirmed by the audit logs.
</p>
<p>
Meta-data are also supposed to be searchable. Therefore they may be used to quickly find
"candidate" objects for a closer examination.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:container/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="createTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The timestamp of data creation. It is set once and should never be changed.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="creatorRef" type="tns:ObjectReferenceType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Reference to the user that created the data.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="createApproverRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Reference to the user that approved the creation of the data (if there was such a user).
This is multi-value reference therefore multiple approvers may be recorded. However the order and
hierarchy of the approvers is lost.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="createChannel" type="xsd:anyURI" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Channel in which the object was created.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="modifyTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The timestamp of last data modification. It should be updated to a current time
when the object is modified.
The modifications that change only operational attributes may not update the
modifytimestamp.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="modifierRef" type="tns:ObjectReferenceType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Reference to the user that modified the data.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="modifyApproverRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Reference to the user that approved the last modification of the data (if there was such a user).
This is multi-value reference therefore multiple approvers may be recorded. Howerver the order and
hierarchy of the approvers is lost.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="modifyChannel" type="xsd:anyURI" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
Channel in which the object was last modified.
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!-- Property-related types -->
<xsd:complexType name="EmptyType">
<xsd:annotation>
<xsd:documentation>
Type that contains nothing.
Used in WSDL messages that do not return anything to silence the warnings.
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<xsd:simpleType name="BeforeAfterType">
<xsd:annotation>
<xsd:documentation>
An enumeration that defines when the activity will be excuted.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before">
<xsd:annotation>
<xsd:documentation>
The activity will be executed before the "main" operation.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="BEFORE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="after">
<xsd:annotation>
<xsd:documentation>
The activity will be executed after the "main" operation.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="AFTER"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="NodeType">
<xsd:annotation>
<xsd:documentation>
Node describes a single installation of midPoint. MidPoint installations can work in cluster.
The Node objects are the way how the nodes in cluster know about each other.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectType">
<xsd:sequence>
<xsd:element name="nodeIdentifier" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Short, cluster-wide identifier of the node. It may be a hostname or a short number node ID.
Very short string is advised as this identifier is used to generate other identifiers
(e.g. lightweight IDs), it is used in audit records, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="hostname" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Hostname of the node that can be used by other nodes to contact this node over the
network.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="jmxPort" type="xsd:int" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Port at which this node can be contacted via JMX.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="lastCheckInTime" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The time when this node last checked-in.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="running" type="xsd:boolean" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Whether this node is running, i.e. it can be queried via JMX.
(This does not necessarily mean that the scheduler thread and task threads are running!)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="clustered" type="xsd:boolean" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Whether this node is a part of a cluster. Used to detect misconfigurations.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="internalNodeIdentifier" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Internal (generated) node identifier, used primarily to detect whether
the node information was not overwritten by another node.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="executionStatus" type="tns:NodeExecutionStatusType">
<xsd:annotation>
<xsd:documentation>
Actual node status from the point of executing tasks.
This field is TRANSIENT. It must only be used in runtime. It should
never be stored in the repository.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="errorStatus" type="tns:NodeErrorStatusType">
<xsd:annotation>
<xsd:documentation>
More detailed characterization of the error state.
This field is TRANSIENT. It must only be used in runtime. It should
never be stored in the repository.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="connectionResult" type="tns:OperationResultType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Result of the operation that connected to this node.