/
common-core-3.xsd
executable file
·18907 lines (18145 loc) · 861 KB
/
common-core-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-2017 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: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:jaxb="http://java.sun.com/xml/ns/jaxb"
elementFormDefault="qualified"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="2.0">
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/annotation-3"/>
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/types-3"/>
<xsd:import namespace="http://prism.evolveum.com/xml/ns/public/query-3"/>
<xsd:import namespace="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"/>
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-model-context-3" />
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-certification-3" />
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-notifications-3" />
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-workflows-3" />
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-policy-3" />
<xsd:include schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-case-management-3" />
<!-- ################################## -->
<!-- ## 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="false">
<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>
All objects are identified by OID. The OID is an immutable identifier
(usually UUID). Except the OID all the objects have human-readable name.
The name is usually unique for each object type, but this is not a
strict requirement.
</p>
<p>
Note: object type is fixed, it cannot be changed. The object retains its
type from the time it was created to the end of its life.
</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).
It is usually unique in the respective context of
interpretation. E.g. the name of the UserType subtype
is usually unique in the whole system.
The name of the ShadowType subtype is usually unique in the
scope of resource (target system) that it belongs to.
</p>
<p>
The name 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 mutable. It 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>
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>ObjectType.name</a:displayName>
<a:displayOrder>0</a:displayOrder>
<a:emphasized>true</a:emphasized>
</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. This is meant to
be displayed in the user interface.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>ObjectType.description</a:displayName>
<a:displayOrder>10</a:displayOrder>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="subType" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<p>
Type of the object. It is used to distinguish what a specific object
represents. Whether it is a different kind of organizational unit, project,
team, or different kind of user, etc.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>ObjectType.subType</a:displayName>
<a:displayOrder>15</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>
Extension container that provides generic extensibility mechanism.
Almost any extension property can be placed in this container.
This mechanism is used to extend objects with new properties.
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>ObjectType.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>
<a:displayName>OrgType.parentOrganization</a:displayName>
<a:displayOrder>240</a:displayOrder>
<a:operational/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="trigger" type="tns:TriggerType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<p>
Triggers for this object. They drive invocations of corresponding trigger handlers
at specified time.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:operational>true</a:operational>
</xsd:appinfo>
</xsd:annotation>
</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>
<a:displayName>OrgType.tenant</a:displayName>
<a:displayOrder>250</a:displayOrder>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="lifecycleState" type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Lifecycle state of the object. This property defines whether the
object represents a draft, proposed definition, whether it is active,
deprecated, and so on.
</p>
<p>
There are few pre-defined lifecycle states. But custom lifecycle states
may also be defined. Pre-defined lifecycle states are:
</p>
<ul>
<li>draft: Definition of the new object in progress. The object is
NOT active. The definition may change at any moment. It is
not ready yet.</li>
<li>proposed: Definition of a new object is ready for use, but there
is still a review process to be applied (e.g. approval).
The object is NOT active. However the definition should
not change in this state.</li>
<li>active: Active and working definition. Ready to be used without
any unusual limitations.</li>
<li>deprecated: Active definition which is being phased out. The
definition is still fully operational. But it should not
be used for new assignments. E.g. it should not be requested,
it should not be approved, etc.</li>
<li>archived: Inactive historical definition. It is no longer used.
It is maintained only for historical, auditing and
sentimental reasons.</li>
<li>failed: Unexpected error has occurred during object lifecycle. Result
of that event is that the object is rendered inactive.
The situation cannot be automatically remedied. Manual action
is needed.</li>
</ul>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>ObjectType.lifecycleState</a:displayName>
<a:displayOrder>20</a:displayOrder>
<a:since>3.5</a:since>
<a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000230" type="tns:LookupTableType"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="operationExecution" type="tns:OperationExecutionType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<p>
Description of recent operations executed on this object (or related objects, e.g. shadows
in case of a focal object). The number of operations to be kept here is configurable.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:since>3.6</a:since>
<a:operational>true</a:operational>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="policySituation" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
The policy situation(s) of this object. The situations are result of
evaluation of the policy rules. This property is recorded for each object
and can be used for reporting, diagnostics, target selection in certification
campaigns, etc.
</xsd:documentation>
<xsd:appinfo>
<a:since>3.5</a:since>
<a:operational>true</a:operational>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="triggeredPolicyRule" type="tns:EvaluatedPolicyRuleType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Triggered policy rules for this assignment. (Not necessarily complete; subject to specified storage strategy.)
This is EXPERIMENTAL functionality. It is possibly to change in the near future.
</xsd:documentation>
<xsd:appinfo>
<a:since>3.7</a:since>
<a:operational>true</a:operational>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="policyException" type="tns:PolicyExceptionType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Recorded exception from a policy rule. The exceptions that are approved are
recoded here to avoid re-evaluating and re-approving them all the time.
This is EXPERIMENTAL functionality. It is likely to change in the near future.
</xsd:documentation>
<xsd:appinfo>
<a:since>3.5</a:since>
<a:experimental>true</a:experimental>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
<p>
System-wide immutable identifier for the object.
Will be probably quite long and not human-readable. It
should NOT be displayed to user.
</p>
<p>
This identifier must be unique in the entire system.
</p>
<p>
This attribute is immutable.
It cannot be changed. Any operation attempting
to change this identifier must fail.
However OID is not property and therefore cannot
be "addressed" in usual operations.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="version" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
<p>
Object version for the purposes of optimistic locking, cache
coherency, etc.
</p>
<p>
Contains the version in which this object was read from the
repository, fetched from the resource, etc.
</p>
<p>
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.
</p>
</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>
<p>
Reference to an object. It contains OID of the object that it
refers to.
</p>
</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>
<p>
Filter that can be used to dynamically lookup the reference OID e.g. during imports.
It must not be used for normal operations. The filter may be stored in the repository
to avoid data loss. But even if it is stored it will not be used beyond initial
import or unless explicitly requested (e.g. by setting resolutionTime).
</p>
<p>
Note: The filter will NOT be used if the OID in the reference is set. The OID always takes
precedence.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="resolutionTime" type="t:EvaluationTimeType" minOccurs="0" maxOccurs="1" default="import">
<xsd:annotation>
<xsd:documentation>
<p>
Definition of the "time" when the reference will be resolved. Resolving the reference means using
the filter to get object(s) or OID(s).
</p>
<p>
Import-time resolution means that the reference will be resolved once when the file is imported.
OID will be recorded in the reference and then only the OID will be used to follow the reference.
This is a very efficient method and it is the default.
</p>
<p>
Run-time resolution means that the reference will be resolved every time that the reference is
evaluated. This is less efficient but it provides great flexibility as the filter may contain
expressions and therefore the reference target may dynamically change.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="targetName" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Cached name of the target object.
This is a ephemeral value. It is not stored in the repository.
It may be computed at object retrieval time or it may not be present at all.
This is NOT an authoritative information. Setting it or changing it will
not influence the reference meaning. OID is the only authoritative linking
mechanism.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
<p>
Target of the reference.
</p>
<p>
Optional only during imports. The objects stored in the repository must have the OID
value filled in.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="type" type="xsd:QName" use="optional">
<xsd:annotation>
<xsd:documentation>
<p>
Type of the reference target object.
</p>
<p>
It has to be provided unless the schema explicitly defines
a non-polymorphic type for the reference target type.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="relation" type="xsd:QName" use="optional">
<xsd:annotation>
<xsd:documentation>
<p>
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,
are mebers of the org or managers of the org, etc.
</p>
</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>
<!-- We don't consider this type to be operational per se. We set operational flag
on some elements with this type. -->
<a:operational>false</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>
<!-- cannot be operational: it's a substantial piece of information, used to compare triggers -->
<!-- TODO think again about this (MID-3828) -->
<a:operational>false</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:element ref="tns:extension" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Extension container used to provide additional situation-specific information to the trigger.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:since>3.6</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:long"/>
</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>
Meta-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>
Meta-data only describe the last operation of its kind. E.g. there is a record of last
modification, last approval, etc. There is no history. The last operation overwrites data
about the previous operation.
</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/>
<a:displayName>Metadata</a:displayName>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="requestTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>
The timestamp of "create" operation request. It is set once and should never be changed.
</p>
<p>
In case of "background" processes to create object (e.g. create with approval)
this should be the timestamp when the process started. I.e. the timestamp when
the operation was requested.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.requestTimestamp</a:displayName>
<a:operational>true</a:operational>
<a:since>3.5</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="requestorRef" type="tns:ObjectReferenceType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Reference to the user that requested the "create" operation for this object or assignment.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.requestorRef</a:displayName>
<a:operational>true</a:operational>
<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="requestorComment" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Comment of the user that requested the "create" operation for this object or assignment.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.requestorComment</a:displayName>
<a:operational>true</a:operational>
<a:since>3.7</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="createTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>
The timestamp of data creation. It is set once and should never be changed.
</p>
<p>
In case of "background" processes to create object (e.g. create with approval)
this should be the timestamp when the process ended. I.e. the timestamp when
the operation was executed.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.createTimestamp</a:displayName>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
<a:since>3.5</a:since>
</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:displayName>MetadataType.creatorRef</a:displayName>
<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:displayName>MetadataType.createApproverRef</a:displayName>
<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="createApprovalComment" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Comments of the approvers during the creation of the data. Note that these comments are in no
particular order, so basically it is not known who entered which comment.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.createApprovalComment</a:displayName>
<a:operational>true</a:operational>
<a:since>3.7</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="createApprovalTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The timestamp of creation approval.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.createApprovalTimestamp</a:displayName>
<a:operational>true</a:operational>
<a:since>3.5</a:since>
</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:displayName>MetadataType.createChannel</a:displayName>
<a:operational>true</a:operational>
<a:indexed>true</a:indexed>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="createTaskRef" type="tns:ObjectReferenceType" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Reference to the task that created the object (if it was a persistent one).
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.createTaskRef</a:displayName>
<a:operational>true</a:operational>
<a:objectReferenceTargetType>tns:TaskType</a:objectReferenceTargetType>
<a:since>3.7</a:since>
</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
modify timestamp.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.modifyTimestamp</a:displayName>
<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:displayName>MetadataType.modifierRef</a:displayName>
<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>
<p>
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. However the order and
hierarchy of the approvers is lost.
</p>
<p>
Even though this is multi-value reference it will get overwritten after each approval.
The multiple values are used only if all the approvers are known at the same time,
e.g. if multi-level approval is evaluated at the same time. But generally this refers
only to the last approval event.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.modifyApproverRef</a:displayName>
<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="modifyApprovalComment" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<p>
Comments of the approvers during the last modification of the data. Note that these comments are in no
particular order, so basically it is not known who entered which comment.
</p>
<p>
Even though this is multi-value property it will get overwritten after each approval.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.modifyApprovalComment</a:displayName>
<a:operational>true</a:operational>
<a:since>3.7</a:since>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name="modifyApprovalTimestamp" type="xsd:dateTime" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
The timestamp of last modification approval.
</xsd:documentation>
<xsd:appinfo>
<a:displayName>MetadataType.modifyApprovalTimestamp</a:displayName>
<a:operational>true</a:operational>
<a:since>3.5</a:since>
</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>