common-core-3.xsd

<?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="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>
    				<xsd:appinfo>
    					<a:displayName>MetadataType.modifyChannel</a:displayName>
    					<a:operational>true</a:operational>
    					<a:indexed>true</a:indexed>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
			<xsd:element name="modifyTaskRef" type="tns:ObjectReferenceType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Reference to the task that last modified the object (if it was a persistent one).
						If the last modification was carried out by synchronous task, this reference will be empty.
					</xsd:documentation>
					<xsd:appinfo>
						<a:displayName>MetadataType.modifyTaskRef</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="lastProvisioningTimestamp" type="xsd:dateTime" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						The timestamp last provisioning operation that was based on this object.
    						E.g. the timestamp of last modification of any account based on the
    						data from the user. This value is only updated if there was any
    						real change in the resource.
    					</p>
    					<p>
    						This meta-datum is used as an informational property that tells when
    						the data were last synchronized in outbound direction. But it has another
    						important role. It is used indirectly to trigger optimistic locking
    						conflicts that are used to detect a "clean" recompute (i.e. recompute
    						that is processing data without any outside interaction).
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:displayName>MetadataType.lastProvisioningTimestamp</a:displayName>
    					<a:operational>true</a:operational>
    					<a:since>3.6.1</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
            <!--<xsd:element name="certificationStartedTimestamp" type="xsd:dateTime" minOccurs="0">-->
                <!--<xsd:annotation>-->
                    <!--<xsd:documentation>-->
                        <!--When last certification related to this item was started.-->
                        <!--NOTE we assume only one certification type deals with any specific item (object or assignment).-->
                    <!--</xsd:documentation>-->
                    <!--<xsd:appinfo>-->
                        <!--<a:operational>true</a:operational>-->
                        <!--<a:indexed>true</a:indexed>-->
						<!--<a:since>3.7</a:since>-->
                    <!--</xsd:appinfo>-->
                <!--</xsd:annotation>-->
            <!--</xsd:element>-->
			<!--<xsd:element name="certificationCampaignRef" type="tns:ObjectReferenceType" minOccurs="0">-->
				<!--<xsd:annotation>-->
					<!--<xsd:documentation>-->
						<!--Certification campaign applied to this item.-->
						<!--(Should be set if and only if certificationStartedTimestamp is set.)-->
					<!--</xsd:documentation>-->
					<!--<xsd:appinfo>-->
						<!--<a:operational>true</a:operational>-->
						<!--<a:indexed>true</a:indexed>-->
						<!--<a:objectReferenceTargetType>tns:AccessCertificationCampaignType</a:objectReferenceTargetType>-->
						<!--<a:since>3.7</a:since>-->
					<!--</xsd:appinfo>-->
				<!--</xsd:annotation>-->
			<!--</xsd:element>-->
            <xsd:element name="certificationFinishedTimestamp" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        When last certification related to this item was finished.
						Only certifications that resulted in non-null outcome are taken into account.
                    </xsd:documentation>
                    <xsd:appinfo>
						<a:displayName>MetadataType.certificationFinishedTimestamp</a:displayName>
                        <a:operational>true</a:operational>
						<a:since>3.7</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="certificationOutcome" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Outcome (URI) of the last certification.
						Only certifications that resulted in non-null outcome are taken into account.
                    </xsd:documentation>
                    <xsd:appinfo>
						<a:displayName>MetadataType.certificationOutcome</a:displayName>
                        <a:operational>true</a:operational>
						<a:since>3.7</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="certifierRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the user that certified the data.
                        Contrary to approver/modifierRef, this field is filled-in also when certifier denies the item status.
						Only certifications that resulted in non-null outcome are taken into account.
					</xsd:documentation>
                    <xsd:appinfo>
						<a:displayName>MetadataType.certifierRef</a:displayName>
                        <a:operational>true</a:operational>
                        <a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
						<a:since>3.7</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="certifierComment" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
						<p>
							Comments of the certifiers during the last certification 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>
						<p>
							Only certifications that resulted in non-null outcome are taken into account.
						</p>
                    </xsd:documentation>
                    <xsd:appinfo>
						<a:displayName>MetadataType.certifierComment</a:displayName>
                        <a:operational>true</a:operational>
						<a:since>3.7</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="originMappingName" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
						<p>
							Identifies the mapping that caused the automated creation of this object or assignment.
						</p>
                    </xsd:documentation>
                    <xsd:appinfo>
						<a:displayName>MetadataType.originMappingName</a:displayName>
                        <a:operational>true</a:operational>
						<a:since>3.7</a:since>
                    </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 executed.
            </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:simpleType name="DeadlineRoundingType">
        <xsd:annotation>
            <xsd:documentation>
                Way of rounding deadline(s) e.g. for certification or approval stages.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        The deadline will not be rounded.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="hour">
                <xsd:annotation>
                    <xsd:documentation>
                        The deadline will be rounded to 59:59 of the computed hour.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HOUR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="day">
                <xsd:annotation>
                    <xsd:documentation>
                        The deadline will be rounded to 23:59:59 of the computed day.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DAY"/>
                    </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="ipAddress" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                IP addresses of the node (both IPv4 and IPv6 addresses in textual notation)
                            </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.
                                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="build" type="tns:BuildInformationType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Information about midPoint build running on this node.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="taskExecutionLimitations" type="tns:TaskExecutionLimitationsType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Limitations for execution of tasks on this node.
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.7</a:since>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="node" type="tns:NodeType" substitutionGroup="c:object"/>

	<xsd:complexType name="TaskExecutionLimitationsType">
		<xsd:annotation>
			<xsd:documentation>
				Limitations for execution of tasks on a given node.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="groupLimitation" type="tns:TaskGroupExecutionLimitationType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Limitations of execution for individual task groups.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="TaskGroupExecutionLimitationType">
		<xsd:annotation>
			<xsd:documentation>
				Limitations for execution of a task group on a given node.
				EXPERIMENTAL. Will probably change in the future, when task groups will be created as regular midPoint objects.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="groupName" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Name of the group to apply limitation to. Null or empty means "tasks with no specified group". Asterisk (*) means
						that the limit applies to each groups not listed here (individually).
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="limit" type="xsd:int" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						How many threads can be allocated to tasks within the given group. 0 means such tasks cannot be run
						on the current node. Null (i.e. no "limit" property) means this group can run on this node without
						explicit limitations; bound only by the total number of available threads.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

    <xsd:simpleType name="NodeExecutionStatusType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="running">
                <xsd:annotation>
                    <xsd:documentation>
                        Node is running, task scheduler is running.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RUNNING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="paused">
                <xsd:annotation>
                    <xsd:documentation>
                        Node is running, scheduler is paused.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PAUSED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="down">
                <xsd:annotation>
                    <xsd:documentation>
                        Node down (this status is available only for remote nodes, of course).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DOWN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="error">
                <xsd:annotation>
                    <xsd:documentation>
                        Node error (see NodeErrorStatus for more details).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="communicationError">
                <xsd:annotation>
                    <xsd:documentation>
                        Status unknown due to communication error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="COMMUNICATION_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="NodeErrorStatusType">
        <xsd:annotation>
            <xsd:documentation>
                Status of this node w.r.t. error conditions.
                Generally speaking, if NodeErrorStatus != OK, tasks cannot be scheduled on this node.
                This is a dynamic information, not stored in the repository.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ok">
                <xsd:annotation>
                    <xsd:documentation>
                        Everything is OK.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OK"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="duplicateNodeIdOrName">
                <xsd:annotation>
                    <xsd:documentation>
                        More nodes with the same ID or name (currently ID is the same as name, but in the future they might be different).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DUPLICATE_NODE_ID_OR_NAME"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="nonClusteredNodeWithOthers">
                <xsd:annotation>
                    <xsd:documentation>
                        A non-clustered node runs along other (clustered or non-clustered) nodes.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NON_CLUSTERED_NODE_WITH_OTHERS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="localConfigurationError">
                <xsd:annotation>
                    <xsd:documentation>
                        Local task manager is not configured properly, so it cannot even be started.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOCAL_CONFIGURATION_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="localInitializationError">
                <xsd:annotation>
                    <xsd:documentation>
                        Other kind of initialization error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOCAL_INITIALIZATION_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="nodeRegistrationFailed">
                <xsd:annotation>
                    <xsd:documentation>
                        It was not possible to register node in repository due to a permanent error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NODE_REGISTRATION_FAILED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="TaskType">
        <xsd:annotation>
            <xsd:documentation>
                TaskType contains information about a task (either transient or persistent).
                For background information and clarification of various terms used here, please see
                <a href="http://wiki.evolveum.com/display/midPoint/Task+Manager">wiki:Task Manager</a>
                and
                <a href="https://wiki.evolveum.com/display/midPoint/Task">wiki:Task</a>.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ObjectType">
                <xsd:sequence>
                    <xsd:element name="taskIdentifier" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Task (lightweight) identifier. This is an unique identification of any task,
                                regardless whether it is persistent or transient (cf. OID). Therefore this can be used
                                to identify all tasks, e.g. for the purposes of auditing and logging.
                                </p>

                                <p>
                                Task identifier is assigned automatically when the task is created. It is immutable.
                                It is formally set as optional, however it is mandatory for any task to work. Setting
                                it to optional allows creating a task without identifier and generating the identifier
                                during import. However any tasks that live inside midPoint (running or stored in repository)
                                must have valid task identifier.
                                </p>
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="ownerRef" type="tns:ObjectReferenceType">
                        <xsd:annotation>
                            <xsd:documentation>
                                The user that owns this task. It usually means the user that started the task
                                or a system user that is used to execute the task. The owner will be used to
                                determine access rights of the task, will be used for auditing, etc.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="channel" type="xsd:anyURI" minOccurs="0" maxOccurs="1"/>
                    <xsd:element name="parent" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Parent task, used to implement task hierarchies. A task can have a number of
                                children (subtasks) that carry out some of the work. For example, a parent task
                                can contain a complex model operation, and its subtasks contain individual
                                approvals and/or elementary model operations. If null, this task is a "root-level"
                                task that has no parent.
                                Task identifier (not OID) is used here.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="subtask" type="tns:TaskType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Set of task's subtasks.
                                TRANSIENT attribute. In the repository the parent-child relationship is stored using "parent" property.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReference>tns:subtaskRef</a:objectReference>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="subtaskRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Set of task's subtasks references.
                                TRANSIENT attribute. In the repository the parent-child relationship is stored using "parent" property.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReferenceTargetType>tns:TaskType</a:objectReferenceTargetType>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="dependent" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Dependent tasks, i.e. tasks that wait for the completion of this task.
                                Task identifiers (not OIDs) are used here.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="dependentTask" type="tns:TaskType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Dependent tasks, i.e. tasks that wait for the completion of this task.
                                TRANSIENT attribute. In the repository only the identifiers are stored (see "dependent" attribute).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReference>tns:dependentTaskRef</a:objectReference>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="dependentTaskRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Dependent tasks references, i.e. tasks that wait for the completion of this task.
                                TRANSIENT attribute. In the repository only the identifiers are stored (see "dependent" attribute).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReferenceTargetType>tns:TaskType</a:objectReferenceTargetType>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="executionStatus" type="tns:TaskExecutionStatusType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Execution status provides information about the task overall high-level execution state.
                                It tells whether the task is running/runnable, waits for something or is done.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="waitingReason" type="tns:TaskWaitingReasonType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                What is this task waiting for?
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="node" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Identifier of the node that currently executes this task.
                                (In case of node crash, the value here may be out-of-date.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="nodeAsObserved" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Identifier of the node that executes this task, as observed by querying cluster nodes
                                about tasks that are currently executing.
                                TRANSIENT. This value is not stored in the repository.
                                (It is currently not possible to use it for filtering or sorting.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="category" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Kind of the task, e.g. live sync, reconciliation, workflow, import from resource.
                                Used mainly for the GUI.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="handlerUri" type="xsd:anyURI" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Handler URI indirectly specifies which class is responsible to handle the task. The
                                handler will
                                execute reaction to a task lifecycle events such as executing the task, task heartbeat,
                                etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="otherHandlersUriStack" type="tns:UriStack" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                A stack of handlers that should be called after the primary one (handlerUri) finishes.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="result" type="tns:OperationResultType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                OperationResult that is used to compile task results (parent result).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="resultStatus" type="tns:OperationResultStatusType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Top-level state of the 'result' (OperationResultType).
                                It is put here for ease of use - mainly filtering, displaying, and so on.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="objectRef" type="tns:ObjectReferenceType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Object that the task is associated with. Tasks may be associated with a particular
                                objects. For
                                example a "import from resource" task is associated with the resource definition object
                                that it imports from. Similarly
                                for synchronization and reconciliation tasks (cycles).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="lastRunStartTimestamp" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The time when the task execution was last started.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="lastRunFinishTimestamp" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The time when the (last) task execution was finished, successfully or unsuccessfully.
                                (If node crashes, this attribute is not updated.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="completionTimestamp" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The moment when the task was marked as closed. (May be different from
                                lastRunFinishTimestamp, e.g. when task waits for its children to finish
                                and then closes automatically.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="cleanupAfterCompletion" type="xsd:duration" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                If set, the task is automatically cleaned up after this time following its completion.
                            </xsd:documentation>
							<xsd:appinfo>
								<a:since>3.7</a:since>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="nextRunStartTimestamp" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The time when the task should start again, according to the task's defined schedule.
								(Null if no further execution is scheduled.)
								Ad-hoc (retry) run times, like those stemming from unsatisfied execution constraints, are NOT
								considered here. They are covered by nextRetryTimestamp property.

                                TRANSIENT. This value is not stored in the repo, it is queried dynamically.
                                (It is currently not possible to use it for filtering or sorting.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="nextRetryTimestamp" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                If the start of a task was delayed (typically because of unsatisfied execution constraints),
								the planned retry time is reported here.

								EXPERIMENTAL.

                                TRANSIENT. This value is not stored in the repo, it is queried dynamically.
                                (It is currently not possible to use it for filtering or sorting.)
                            </xsd:documentation>
							<xsd:appinfo>
								<a:since>3.5</a:since>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="progress" type="xsd:long" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Relative metric of task progress. The meaning of this attribute
                                is specific to particular task handler.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="operationStats" type="tns:OperationStatsType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Operation statistics/state.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="stalledSince" type="xsd:dateTime" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                From which moment is this task stalled (if applicable)?
                                TRANSIENT. This value is not stored in the repo, it is queried dynamically.
                                (It is currently not possible to use it for filtering or sorting.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="expectedTotal" type="xsd:long" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Expected target (goal) value of task progress. Perceived progress
                                is computed as a ratio of progress/expectedTotal. May be null; in that
                                case we just do not know how much progress we should expect.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="recurrence" type="tns:TaskRecurrenceType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Whether the task activity is to be executed only once (single-run tasks)
                                or periodically (recurring tasks).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="binding" type="tns:TaskBindingType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Whether a recurring task is bound tightly to one node (having allocated
                                a thread on this node for the whole time of task execution) or it should
                                by dynamically placed on any suitable node when its execution time comes.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="canRunOnNode" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
									Whether a task is constrained to be run on a particular node,
									i.e. it will *not* be executed on a different node.
									If this attribute is not specified, the task will be executed on any available node.
                                </p>
                                <p>
									(There may be other constraints on the node(s) where this task may be run,
									determined e.g. by task handler.)
								</p>
                                <p>
									DEPRECATED. This attribute is not used. Please use executionConstraints/group instead.
                                </p>
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
					<xsd:element name="executionConstraints" type="tns:TaskExecutionConstraintsType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Constraints on task execution, e.g. a execution group, allowed/disallowed nodes, etc.
									EXPERIMENTAL
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.5</a:since>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
                    <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Task schedule. Specifies when and how often to execute the task.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="threadStopAction" type="tns:ThreadStopActionType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                What is to be done when the thread allocated to this task stops
                                (e.g. via node shutdown or node crash).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="modelOperationContext" type="tns:LensContextType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Model context of the operation that is to be executed within this task.
                                This is NOT a live information: it is a serialized form of a model context.
                                Currently there is a specialized task handler that takes this context,
                                unmarshalls and executes it.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="workflowContext" type="tns:WfContextType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Workflow context of the operation that is to be executed within this task.
                                Points to a process instance in a workflow engine, and to an externalized view
                                of its state.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                     <xsd:element name="policyRule" type="tns:PolicyRuleType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Policy rule for the task. E.g notify user 5 days before their account expires.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="task" type="tns:TaskType" substitutionGroup="c:object"/>

	<xsd:complexType name="TaskExecutionConstraintsType">
		<xsd:annotation>
			<xsd:documentation>
				Constraints on task execution, e.g. a execution group, allowed/disallowed nodes, etc.

				EXPERIMENTAL.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.5</a:since>
				<a:container>true</a:container>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="group" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						A group this task is a part of. In the future, task execution groups will probably have more
						complex parameters. But for now, their only parameter is the (clusterwide) member tasks limit.
						They are also referenced from NodeType when specifying execution limitations for them.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="groupTaskLimit" type="xsd:int" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Number of tasks within the group that can be executed at once (clusterwide). Default is "unlimited".
						This parameter will be moved into separate task group object in a later version of midPoint.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="secondaryGroup" type="tns:TaskExecutionGroupConstraintType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="allowedNode" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Node(s) that this task is allowed to be executed on. If not specified, the task is allowed
						to be executed on any cluster node (if not restricted by disallowedNode item).
						DEPRECATED and UNUSED. Use NodeType.taskExecutionLimitations instead.
					</xsd:documentation>
					<xsd:appinfo>
						<a:deprecated>true</a:deprecated>
						<a:deprecatedSince>3.7</a:deprecatedSince>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="disallowedNode" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Node(s) that this task is not allowed to be executed on.
						DEPRECATED and UNUSED. Use NodeType.taskExecutionLimitations instead.
					</xsd:documentation>
					<xsd:appinfo>
						<a:deprecated>true</a:deprecated>
						<a:deprecatedSince>3.7</a:deprecatedSince>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="retryAfter" type="xsd:duration" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						In what time to retry after clusterwide execution constraints are not met. The default is 1 minute.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="TaskExecutionGroupConstraintType">  <!-- TODO type name -->
		<xsd:annotation>
			<xsd:documentation>
				TODO
				EXPERIMENTAL.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
				<a:container>true</a:container>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="group" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="groupTaskLimit" type="xsd:int" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Number of tasks within the group that can be executed at once (clusterwide). Default is "unlimited".
						This parameter will be moved into separate task group object in a later version of midPoint.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="OperationStatsType">
        <xsd:annotation>
            <xsd:documentation>
                Operation execution statistics/state. Contains various statistical and state information about execution
                of the operation or operations that are carried out in the scope of the task.

                Not all parts of this structure are relevant for all task types. TODO handle this by subtyping - later.

                EXPERIMENTAL.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="environmentalPerformanceInformation" type="tns:EnvironmentalPerformanceInformationType" minOccurs="0"/>
            <xsd:element name="iterativeTaskInformation" type="tns:IterativeTaskInformationType" minOccurs="0"/>
            <xsd:element name="synchronizationInformation" type="tns:SynchronizationInformationType" minOccurs="0"/>
            <xsd:element name="actionsExecutedInformation" type="tns:ActionsExecutedInformationType" minOccurs="0"/>

            <xsd:element name="timestamp" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        When this information was collected from the "living" task.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="liveInformation" type="xsd:boolean" minOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        Source of the information - is it from repository or directly from the "living" task?
                        TRANSIENT INFORMATION, not stored in the repository. Filled in by task manager when fetching the task.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="TaskExecutionStatusType">
        <xsd:annotation>
            <xsd:documentation>
                Execution status provides information about the task overall high-level execution state. It tells
                whether the task is running/runnable, waits for something or is done.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="runnable">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is running or is ready to be executed. This state implies that the task is being
                        actively executed by IDM nodes, e.g. there is a thread on one of the IDM nodes that executes the
                        task, or the system needs to allocate such thread, or the task is prepared to be started
                        when a defined time arrives.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RUNNABLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="waiting">
                <xsd:annotation>
                    <xsd:documentation>
                        The IDM system is waiting while the task is being executed on an external node (e.g. external
                        workflow engine) or is waiting for some kind of external signal (e.g. approval in internal
                        workflow). The task may be running on external node or be blocked on IDM node. One way or another,
                        there is no point in allocating a thread to run this task. Other task properties provide more
                        information about the actual "business" state of the task.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WAITING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="suspended">
                <xsd:annotation>
                    <xsd:documentation>
                        The task has been suspended. It waits until an instruction to resume it arrives.
                        After that, it will (usually) go to the RUNNABLE state again. Or, it can be closed
                        in the suspended state as well.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SUSPENDED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="closed">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is done. No other changes or progress will happen. The task in this state is considered
                        immutable and the only things that can happen to it is a delete by a cleanup code.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CLOSED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="TaskRecurrenceType">
        <xsd:annotation>
            <xsd:documentation>
                Whether the task activity is to be executed only once (single-run tasks)
                or periodically (recurring tasks).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="single">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is executed only once, at the first moment that the schedule
                        specifies. If that moment is in the past, the task will be executed as
                        soon as any execution environment (node) is available.
                        Once the task is finished, it will not be executed again.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SINGLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="recurring">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is executed as many times as the schedule specifies.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RECURRING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="TaskBindingType">
        <xsd:annotation>
            <xsd:documentation>
                Whether a recurring task is bound tightly to one node (having allocated
                a thread on this node for the whole time of task execution) or it should
                by dynamically placed on any suitable node when its execution time comes.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="loose">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is exclusively assigned to a specific node only during its execution.

                        The thread is allocated only for the minimal amount of time.

                        It does not matter which node will execute the task as long as there is an appropriate handler.

                        This is efficient for tasks that take long time to execute and the execution mostly waits
                        (e.g. approvals) or for tasks which have long interval between executions (e.g. reconciliation).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOOSE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="tight">
                <xsd:annotation>
                    <xsd:documentation>
                        Task is exclusively assigned to a specific node from its start to its finish.

                        A thread will be running and allocated for the task all the time.
                        The thread may go to sleep as needed, but during that time the task remains assigned
                        to the node.

                        This is efficient for recurring tasks executed in short intervals, such as live synchronization.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TIGHT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="TaskWaitingReasonType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="otherTasks">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is waiting for other (dependent) tasks - either its subtasks, or tasks explicitly marked
                        as "prerequisites" for this task (via dependentTask property)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OTHER_TASKS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="workflow">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is waiting for a workflow process (that it monitors/shadows) to be finished.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WORKFLOW"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="other">
                <xsd:annotation>
                    <xsd:documentation>
                        The task is waiting because of other reason.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OTHER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="ThreadStopActionType">
        <xsd:annotation>
            <xsd:documentation>
                What is to be done when the thread allocated to this task stops
                (e.g. via node shutdown or node crash).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="restart">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be restarted on first node available
                        (i.e. either immediately, if there is a suitable node in the cluster,
                        or later, when a suitable node becomes available).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESTART"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="reschedule">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be rescheduled according to its schedule
                        (for single-run tasks this is the same as 'restart').
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESCHEDULE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="suspend">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be suspended.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SUSPEND"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="close">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be closed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CLOSE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="MisfireActionType">
        <xsd:annotation>
            <xsd:documentation>
                What is to be done when the planned start time arrives without
                the task actually starting.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="executeImmediately">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be executed immediately.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXECUTE_IMMEDIATELY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="reschedule">
                <xsd:annotation>
                    <xsd:documentation>
                        The task will be rescheduled according to its schedule.
                        This is to be used only for loosely-bound recurring tasks.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESCHEDULE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ScheduleType">
        <xsd:annotation>
            <xsd:documentation>
                Task schedule. Specifies when and how often something should happen.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="earliestStartTime" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Earliest time when the task is allowed to start.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="latestStartTime" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Latest time when the task is allowed to start.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="latestFinishTime" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Latest time when the task is allowed to run.
                        It is the responsibility of the task handler to finish
                        working when this time arrives.

                        NOTE: This attribute is currently not used; its use is planned.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="interval" type="xsd:int" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Interval in seconds between task runs.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="cronLikePattern" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Cron-like pattern specifying time(s) when the task is to be run.
                        Currently only loosely-bound recurring tasks can use this feature.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="misfireAction" type="tns:MisfireActionType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        What is to be done when the planned start time arrives without
                        the task actually starting.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="UriStack">
        <xsd:annotation>
            <xsd:documentation>
                A stack of URIs (used e.g. for managing a stack of handlers to be called when a task is to be run).
                Last URI is considered to be the top of the stack (i.e. the one that will be retrieved first).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="uriStackEntry" type="tns:UriStackEntry" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        An entry of the URI stack.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="UriStackEntry">
        <xsd:annotation>
            <xsd:documentation>
                An entry of the URI stack. It contains the handler URI as well as the schedule under which the handler should be run.
                This allows e.g. to run a "main" handler once, and then run a subhandler under a different schedule (e.g. cyclically).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="handlerUri" type="xsd:anyURI">
                <xsd:annotation>
                    <xsd:documentation>
                        URI of the task handler.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="recurrence" type="tns:TaskRecurrenceType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Recurrence type of this task (may be null - in that case it is guessed from the schedule).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Schedule under which this handler should be executed (may be null).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="binding" type="tns:TaskBindingType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Binding with which this handler should be executed (default = derived from schedule)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="extensionDelta" type="t:ItemDeltaType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        List of deltas that should be put into extension when starting this handler.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="FocusType" abstract="true">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
                    Abstract supertype for all object types that can be focus of midPoint computation.
            	</p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:object/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>

                    <xsd:element name="link" type="tns:ShadowType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:linkRef</a:objectReference>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="linkRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Set of shadows (projections) linked to this focal object.
                                E.g. a set of accounts linked to a user. This is the set of
                                shadows that belongs to the focal object in a sense
                                that these shadows represents the focal object on the resource.
                                E.g. The set of accounts that represent the same midPoint user (the
                                same physical person, they are "analogous").
                                </p>
                                <p>
                                Links define what the object HAS. The links reflect real state of things
                                (cf. assignment).
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ShadowType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="personaRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Set of personas linked to this focal object.
                                E.g. a set of virtual identities linked to a user. This is the set of
                                "secondary" focal objects that belongs to this focal object in a sense
                                that the currect focal object is in control over the linked focal objects.
                                E.g. this reference can be used to link user object which specified a physical
                                person with his virtual identities (personas) that specify his identity as an
                                employee, system administrator, customer, etc.
                                The deafalt meaning is that the personas are ""analogous", i.e. the represent
                                different facets of the same physical person. However, this meaning may be 
                                theoretically overridden by using various relation parameters in this reference. 
                                </p>
                                <p>
                                This reference define what the object HAS. The links reflect real state of 
                                things (cf. assignment).
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:FocusType</a:objectReferenceTargetType>
                    			<a:since>3.6</a:since>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="assignment" type="tns:AssignmentType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Set of object's assignments.
                                Assignments define the privileges and "features" that this object should have, that
                                this object is entitled to. Typical assignment will point to a role or define
                                a construction of an account.
                                </p>
                                <p>
                                Assignments represent what the object SHOULD HAVE. The assignments represent a policy,
                                a desired state of things (cf. linkRef).
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>FocusType.assignmentKey</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="activation" type="tns:ActivationType" minOccurs="0" maxOccurs="1">
                    </xsd:element>
                    
                    <xsd:element name="iteration" type="xsd:int" minOccurs="0">
                    <xsd:annotation>
                    	<xsd:documentation>
                    		Iteration number. Starts with 0. It is used to iterativelly find unique identifier
                    		for the object.
                    	</xsd:documentation>
                    	<xsd:appinfo>
            				<a:operational>true</a:operational>
            			</xsd:appinfo>
                    </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="iterationToken" type="xsd:string" minOccurs="0">
	                    <xsd:annotation>
	                    	<xsd:documentation>
	                    		Iteration token. String value that is usualy a suffix to the identifier based
	                    		on iteration number. E.g. ".007". It is used to iterativelly find unique identifier
	                    		for the object.
	                    	</xsd:documentation>
	                    	<xsd:appinfo>
	            				<a:operational>true</a:operational>
	            			</xsd:appinfo>
            			</xsd:annotation>
                    </xsd:element>

                    <xsd:element name="roleMembershipRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                  References to abstract roles (roles, orgs, services) that this focus currently belongs to - directly
                                  or indirectly. This reference points to all the roles in the role hierarchy. It only points to
                                  the roles that were evaluated as active during last recompute (conditions were true, validity
                                  constraints not violated).
                                </p>
                                <p>
                                  Note: the value of this reference is only updated when a focal object is recomputed.
                                  Therefore if a role definition changes then all the affected focal objects must be recomputed
                                  for this reference to be consistent.
                                </p>
								<p>
								  Roles mentioned here are those that are NOT obtained via delegation, i.e. "deputy" relations.
								  Relations acquired by delegation are listed in delegatedRef item.
								</p>
                                <p>
                                  This is an operational property. It is set and managed by the system. It is used
                                  for efficient search of all current role members, e.g. for the purpose of displaying this
                                  information in the GUI.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:AbstractRoleType</a:objectReferenceTargetType>
                    			<a:operational>true</a:operational>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="delegatedRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
									References to objects (abstract roles as well as users) obtained via delegation.
									If A1 is a deputy of A, its delegatedRef contains a union of A, A.roleMembershipRef and
									A.delegatedRef.
								</p>
                                <p>
									This is an operational property. It is set and managed by the system. It is used
									for efficient search of all current role members, e.g. for the purpose of displaying this
									information in the GUI.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:FocusType</a:objectReferenceTargetType>
                    			<a:operational>true</a:operational>
								<a:since>3.5</a:since>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="roleInfluenceRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                  References to abstract roles (roles and orgs) that this focus may directly belong to. 
                                  This reference only points to the next role in the hierarchy. However, it is backed by
                                  a "closure" index in the repository subsystem. Therefore it can efficiently support tree-like
                                  queries. This reference points to the roles for whose the condition is not true. 
                                  Therefore it does not reliably show
                                  who actually has a role. It shows potential role members - all the object that are possibly
                                  influenced when a role definition changes.
                                </p>
                                <p>
                                  This is an operational property. It is set and managed by the system. It is used
                                  for efficient search of all possible role members, e.g. for the purpose of recomputing
                                  all role members after the role definition is changed.
                                </p>
                                <p>
                                	TODO. NOT IMPLEMENTED YET. EXPERIMENAL. UNSTABLE.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:AbstractRoleType</a:objectReferenceTargetType>
                    			<a:operational>true</a:operational>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="jpegPhoto" type="xsd:base64Binary" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                    Photo corresponding to the user / org / role.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>FocusType.jpegPhoto</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
				</xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="focus" type="tns:FocusType"/>
	    
    <xsd:complexType name="UserType">
        <xsd:annotation>
            <xsd:documentation>
            	User object represents a physical user of the system.
            	It differs from the account, as "account" represents a data structure in a target system while
            	"user" represents data structure in midPoint. One user typically has many accounts.
            	Properties of User object typically describe the user as a physical person.
            	Therefore the user obect defines handful of properties that are commonly used to describe users
            	in the IDM solutions (employees, customers, partners, etc.) Custom extensions are possible by utilizing
            	the "extension" container.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:FocusType">
                <xsd:sequence>
                    <xsd:element name="fullName" type="t:PolyStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Full name of the user with all the decorations,
                                middle name initials, honorific title and any
                                other structure that is usual in the cultural
                                environment that the system operates in. This
                                element is intended to be displayed to
                                a common user of the system.
                                </p>

                                <p>
                                Examples:
                                    <ul>
                                        <li>cpt. Jack Sparrow</li>
                                        <li>William "Bootstrap" Turner</li>
                                        <li>James W. Random, PhD.</li>
                                        <li>Vladimir Iljic Lenin</li>
                                        <li>Josip Broz Tito</li>
                                        <li>Chuck Norris</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.fullName</a:displayName>
		                    	<a:displayOrder>100</a:displayOrder>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="givenName" type="t:PolyStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Given name of the user. It is usually the first
                                name of the user, but the order of names may
                                differ in various cultural environments. This
                                element will always contain the name that was
                                given to the user at birth or was chosen
                                by the user.
                                </p>

                                <p>
                                Examples:
                                    <ul>
                                        <li>Jack</li>
                                        <li>Chuck</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.givenName</a:displayName>
		                    	<a:displayOrder>110</a:displayOrder>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="familyName" type="t:PolyStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                Family name of the user. It is usually the last
                                name of the user, but the order of names may
                                differ in various cultural environments. This
                                element will always contain the name that was
                                inherited from the family or was assigned
                                to a user by some other means.
                                </p>

                                <p>
                                Examples:
                                    <ul>
                                        <li>Sparrow</li>
                                        <li>Norris</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.familyName</a:displayName>
		                    	<a:displayOrder>120</a:displayOrder>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="additionalName" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Middle name, patronymic, matronymic or any other name of a person. It is usually the
	                                middle component of the name, however that may be culture-dependent.
								</p>
								<p>
                                Examples:
                                    <ul>
                                        <li>Walker</li>
                                        <li>John</li>
                                        <li>Iljic</li>
                                    </ul>
                                </p> 
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.additionalName</a:displayName>
		                    	<a:displayOrder>130</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="nickName" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Familiar or otherwise informal way to address a person.
                                </p>
                                <p>
                                Examples:
                                    <ul>
                                        <li>Bootstrap</li>
                                        <li>Bobby</li>
                                    </ul>
                                </p>  
                                <p>
	                                The meaning of this property is to take part in the formatted full
	                                name of the person, e.g. William "Bootstrap" Turner. It is not intended
	                                to be used as a username or login name. This value is usually changable
	                                by the user itself and it defines how the user wants other to address him.
	                                Therefore it is not ideal for use as an identifier.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.nickName</a:displayName>
		                    	<a:displayOrder>140</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="honorificPrefix" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Honorific titles that go before the name.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>cpt.</li>
                                        <li>Ing.</li>
                                        <li>Sir</li>
                                    </ul>
                                </p>
                                <p>  
	                                This property is single-valued. If more
	                                than one title is applicable, they have to be represented in
	                                a single string (concatenated) form in the correct order.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.honorificPrefix</a:displayName>
		                    	<a:displayOrder>150</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="honorificSuffix" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Honorific titles that go after the name.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>PhD.</li>
                                        <li>KBE</li>
                                    </ul>
                                </p>
                                <p>  
	                                This property is single-valued. If more
	                                than one title is applicable, they have to be represented in
	                                a single string (concatenated) form in the correct order.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.honorificSuffix</a:displayName>
		                    	<a:displayOrder>160</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="title" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                User's title defining a work position or a primary role in the
	                                organization.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>CEO</li>
                                        <li>Security Officer</li>
                                        <li>Assistant</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.title</a:displayName>
		                    	<a:displayOrder>170</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="preferredLanguage" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Indicates user's preferred language, usually for the purpose of localizing
	                                user interfaces. The format is IETF language tag defined in BCP 47, where
	                                underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter
	                                language code optionally followed by ISO 3166-1 two letter country code 
	                                separated by underscore. The languages that do not have coutry-specific
	                                variants are usually specified by using a two-letter coutry code ("sk", 
	                                "cs", "tr"). Languages with coutry-specific variants have country-specific
	                                subtags ("pt_BR", "zn_CN").
	                                If no value is specified in this property then system default locale is assumed.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>en_US</li>
                                        <li>sk</li>
                                        <li>cs</li>
                                        <li>pt_BR</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.preferredLanguage</a:displayName>
		                    	<a:displayOrder>200</a:displayOrder>
		                    	<a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000200" type="tns:LookupTableType"/>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="locale" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Defines user's preference in displaying currency, dates and other items
	                                related to location and culture. The format is IETF language tag defined in BCP 47, where
	                                underscore is used as a subtag separator. This is usually a ISO 639-1 two-letter
	                                language code optionally followed by ISO 3166-1 two letter country code 
	                                separated by underscore. The languages that do not have coutry-specific
	                                variants are usually specified by using a two-letter coutry code ("sk", 
	                                "cs", "tr"). Languages with coutry-specific variants have country-specific
	                                subtags ("pt_BR", "zn_CN").
	                                If not specified then system default locale is assumed.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>en_US</li>
                                        <li>sk</li>
                                        <li>cs</li>
                                        <li>pt_BR</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.locale</a:displayName>
		                    	<a:displayOrder>210</a:displayOrder>
		                    	<a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000210" type="tns:LookupTableType"/>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="timezone" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                User's preferred timezone. It is specified in the "tz database" (a.k.a "Olson")
	                                format. If not specified then system default timezone is assumed.
                                </p>
								<p>
                                Examples:
                                    <ul>
                                        <li>Europe/Bratislava</li>
                                    </ul>
                                </p> 
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>UserType.timezone</a:displayName>
		                    	<a:displayOrder>220</a:displayOrder>
		                    	<a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000220" type="tns:LookupTableType"/>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="emailAddress" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                E-Mail address of the user. This is the address
	                                supposed to be used for communication with the
	                                user. E.g. IDM system may send notifications
	                                to the e-mail address. It is NOT supposed to be
	                                full-featured e-mail address data structure
	                                e.g. for the purpose of complex address-book application.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.EmailAddress</a:displayName>
                                <a:displayOrder>300</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="telephoneNumber" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Primary telephone number of the user.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.telephoneNumber</a:displayName>
                                <a:displayOrder>310</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="employeeNumber" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Unique, business-oriented identifier of the employee.
	                                Typically used as correlation identifier and for
	                                auditing purposes. Should be immutable, but the
	                                specific properties and usage are deployment-specific.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.employeeNumber</a:displayName>
                                <a:displayOrder>400</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="employeeType" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Employee type specification such as internal employee,
	                                external or partner. The specific values are
	                                deployment-specific. However it is generally assumed that this
	                                will be enumeration of several type names or codes that define
	                                "classes" of users.
                                </p>
                                <p>
                                	Even though this property is named "employeeType" due to the historical
                                	reasons it is used in a more generic way to mean general type of user.
                                	Therefore it can be used to distinguish employees from customers, etc.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.employeeType</a:displayName>
                                <a:displayOrder>410</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="costCenter" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	The name, identifier or code of the cost center to which the user belongs.
                                </p>
                            	<p>
                                	Please note that organization objects (OrgType) also have a costCenter property.
                                	Therefore it is usual that if a user belongs to an organization the costCenter from
                                	the organization is used. Therefore this property is usually used only for users that
                                	do not belong to any organization or for users that have different cost center than
                                	the one defined by the organization.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.costCenter</a:displayName>
                                <a:displayOrder>420</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="organization" type="t:PolyStringType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Name or (preferably) immutable identifier of organization that the user belongs to.
	                                The format is deployment-specific. This property together with organizationalUnit
	                                may be used to provide easy-to-use data about organizational membership of the user.
								</p>
								<p>
	                                This is multi-valued property to allow membership of a user to several
	                                organizations. Please note that midPoint does not maintain ordering in
	                                multi-value properties therefore this is not usable to model a complex
	                                organization hierarchies. Use OrgType instead.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.organization</a:displayName>
                                <a:displayOrder>430</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="organizationalUnit" type="t:PolyStringType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Name or (preferrably) immutable identifier of organizational unit that the user belongs to.
	                                The format is deployment-specific. This property together with organization
	                                may be used to provide easy-to-use data about organizational membership of the user.
                                </p>
                                <p>
	                                This is multi-valued property to allow membership of a user to several
	                                organizational units. Please note that midPoint does not maintain ordering in
	                                multi-value properties therefore this is not usable to model a complex
	                                organization hierachies. Use OrgType instead.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.organizationalUnit</a:displayName>
                                <a:displayOrder>440</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="locality" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Primary locality of the user, the place where
	                                the user usually works, the country, city or
	                                building that he belongs to. The specific meaning
	                                and form of this property is deployment-specific.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.locality</a:displayName>
                                <a:displayOrder>450</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="credentials" type="tns:CredentialsType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                The set of user's credentials (such as passwords).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>UserType.credentials</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

					<xsd:element name="adminGuiConfiguration" type="tns:AdminGuiConfigurationType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Specifies the admin GUI configuration that should be used
									by this user.
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.5</a:since>
								<a:displayName>AdminGuiConfigurationType.adminGuiConfiguration</a:displayName>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>

                    <xsd:element name="result" type="tns:OperationResultType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                User's result for the operation. e.g. set by recompute status.
								DEPRECATED. Use ObjectType.operationExecution instead.
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.6</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="user" type="tns:UserType" substitutionGroup="c:object"/>


    <xsd:complexType name="CredentialsType">
        <xsd:annotation>
            <xsd:documentation>
                This is a container type for various credentials types: passwords, public keys, one-time password
                scheme identifiers, etc. However, we expect that password will be the most widely used credential
                type and that's actually also the only supported type.

                The reason to "formalize" this structure is the ability to synchronize credentials. If the password
                would be just an ordinary attribute, we cannot automatically synchronize user and account passwords.
                Similarly as other credential types.
                Note: marking password with a special attribute type will not be enough. There may be numerous passwords
                with various meanings, we need to distinguish the "primary" one to synchronize. We also need to store
                user password somewhere.

                This is not perfect. It may change in the future.

                TODO: support for "old password", e.g. some resource need it to change password.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="password" type="tns:PasswordType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>CredentialsType.password</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="nonce" type="tns:NonceType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>CredentialsType.nonce</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="securityQuestions" type="tns:SecurityQuestionsCredentialsType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>CredentialsType.securityQuestions</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <!-- More credentail types may be here, such as OTP seeds, X.509 credentials, 
				etc. -->
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    <xsd:element name="credentials" type="tns:CredentialsType"/>
    
    <xsd:complexType name="AbstractCredentialType" abstract="true">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Name of the credential. It is used as an identifier that
                        specifies credential purpose. E.g. it may specify whether
                        this is default user password or administration password,
                        whether this is a nonce for registration or password reset
                        and so on. Simply speaking the name is used to distinguish
                        credetials that have the same type but different purpose.
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="failedLogins" type="xsd:int" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The number of failed logins. It should be
                        increased after every unsuccessful use of
                        the credential. It may be reset after
                        successful login or a time-out or may not.
                        It depends on the policy setting. If
                        not present, value of zero (0) is assumed.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="lastSuccessfulLogin" type="tns:LoginEventType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The date and time of last successful login attempt.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="previousSuccessfulLogin" type="tns:LoginEventType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The date and time of successful before the last login attempt.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="lastFailedLogin" type="tns:LoginEventType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The date and time of last successful login attempt.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO: lockoutTimestamp -->
            <xsd:element name="metadata" type="tns:MetadataType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Timestamps and general metadata describing the credential change.
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="forceChange" type="xsd:boolean" minOccurs="0" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        If it is required to change password. E.g. there are situation when you set first password
                        for the user, but after the user fist log in to the system, he/she has to change his/her password.
                    </xsd:documentation>
					<xsd:appinfo>
						<a:displayName>AbstractCredentialType.forceChange</a:displayName>
						<a:operational>true</a:operational>
						<a:experimental>true</a:experimental>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>

    <xsd:complexType name="PasswordType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:AbstractCredentialType">
        		<xsd:sequence>
            		<xsd:element name="value" type="t:ProtectedStringType" minOccurs="0">
						<xsd:annotation>
							<xsd:appinfo>
								<a:displayName>PasswordType.value</a:displayName>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
            		<xsd:element name="historyEntry" type="tns:PasswordHistoryEntryType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <a:operational/>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
            	</xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="NonceType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:AbstractCredentialType">
        		<xsd:sequence>
            		<xsd:element name="value" type="t:ProtectedStringType" minOccurs="0"/>
            	</xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="PasswordHistoryEntryType">
        <xsd:annotation>
        	<xsd:documentation>
        		Contains a single entry of the password history. It contains a historical value
        		of a password together with essential metadata.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
		<xsd:sequence>
	  		<xsd:element name="metadata" type="tns:MetadataType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Timestamps and general metadata describing the credential change.
            			This is a copy of the original metadata of the password before it was
            			changed and before it was moved to the history.
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="value" type="t:ProtectedStringType" minOccurs="0"/>
            <xsd:element name="changeTimestamp" type="xsd:dateTime" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					The timestamp when this password was changed to a different value.
    					This is different from the date in metadata. The dates in metadata
    					tells when this password was created (when it started to be valid).
    					The changeTimestamp tells when the password stopped to be valid and
    					was moved to the history entries. This timestamp can be used to
    					chronologically order the entries.
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:operational>true</a:operational>
    					<a:indexed>true</a:indexed>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
	  	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:complexType name="SecurityQuestionsCredentialsType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:AbstractCredentialType">
        		<xsd:sequence>
            		<xsd:element name="questionAnswer" type="tns:SecurityQuestionAnswerType" minOccurs="0" maxOccurs="unbounded"/>
            	</xsd:sequence>	
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="SecurityQuestionAnswerType">
    	<xsd:annotation>
    		<xsd:documentation>
    			Answer to the security question. This is a "personalized" answer and it is supposed to
    			be associated with a single user. However, it may also optionally contain a question.
    			E.g. in case a user specified a custom question.
    		</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
    	</xsd:annotation>
        <xsd:sequence>
        	
        	<xsd:element name="questionIdentifier" type="xsd:anyURI" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				Identifier of a question that this answer applies to. It is expected to be
        				present only if this is an answer to a "configured question", i.e. a question
        				that is defined in a security policy.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	
        	  	<xsd:element minOccurs="0" maxOccurs="1" name="questionAnswer" type="t:ProtectedStringType">
        		<xsd:annotation>
        			<xsd:documentation>
        				Answer to the question
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	
        	  <xsd:element name="enabled" type="xsd:boolean" minOccurs="0" default="true">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>Flag indicating that this particular question is enabled.
                           It can be used to temporarily disable a question.</p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>

    <xsd:complexType name="LoginEventType">
        <xsd:sequence>
            <xsd:element name="timestamp" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The date and time of login attempt.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="from" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The source from where the login came. It is supposed to be human-readable,
                        e.g. a hotname, IP address, etc.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AssignmentType">
        <xsd:annotation>
            <xsd:documentation>
                Generic assignments of one object to another object.
                This will usually be assignment of a role to a user, assignment of an
                organizational unit, team or whatever. It may also be used to assign
                role to another role, creating a role hierarchy.

                Assignment is an abstract concept. It can be anything that
                gives the "receptor" object additional access rights, privileges,
                capabilities or similar ability or right. But it may also constraint
                the object with policy, e.g. to implement separation of duties. Roles,
                organizations and privileges in IDM system are examples of assignments.

                The assignment may target either existing IDM object (such as a role)
                or abstract resource account that may or may not exist. In case of resource
                objects it is constrained to accounts, as accounts are the only resource objects
                that can be assigned to a user. Other resource objects (entitlements) can
                be assigned to accounts, but not to users.

                TODO: constraints

            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:displayName>AssignmentType.assignment</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        
        	<xsd:element name="description" type="xsd:string" minOccurs="0">
        		<xsd:annotation>
        			<xsd:appinfo>
        				<a:displayName>AssignmentType.description</a:displayName>
        				<a:help>AssignmentType.description.help</a:help>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        
        	<xsd:element ref="tns:extension" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				The assignment extension used to add parameters to the assignment.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	
        	<xsd:element name="lifecycleState" type="xsd:string" minOccurs="0" maxOccurs="1">
	        	<xsd:annotation>
	        		<xsd:documentation>
                        <p>
	        				Lifecycle state of the assignment. This property defines whether the
	        				assignment 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 assignment in progress. The assignment is 
										NOT active. The definition may change at any moment. It is
										not ready yet.</li>
							<li>proposed: Definition of a new assignment is ready for use, but there 
										is still a review process to be applied (e.g. approval).
										The assignment is NOT active. However the definition should 
										not change in this state.
										This is the state applied to requested and not yet approved
										assignments.</li>
							<li>active: Active and working definition.</li>
							<li>deprecated: Active definition which is being phased out. The
										definition is still fully operational. But it should be
										replaced by a new assignment.</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 occured during assignment lifecycle. Result
										of that event is that the assignment is rendered inactive.
										The situation cannot be automatically remedied. Manual action
										is needed.</li>
                        </ul>
	        		</xsd:documentation>
	        		<xsd:appinfo>
	        			<a:since>3.5</a:since>
	        			<a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000230" type="tns:LookupTableType"/>
	        			<a:displayName>AssignmentType.lifecycleState</a:displayName>
        				<a:help>AssignmentType.lifecycleState.help</a:help>
	        		</xsd:appinfo>
	        	</xsd:annotation>
	        </xsd:element>
        	
        	<xsd:element name="metadata" type="tns:MetadataType" minOccurs="0"/>
        
            <xsd:choice>

                <xsd:element name="target" type="tns:ObjectType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Target of assignment or inducement. This is the role, org or service that is assigned.
                        </xsd:documentation>
                        <xsd:appinfo>
                    		<a:objectReference>tns:targetRef</a:objectReference>
                            <a:displayName>AssignmentType.target</a:displayName>
                            <a:help>AssignmentType.target.help</a:help>
                    	</xsd:appinfo>
                    </xsd:annotation>
                </xsd:element>

                <xsd:element name="targetRef" type="c:ObjectReferenceType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Target of assignment or inducement. This is the role, org or service that is assigned.
                        </xsd:documentation>
                        <xsd:appinfo>
                            <a:displayName>AssignmentType.target</a:displayName>
                            <a:help>AssignmentType.target.help</a:help>
                        </xsd:appinfo>
                    </xsd:annotation>
                </xsd:element>
                
                <xsd:element name="construction" type="tns:ConstructionType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Projection construction. This structure defines how a projection
                            (e.g. account) should be constructed.
                        </xsd:documentation>
                        <xsd:appinfo>
                            <a:displayName>AssignmentType.construction</a:displayName>
                        </xsd:appinfo>
                    </xsd:annotation>
                </xsd:element>
                
                <xsd:element name="personaConstruction" type="tns:PersonaConstructionType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Persona construction. This structure defines how a persona
                            (e.g. virtual identity) should be constructed.
                        </xsd:documentation>
                        <xsd:appinfo>
                            <a:displayName>AssignmentType.personaConstruction</a:displayName>
                            <a:since>3.6</a:since>
                        </xsd:appinfo>
                    </xsd:annotation>
                </xsd:element>
                
                <xsd:element name="focusMappings" type="tns:MappingsType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Set of mappings that are applied to a focus in addition to object template.
                        </xsd:documentation>
                    </xsd:annotation>
                </xsd:element>
                
                <xsd:element name="policyRule" type="tns:PolicyRuleType" minOccurs="0">
                    <xsd:annotation>
                        <xsd:documentation>
                            Policy rule that should be applied to the target object.
                        </xsd:documentation>
						<xsd:appinfo>
							<a:displayName>AssignmentType.policyRule</a:displayName>
							<a:help>AssignmentType.policyRule.help</a:help>
						</xsd:appinfo>
                    </xsd:annotation>
                </xsd:element>

            </xsd:choice>

            <xsd:element name="activation" type="tns:ActivationType" minOccurs="0"/>

			<xsd:element name="order" type="xsd:int" minOccurs="0">
		        <xsd:annotation>
		            <xsd:documentation>
		                Order of the inducement. Simply speaking order specifies the number
		                of assignments that the evaluation must traverse to apply the inducement.
		                The high-order inducements are used in meta-roles. These high-order inducements
		                apply to the object that is assigned to the role instead of meta-role.
		                
		                This property specifies the summary order. This is a sum of all the (non-delegation)
		                assignments along the assignment path. More precise control over the order can
		                be achieved by using the orderConstraints.
		                
		                If not specified and no orderConstraints are specified then the values of 1 is assumed.
		            </xsd:documentation>
		        	<xsd:appinfo>
                        <a:displayName>AssignmentType.order</a:displayName>
                        <a:help>AssignmentType.order.help</a:help>
		        	</xsd:appinfo>
		        </xsd:annotation>
			</xsd:element>
			<xsd:element name="orderConstraint" type="tns:OrderConstraintsType" minOccurs="0" maxOccurs="unbounded">
		        <xsd:annotation>
		            <xsd:documentation>
		                Constraint that defines the range of "orders" and relations when this assignment/inducement should be applied.
		            </xsd:documentation>
		            <xsd:appinfo>
		                <a:since>3.5</a:since>
		            </xsd:appinfo>
		        </xsd:annotation>			
			</xsd:element>
			
			<xsd:element name="limitTargetContent" type="tns:AssignmentSelectorType" minOccurs="0" maxOccurs="1">
		        <xsd:annotation>
		            <xsd:documentation>
		                Limitations that selects only some assignments/inducements from the target. It may be used to
		                incorporate only a part of the subrole in the role hierarchy. But it is most frequently used
		                to limit the scope of a delegation to the deputy.
						It not specified, no limitations of this kind take place.
		            </xsd:documentation>
		            <xsd:appinfo>
		                <a:since>3.5</a:since>
		            </xsd:appinfo>
		        </xsd:annotation>			
			</xsd:element>
			<xsd:element name="limitOtherPrivileges" type="tns:OtherPrivilegesLimitationType" minOccurs="0" maxOccurs="1">
		        <xsd:annotation>
		            <xsd:documentation>
		                Limitations related to other privileges, like the ability to complete work items.
						If not specified, no limitations of this kind take place.
		            </xsd:documentation>
		            <xsd:appinfo>
		                <a:since>3.6</a:since>
		            </xsd:appinfo>
		        </xsd:annotation>
			</xsd:element>

			<xsd:element name="focusType" type="xsd:QName" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Type of focal object that this assingnment/inducement applies to. E.g UserType, RoleType, OrgType, ...
					</xsd:documentation>
					<xsd:appinfo>
						<a:displayName>AssignmentType.focusType</a:displayName>
                        <a:help>AssignmentType.focusType.help</a:help>
					</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 which this assignment is associated with. This is an argument to the target of this
                        assignment. E.g. is if frequently used to parametrize the role which is assigned by this assignment.
                        However the exact interpretation of this value depends on the logic of the target role. It may be
                        significant or it may be entirely ignored.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
                        <a:displayName>AssignmentType.tenantReference</a:displayName>
                        <a:help>AssignmentType.tenantReference.help</a:help>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="orgRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                        Reference to the organization (org. unit, project, ...) which this assignment is associated with. This is an argument to the target of this
                        assignment. E.g. is if frequently used to parametrize the role which is assigned by this assignment.
                        However the exact interpretation of this value depends on the logic of the target role. It may be
                        significant or it may be entirely ignored.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
                        <a:displayName>AssignmentType.orgReference</a:displayName>
                        <a:help>AssignmentType.orgReference.help</a:help>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            
            <xsd:element name="condition" type="tns:MappingType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The assignment is applied only if the condition is evaluated to true.
                        If condition is not present, it is assumed to be true.
                    </xsd:documentation>
                </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 assignment. The situations are result of
                        evaluation of the policy rules. This property is recorded for each assignment
                        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>
							<a:displayName>AssignmentType.policySituation</a:displayName>
							<a:help>AssignmentType.policySituation.help</a:help>
						</xsd:appinfo>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            
            <xsd:element name="trigger" type="tns:EvaluatedPolicyRuleTriggerType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
						DEPRECATED. DO NOT USE.
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:since>3.6</a:since>
						<a:deprecated>true</a:deprecated>
						<a:deprecatedSince>3.7</a:deprecatedSince>
						<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="id" type="xsd:long" use="optional"/>
    </xsd:complexType>

    <xsd:element name="assignment" type="tns:AssignmentType"/>
    
    <xsd:complexType name="OrderConstraintsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.5</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       	<xsd:sequence>
       		<xsd:element name="order" type="xsd:int" minOccurs="0" maxOccurs="1" default="1">
	   			<xsd:annotation>
    				<xsd:documentation>
    					Exact order to match. This is a short-hand for setting both
    					orderMin and orderMax to the same value.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
   			<xsd:element name="orderMin" type="xsd:string" minOccurs="0" maxOccurs="1">
	   			<xsd:annotation>
    				<xsd:documentation>
    					Minimum matching order. Applicable only if "order" element is not set.
    					Numeric value or string "unbounded".
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
   			<xsd:element name="orderMax" type="xsd:string" minOccurs="0" maxOccurs="1">
	   			<xsd:annotation>
    				<xsd:documentation>
    					Maximum matching order. Applicable only if "order" element is not set.
    					Numeric value or string "unbounded".
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
			<xsd:element name="resetOrder" type="xsd:int" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						The new value for order for this relation (or summary order), to be used when
						evaluating subsequent inducements.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
    		<xsd:element name="relation" type="xsd:QName" minOccurs="0" maxOccurs="1">
	   			<xsd:annotation>
    				<xsd:documentation>
    					Relation to which the order constraints apply. If none present, summary (i.e. non-delegation) order is considered.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
       </xsd:sequence>
	</xsd:complexType>
    
    <xsd:complexType name="MappingsType">
        <xsd:annotation>
            <xsd:documentation>
                Generic set of mappings.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
       	<xsd:sequence>
       		<xsd:element ref="tns:description" minOccurs="0"/>
   			<xsd:element name="mapping" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
                   </xsd:element>
       </xsd:sequence>
	</xsd:complexType>

    <xsd:complexType name="ActivationType">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	                Type that defines activation properties. Determines whether something is active
	                (and working) or inactive (e.g. disabled).
                </p><p>
	                It applies to several object types. It may apply to user, account, assignement, etc.
	                The data in this type define if the described concept is active, from when it is active
	                and until when. The "active" means that it works. If something is not active, it should
	                not work or not cause any effect. E.g. inactive user should not be able to log in or run
	                any tasks, the non-active role should not be assigned and if assigned it should not be
	                taken into account when computing the accounts.
	            </p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:displayName>ActivationType.activation</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="administrativeStatus" type="tns:ActivationStatusType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        This defines the "administrative state", i.e. the administrator's decision.
	                        If set, this property overrides any other constraints in the activation type.
	                        E.g. if this is set to "enabled" and the object is not yet valid (according to
	                        validFrom below), the user should be considered active. If set to "disabled" the
	                        user should be considered inactive regardless of other settings.
                        </p><p>
	                        Therefore this property does NOT define an actual state of
	                        the object. It is a kind of "manual override".
                        </p><p>
	                        If this property is not present then the other constraints in the activation type
	                        should be considered.
                        </p><p>
	                        If the administrative status is not present and there are no other constraints in
	                        the activation type or if there is no activation type at all then the object is 
	                        assumed to be "enabled", i.e. that the described concept is active.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.administrativeStatus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="effectiveStatus" type="tns:ActivationStatusType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        This defines the "effective state", i.e. the result of combining several
	                        activation settings (administrative status, validity dates, etc.).
                        </p><p>
	                        This holds the result of a computation, therefore it is kind of VIRTUAL property
	                        that is recomputed every time. It SHOULD NOT be set directly but it rather should be
	                        computed from the values of other activation properties. Therefore it is considered
	                        READ ONLY for the high-level code. It may be stored in the repository but in that
	                        case it has only an informational value (the effective activation status at the time
	                        the object was last updated).
                        </p><p>
                        	If this property is not present then the computation haven't taken place yet.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:operational>true</a:operational>
                        <a:displayName>ActivationType.effectiveStatus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="validFrom" type="xsd:dateTime" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        A date from which is should the object be considered active.
	                        Not applied if the "enabled" flag is set to any value.
	                    </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.validFrom</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="validTo" type="xsd:dateTime" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        A date to which is should the object be considered active.
	                        Not applied if the "enabled" flag is set to any value.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.validTo</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="validityStatus" type="tns:TimeIntervalStatusType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        This property holds the result of vality period computation with respect to the current
	                        date and time. E.g. it specifies whether the entity is before the validity period,
	                        in the validity perion or after validity period.
                        </p><p>
	                        This holds the result of a computation, therefore it is kind of VIRTUAL property
	                        that is recomputed every time. It SHOULD NOT be set directly but it rather should be
	                        computed from the values of validity timestamps and current time. Therefore it is considered
	                        READ ONLY for the high-level code. It may be stored in the repository but in that
	                        case it has only an informational value (the effective activation status at the time
	                        the object was last updated).
						</p><p>
	                        If this property is not present then the computation haven't taken place yet.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.validityStatus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="disableReason" type="xsd:anyURI" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			<p>
	            			URL that identifies a reason for disable. This may be indication that that identity
	            			was disabled explicitly, that the disable status was computed or other source of the
	            			disabled event.
            			</p>
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="disableTimestamp" type="xsd:dateTime" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			<p>
	            			Timestamp of last modification of the activation status to the disabled state.
	            			Note: This timestamp is used for recording purposes. Changing it will NOT change
	            			the activation state.
            			</p>
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="enableTimestamp" type="xsd:dateTime" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			<p>
	            			Timestamp of last modification of the activation status to the enabled state.
	            			Note: This timestamp is used for recording purposes. Changing it will NOT change
	            			the activation state.
            			</p>
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="archiveTimestamp" type="xsd:dateTime" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			<p>
	            			Timestamp of last modification of the activation status to the archived state.
	            			Note: This timestamp is used for recording purposes. Changing it will NOT change
	            			the activation state.
            			</p>
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="validityChangeTimestamp" type="xsd:dateTime" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			<p>
	            			Timestamp of last modification of the effective validity state, i.e. last time the validity
	            			state was recomputed with result that was different than the previous recomputation. It is
	            			used to avoid repreated validity change deltas.
	            			Note: This timestamp is used for recording purposes. Changing it will NOT change
	            			the activation state.
            			</p>
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:operational>true</a:operational>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            
            <xsd:element name="lockoutStatus" type="tns:LockoutStatusType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        This defines the state of user or account lock-out. Lock-out means that the account
	                        was temporarily disabled due to failed login attempts or a similar abuse attempt.
                        </p><p>
	                        This value is usually set by the resource (or midpoint internal authentication code).
	                        It is unlikely that it can be set to the "locked" value. However it usually can be used
	                        to unlock the account by setting this property to "normal" value.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.lockOutStatus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            
            <xsd:element name="lockoutExpirationTimestamp" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Timestamp of a moment when account lockout expires and the account will
                        be normally usable again.
                        
                        This is only an informational value. It should be considered as read-only
                        for most cases. It only makes sense if the lockoutStatus is not in the "normal" state.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ActivationType.lockOutExpiration</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="ActivationStatusType">
        <xsd:annotation>
            <xsd:documentation>
                An enumeration that indicates the activation status of a particular entity.
                The activation status detemines whether the entity is active (enabled)
                or inactive (disabled, archived, etc.). Please see documentation of individual
                enumaration values for more details.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="enabled">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			The entity is active.
                		</p><p>
                			It is enabled and fully operational.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ENABLED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="disabled">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
	                		The entity is inactive.
                		</p><p>
	                		It has beed disabled, haven't reaced the activation period, etc.
	                		This is used to idicate that the entity is TEMPORARILY inactive
	                		and there is an intent to enabled the entity later.
                		</p><p>
	                		Usualy used for an employee on parental leave, sabbatical, temporarily disabled
	                		account for security reasons, etc.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DISABLED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="archived">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
	                		The entitity is inactive.
                		</p><p>
	                		It is no longer active and there are no plans to ever re-activate it.
	                		This is a PERMANENT state of deactivation.
                		</p><p>
	                		This state is used to keep the user record or account around for archival purposes.
	                		E.g. some systems require that the account exists to maintain referential consistency
	                		of historical data, audit records, etc. It may also be used to "blocks" the user or account
	                		identifier to avoid their reuse. 
                		</p><p>
	                		Usualy used for retired employees and similar cases.
                		</p> 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ARCHIVED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="TimeIntervalStatusType">
        <xsd:annotation>
            <xsd:documentation>
                Holds the result of time interval computation with respect to the current
                date and time. E.g. it specifies whether the entity is before the interval,
                in the interval or after the interval.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="before">
                <xsd:annotation>
                	<xsd:documentation>
                		Current time and date is before the interval.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="BEFORE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="in">
                <xsd:annotation>
                	<xsd:documentation>
                		Current time and date is in the interval.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="after">
                <xsd:annotation>
                	<xsd:documentation>
                		Current time and date is after the interval. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AFTER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="LockoutStatusType">
        <xsd:annotation>
            <xsd:documentation>
                This defines the state of account lock-out. Lock-out means that the account
                was temporarily disabled due to failed login attempts or a similar abuse attempt.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="normal">
                <xsd:annotation>
                	<xsd:documentation>
                		Account is in normal (unlocked state). It is usable without limitations.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NORMAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="locked">
                <xsd:annotation>
                	<xsd:documentation>
                		The account has been locked. Log-in to the account is temporarily disabled.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOCKED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ResourceType">
        <xsd:annotation>
            <xsd:documentation>
                Resource represents a system or component external to the IDM
                system which we manage. It is sometimes called _IT resource_,
                _target system_, _source system_, _provisioning target_,
                etc.
                IDM system connects to it to create accounts, assign
                accounts to groups, etc. But it also may be an authoritative source of
                data, system that maintains lookup tables, database that
                contains organizational structure, etc. The {{Resource}} 
                provides a combination of several functions (e.g.
                both provisioning and authoritative data for some attributes).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                	<xsd:element name="operationalState" type="tns:OperationalStateType" minOccurs="0"/>
                    <xsd:element name="connector" type="tns:ConnectorType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                "Composite" version of the ConnectorType reference. See below for more details.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:connectorRef</a:objectReference>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference to the connector that implements specified resource.

                                Connector reference is MANDATORY. Although the
                                schema does not enforce it (due to various JAXB
                                reasons), exactly one of the connecotor or
                                connectorRef MUST be present in the resource object.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ConnectorType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorConfiguration" type="tns:ConnectorConfigurationType"/>
                    <xsd:element name="additionalConnector" type="tns:ConnectorInstanceSpecificationType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Specification of additional connector(s). Additional connectors may add
                                capabilities to this resource, e.g. scripting capability or capapility for
                                reading the exported resource content.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:since>3.6</a:since>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="namespace" type="xsd:anyURI" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Resource private namespace. This is the namespace            
                                that is private for a specific resource INSTANCE.
                                It may be used by the connector e.g. to generate
                                instance-specific resource schema or for other
                                purposes. If not set a default namespace is assumed.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element ref="tns:schema" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Schema for resource objects.

                                This element contains the XSD-formatted definition
                                of resource schema. It defines data types for
                                accounts, groups, roles, entitlements,
                                organizational units or any other objects
                                related to identity management that the resource
                                supports.

                                Resource schema is only available at run-time
                                and can be diffrent for every resource instance,
                                even for resource instances of the same type.
                                It is supposed to be dynamically interpreted in
                                run-time.

                                Schema defines data types (XSD types), but it
                                does NOT define how these types are handled.
                                E.g. it defines attributes and object class for
                                inetOrgPerson, that it has "cn" attribute which
                                is multi-valued string, etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element ref="tns:schemaHandling" minOccurs="0"/>
                    <xsd:element name="capabilities" type="tns:CapabilitiesType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	TODO: update
                            	
                                The capabilities supported by the resource, including both native capabilities of
                                the connector and simulated capabilities.
                                If this element is not present at all, the value of nativeCapabilities element is
                                assumed.
                                The value of this element is not generated, it should be set by the administrator.
                                The value of this element indicates administrator decisions what connector capabilities
                                to use, what capabilities to simulate and how to simulate them.
                                
                                The valus of this element indicates what the connector is allowed to do.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="scripts" type="tns:OperationProvisioningScriptsType" minOccurs="0"/>
                    <xsd:element name="projection" type="tns:ProjectionPolicyType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Resource-wide account synchronization settings.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="consistency" type="tns:ResourceConsistencyType" minOccurs="0"/>
                    <xsd:element name="caching" type="tns:CachingPolicyType" minOccurs="0"/>
                    <xsd:element ref="tns:synchronization" minOccurs="0"/>
                    <xsd:element name="business" type="tns:ResourceBusinessConfigurationType" minOccurs="0"/>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="resource" type="tns:ResourceType" substitutionGroup="c:object"/>
    
    <xsd:complexType name="OperationalStateType">
        <xsd:annotation>
            <xsd:documentation>
                Structure containing metada about operational state of the resource.
                E.g. if resource is up or down, when it was last checked, etc.
                It should not contain configuration, just the operational state.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="lastAvailabilityStatus" type="tns:AvailabilityStatusType" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="AvailabilityStatusType">
        <xsd:annotation>
            <xsd:documentation>
                The enum describes the availability of the resource, if it is down, unreachable or ok. 
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="down">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DOWN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="up">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UP"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="broken">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="BROKEN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ConnectorInstanceSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                Complete specification of a connector instance with configuration and capabilities.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            	<a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="1" />
			<xsd:element name="description" type="xsd:string"
				minOccurs="0" />
			<xsd:element name="connectorRef" type="c:ObjectReferenceType"
				minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Reference to the connector.
					</xsd:documentation>
					<xsd:appinfo>
						<a:objectReferenceTargetType>tns:ConnectorType</a:objectReferenceTargetType>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="connectorConfiguration" type="tns:ConnectorConfigurationType" />
			<xsd:element name="capabilities" type="tns:CapabilitiesType"
				minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Capabilities provided by the connector.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="XmlSchemaType">
        <xsd:annotation>
            <xsd:documentation>
                This element contains the XSD-formatted definition of schema.

                The schema available in this definition is expeceted to comply
                to the usual midPoint schema structure (properties, property
                containers), although it should not contain objects (persistent
                objects identified by OID).
                
                Note: This schema is considered to be available only in run-time.
                Therefore code-generation methods such as JAXB cannot be applied
                here.

                Note: xsd:any is here, but maybe a stricter type would be preferable.
                However xsd:any seems to be a common practice (e.g. SPML, WSDL).
                
                TODO: rename to CachedSchemaType
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element ref="tns:cachingMetadata" minOccurs="0"/>
            <xsd:element name="generationConstraints" type="tns:SchemaGenerationConstraintsType" minOccurs="0"/>
            <xsd:element name="definition" type="t:SchemaDefinitionType" minOccurs="0"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="schema" type="tns:XmlSchemaType"/>
    
    <xsd:complexType name="CachingMetadataType">
        <xsd:annotation>
            <xsd:documentation>
                Metadata that record when a cache copy was retrieved, the identifiers (etags) of that
                copy and possibly also other data. It is used to guide cache coherence policies and
                cache management in general.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="retrievalTimestamp" type="xsd:dateTime" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The timestamp of a time moment when the object was retrieved from the source.
                        Used mostly for diagnostics and general visibility. As this is relativelly rough
                        granularity and the time in distributed system is relative anyway, it is not really
                        useful for anything else.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="serialNumber" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        A string that uniquely represents the version of the data that was retrieved.
                        The objects of the same type and origin with the same serial number are assumed to
                        be the same.
                        There is no requirement for this to be identifier - the serialNumber cannot be used
                        to retrieve the object.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="cachingMetadata" type="tns:CachingMetadataType"/>
    
    <xsd:complexType name="SchemaGenerationConstraintsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="generateObjectClass" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Specification of an object class that has to be automatically generated into a schema.
            			If at least one generateObjectClass specification is present then only the objectclasses
            			specified by the generateObjectClass elements will be generated an no other object class
            			will be passed into the schema.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SchemaHandlingType">
        <xsd:annotation>
            <xsd:documentation>
                Specification of handling details for resource
                schema. E.g. read-only or read-write attributes,
                account object classes, etc.

                This element belongs to ResourceType and should
                not be used elsewhere. This is a top-level
                element to make the implementation
                (JAXB marshall/unmarshall) easier.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
<!--         <xsd:element name="objectClass" type="tns:ResourceObjectTypeDefinitionType" minOccurs="0"
                         maxOccurs="unbounded">
        	<xsd:annotation>
        		<xsd:documentation>
        			The objectClass part of schema handling definition provides a mechanism to redefine schema
        			objectclasses. The objectclasses are tough of as being fairly abstract. This definition
        			may define default values to este for each instance of this object class. It may define
        			default mapping. But these definitions should be directly used in constructions in roles
        			and assignments. The objectType definitions below are supposed to be used for that purpose.
        		</xsd:documentation>
        	</xsd:annotation>
        </xsd:element>  -->
        <xsd:element name="objectType" type="tns:ResourceObjectTypeDefinitionType" minOccurs="0"
                         maxOccurs="unbounded">
        	<xsd:annotation>
        		<xsd:documentation>
        			The objectType part of schema handling definition provides a mechanism to define
        			concrete types of objects that this resource supports. There should be definitions
        			of account types, entitletement types, etc.
        			There are the definitions that should be used in constrcutions in roles, orgs,
        			assignments, etc.
        		</xsd:documentation>
        	</xsd:annotation>
        </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="schemaHandling" type="tns:SchemaHandlingType"/>

    <xsd:complexType name="ResourceObjectTypeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Defines a type from the resource schema (object class)
                that can be used for creating accounts, entitlements and possible other concepts.
                This is abstract supertype for other types. 
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0"/>
        	<xsd:element name="intent" type="xsd:string" minOccurs="0"/>
            <xsd:element ref="tns:displayName" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:description" minOccurs="0"/>
            <xsd:element name="default" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies whether this type is the default type for the resource.
                        Only one type for each class can be default. Setting this flag to true for more than one type is
                        an error. If the flag is not set, the value is inherited from resource schema. If the resource 
                        schema does not have this flag set, the default value is false.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="objectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        XSD type from the resource schema (Object Class) that should be used for accounts
                        on this resource.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="auxiliaryObjectClass" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
               <xsd:annotation>
                   <xsd:documentation>
                       The reference to additional type definitions for this object. The reference should
                       point to object class definition (complex type definition in resource schema) and
                       this definition should be marked as auxiliary.
                   </xsd:documentation>
               </xsd:annotation>
			</xsd:element>
			<xsd:element name="auxiliaryObjectClassMappings" type="tns:ResourceBidirectionalMappingAndDefinitionType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Outbound/inbound mappings for auxiliary object classes. These can be used to manipulate
							auxiliary object classes beyond the simple capabilities provided by the auxiliaryObjectClass
							property.
						</p>
						<p>
							NOTE: outbound mapping for auxiliary object classes is not yet supported.
						</p>
						<p>
							If tolerant flag is set to true then midPoint will tolerate existing auxiliary object classes on resource
							objects. MidPoint will add/remove auxiliary object classes only if there is an explicit
							operation for that (e.g. assign/unassign of role with auxiliary object class definition).
							If tolerant flag set to false then midPoint will strictly synchronize auxiliary object classes of resource
							objects with the definition given in midPoint configuration. This is the default behavior.
						</p>
						<p>
							NOTE: the "tolerant" behavior is disabled by default for auxiliary object classes. This is
							different for most other midPoint definitions where tolerant behavior is enabled by default.
							This inconsistency has historic (compatibility) reasons. But having auxiliary object classes
							non-tolerant also makes a lot of sense in usual situations.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
					</xsd:appinfo>
               </xsd:annotation>
			</xsd:element>
            <xsd:element name="baseContext" type="tns:ResourceObjectReferenceType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        The definition of base context (resource object container). This object will be used
                        as a base for searches for objects of this type. Usually only the objects that are
                        hierarchically below the baseContext are returned by such a search.
                        E.g. this is used to specify LDAP organizationalUnit that contains users or groups
                        of particular type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="attribute" minOccurs="0" maxOccurs="unbounded"
                         type="tns:ResourceAttributeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of handling of an account attribute.
                        This overrides annotations in the resource schema.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="dependency" type="tns:ResourceObjectTypeDependencyType" minOccurs="0" maxOccurs="unbounded"/>
         	<xsd:element name="association" type="tns:ResourceObjectAssociationType" minOccurs="0" maxOccurs="unbounded"/>
         	<xsd:element name="assignmentPolicyEnforcement" type="tns:AssignmentPolicyEnforcementType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Currently not implemented.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="volatility" type="tns:ResourceObjectVolatilityType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies volatility of this type of resource objects, i.e. whether it can change when midPoint
                        is not looking. (Meaning if it is possible that midPoint creates or updates the object, providing
                        some attributes, but after subsequent read, some of the relevant attributes would have values
                        other than provided.) An example of volatile object is Exchange mailbox, where its PrimarySmtpAddress
                        (or EmailAddresses) can be created based on system policies. Therefore, in order to fill-in
                        $user/emailAddress based on PrimarySmtpAddress, one has to fetch a newly created object before
                        applying inbound mappings.

                        Set this property only if you really need to execute inbounds on volatile attributes;
                        otherwise you'll get performance penalty with no benefits in return.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="iteration" type="tns:IterationSpecificationType" minOccurs="0"/>
            <xsd:element name="protected" type="tns:ResourceObjectPatternType" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Specification of a protected account: account that cannot be affected by IDM. It will be
            			ignored by operations, will not appear in lists, etc. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>         	
            <xsd:element name="activation" minOccurs="0" type="tns:ResourceActivationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of activation handling for this account type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="credentials" minOccurs="0" type="tns:ResourceCredentialsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of credentials handling for this account type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="lifecycle" minOccurs="0" type="tns:ResourceObjectLifecycleDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of resource object lifecycle handling. It defines
                        how the initial lifecycle state is determined, constraints for lifecycle
                        transitions, etc.
                    </xsd:documentation>
                    <xsd:appinfo>
		            	<a:since>3.6</a:since>
		            </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="pagedSearches" minOccurs="0" type="xsd:anyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Placeholder for old-style specification of paged searches.
                        Kept here just to avoid parsing errors when reading the configuration.
                        DEPRECATED. The value is ignored.
                        TODO remove before release
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated/>
                        <a:rawType/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="configuredCapabilities" type="c:CapabilityCollectionType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        The configured capabilities of the resource specific to this object type.

                        This part contains "tweaks" of the native capabilities.
                        Some of the native capabilities may be turned off, other capabilities may be simulated.

                        If this element is not present at all then the native+configured capabilities
                        at the resource level are applied.

                        BEWARE: Currently, only pagedSearch and addRemoveAttributeValues capability is expected here.
                        Other capabilities listed in this section are ignored.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>

        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ResourceConsistencyType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of consistency mechanisms. This may include configuration of high-level
                operation retries and similar technical configuration.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="avoidDuplicateValues" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				When set to true, midPoint will try to avoid adding attribute values that are already
        				there and remove values that are not there. Some resources do not tolerate such operations
        				and they respond with errors. However midPoint cannot rely on transactions. MidPoint's
        				lock-free relativistic model provides the necessary consistency, occasional redundant
        				additions or deletions may happen. If this option is turned on then midPoint will read
        				the data from resource right before the operation and filter our any redundant changes.
        				This requires additional operation and it increases the risk of inconsistencies. However
        				it is the only practical option for some resources.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="shadowConstraintsCheck" type="tns:ShadowCheckType" minOccurs="0" default="none">
        		<xsd:annotation>
        			<xsd:documentation>
        				Shadow constraint uniqueness setting. It mostly applies to shadow uniqueness.
        				Uniqueness is checked by the resource under normal circumstances. This option
        				can be used to turn on additional checks. Those checks may be needed to diagnose
        				configuration issues or bugs (e.g. "duplicate shadow" problems). Or it may be
        				used in case that the resource cannot check uniqueness by itself (e.g. in case of
        				manual or asynchronous resources).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="useProposedShadows" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				If set to true then midPoint will try to create shadows in "proposed" lifecycle
        				state even before an operation is executed. The proposed shadows may be used
        				in combination with shadowConstraintsCheck to reduce probability of identifier
        				conflicts for resources with slow create/rename operations.
        				
        				See also avoidDuplicateOperations and recordPendingOperations properties.
        				
        				This feature is EXPERIMENTAL. Use with care.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.6.1</a:since>
        				<a:experimental>true</a:experimental>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="recordPendingOperations" type="tns:RecordPendingOperationsType" minOccurs="0" default="asynchronous">
        		<xsd:annotation>
        			<xsd:documentation>
        				TODO
        				
        				See also avoidDuplicateOperations and useProposedShadows properties.
        				
        				This feature is EXPERIMENTAL. Use with care.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.6.1</a:since>
        				<a:experimental>true</a:experimental>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="avoidDuplicateOperations" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				When set to true, midPoint will try to avoid executing duplication operations
        				on the resource. If an operation is already underway the duplicate operation
        				will be ignored.
        				
        				See also recordPendingOperations and useProposedShadows properties.
        				
        				This feature is EXPERIMENTAL. Use with care.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.6.1</a:since>
        				<a:experimental>true</a:experimental>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="operationGroupingInterval" type="xsd:duration" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				<p>
	        				Turns on operation grouping feature and specifies a grouping interval.
	        				Operation grouping is feature that groups several operations on a resource
	        				into a single operation. This can be used in case midPoint creates a lot of
	        				small operations. But we want to group all of them into a single big operation.
	        				This means that small operations are deplayed for a specified interval. Then
	        				all the operations are grouped into a single operation and executed at once.
	        				This approach slightly delays the operations. But it may be huge advantage for
	        				resources where the operations are constly (manual resources, slow resources).
        				</p> 
        				<p>
        					This parameter specifies a maximum interval between the operation is requested
        					and the operation is started. First operation will be postponed for the specified
        					interval. When the interval is over the operation will be executed. All the
        					operations that have accumulated during the interval will be grouped together
        					and executed.
        				</p>
        				<p>
        					Note: provisioning propagation task must be running to execute the operations.
        				</p>
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.7.1</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="validateSchema" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				If set to true then midPoint will validate the schema of objects that leave
        				and enter midPoint by the connectors. MidPoint will checks if datatypes and
        				multiplicity is correct and issue hard errors in any mismatch.
        				
        				EXPERIMENTAL: this feature is used mostly for internal checks during 
        				development and testing. It is not intended for production use. 
        				Those checks may slow the system down and they may also may impact 
        				robustness. MidPoint is usually able to deal data types that are slightly
        				wrong and auto-correct them. Enabling this feature will cause that an error
        				is thrown even if cases that may get auto-corrected. 
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element name="caseIgnoreAttributeNames" type="xsd:boolean" minOccurs="0" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        If set to true then midPoint will ignore the case of the attribute names.
                        In that case midpoint will normalize any attribute names with regard to the resource schema.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        	<xsd:element name="postpone" type="xsd:boolean" minOccurs="0" default="true">
        		<xsd:annotation>
        			<xsd:documentation>
        				Postpone the operation in case that an error is encountered. The operation
        				will be re-tried later (consistency mechanism).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="discovery" type="xsd:boolean" minOccurs="0" default="true"/>
            <xsd:element name="connectorErrorCriticality" type="tns:ErrorSelectorType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Specifies a method that midPoint will use to evaluate criticality of errors: which errors are
                		considered to be critical (stops the operation) and which error are non-critical (operation continues).
                		By default network errors are not considered critical, other errors are critical.
                		
                		EXPERIMENTAL: use with care.
                		
                		Use of this option may be DANGEROUS. Especially when used to set generic errors as non-critical.
                		Generic errors means that midPoint has absolutely no idea what is going on. Otherwise the
                		error would be classified to a more specific category. Continuing an operation where midPoint
                		has no idea what is going on may have severe consequences. The results are unpredicatble.
                		If you use this setting then you are on your own. Hic sunt liones.
            		</xsd:documentation>
            		<xsd:appinfo>
		            	<a:experimental>true</a:experimental>
		            </xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="pendingOperationGracePeriod" type="xsd:duration" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Duration for which the completed asychronous operations will be kept in the
            			shadow objects. This may be needed to avoid repeating operations in semi-manual
            			resources. But this may also be desirable in other cases if the administrator
            			wants to inspect result of an asynchronous operation.
            			By default there is no grace period and completed operations are immediately
            			deleted.
            		</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" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="ShadowCheckType">
        <xsd:annotation>
            <xsd:documentation>
                Shadow constraint uniqueness setting. It mostly applies to shadow uniqueness.
   				Uniqueness is checked by the resource under normal circumstances. This option
   				can be used to turn on additional checks. Those checks may be needed to diagnose
   				configuration issues or bugs (e.g. "duplicate shadow" problems). Or it may be
   				used in case that the resource cannot check uniqueness by itself (e.g. in case of
   				manual or asynchronous resources).
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                	<xsd:documentation>
                		No additional checks.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="light">
                <xsd:annotation>
                	<xsd:documentation>
                		Light checks only.
                		E.g. the shadow uniqueness will be checked only once
                		when new shadow is created.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LIGHT"/>
                    </xsd:appinfo>
                </xsd:annotation>
                <!-- TODO: thorough: always check uniqueness -->
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="RecordPendingOperationsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.6.1</a:since>
                <a:experimental>true</a:experimental>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="asynchronous">
                <xsd:annotation>
                	<xsd:documentation>
                		Record only asynchronous operations. The operation
                		will be recorded when we know that it is asynchronous.
                		Which usually means it is only recoded after the operation
                		is started.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASYNCHRONOUS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="all">
                <xsd:annotation>
                	<xsd:documentation>
                		Record all operations to pending deltas. The operations
                		are recoreded even before they are started.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="ErrorSelectorType">
        <xsd:annotation>
            <xsd:documentation>
                Selects error categories, e.g. for the purpose of criticality definition, selection
                which error types to handle, etc.
                
                EXPERIMENTAL: use with care
                TODO: change booleans to CriticalityType
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            	<a:experimental>true</a:experimental>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="network" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects network errors (connection refused, timeouts, unreachable network, connection resets, ...)
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="security" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects security issues (failed authentication, permission denied, ...)
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="policy" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects policy violations. The operation failed because it violates
        				defined policies (e.g. exlusion policies), it fails data consistency checks,
        				etc.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="schema" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects schema and data format errors. These are errors that data
        				not complete, they contain unexpected elements, they do not match
        				pre-defined schema, etc.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="configuration" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects configuration errors. These are caused by misconfiguration of
        				midPoint, some of its components, the connector or the resource. This also
        				includes run-time errors that are likely caused by the configuration, such
        				as generic errors in the expressions.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="generic" type="xsd:boolean" minOccurs="0" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				Selects generic, system and other non-specific issues. These errors
        				do not have any substantial definition about their cause. The error
        				may mean anything.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="CriticalityType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies criticality of an operation.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.6.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="fatal">
                <xsd:annotation>
                    <xsd:documentation>
                        Fatal criticality. Error in the operation will cause
                        fatal error. The processing will be interrupted,
                        error will be indicated.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FATAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="partial">
                <xsd:annotation>
                    <xsd:documentation>
                        Partial criticality. The error will be indicated,
                        composite result of the operation will be presented
                        as partial error, but the processing will NOT be interrupted.
                        The operation will try recover and continue.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PARTIAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <!-- TODO: warning? -->
<!--             <xsd:enumeration value="ignore">
                <xsd:annotation>
                    <xsd:documentation>
                        No criticality. The error will be ignored. It will not
                        be indicated in any result. 
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IGNORE"/>
                    </xsd:appinfo>
                </xsd:annotation>  
            </xsd:enumeration> -->
        </xsd:restriction>
    </xsd:simpleType>
        
    <xsd:complexType name="ResourceBusinessConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of resource "business" aspects such as workflow parameters, notifications,
                approvers, owners, etc.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="administrativeState" type="tns:ResourceAdministrativeStateType" minOccurs="0"/>
            <xsd:element name="approverRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the resource approver(s).
                        It may point to user or organization.
                        If more than one approver is specified they are considered equivalent. Any
                        of the specified approvers may approve the request.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="ownerRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the resource owner(s).
                        It may point to user or organization.
                        If more than one owner is specified they are considered equivalent.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="ResourceAdministrativeStateType">
        <xsd:annotation>
            <xsd:documentation>
                The state of the resource how the administrator want it to be. Overrides the real
                availability status.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="enabled">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ENABLED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="disabled">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DISABLED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="ResourceObjectVolatilityType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies volatility of resource objects or their attributes, i.e. whether they can change without
                explicitly requested by midPoint.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The object is behaving very seriously. What you put there, stays there. No unexpected changes.
                        (At least for the attributes you are interested in.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unpredictable">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNPREDICTABLE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The object can change at any time. Currently this means that midPoint reads the current state
                        after any create or modify operation on that object. In the future we will introduce finer
                        scale, e.g. "can change when created", "can change when updated", etc.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="explosive">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXPLOSIVE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The object can change in insane ways as a reaction to changes made by midPoint.
                        E.g. the attribute that was modified by midPoint can be modified in a different way
                        by the resource (this sometimes happen for nested groups). There is no way how to
                        handle such a volatile behavior other than to re-read the account and re-run
                        reconciliation after every change that midPoint does.
                        This really brutal solution. It is quite inefficient. But it may be the only option
                        to reliably manage data in some resources.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="ShadowDiscriminatorType">
    	<xsd:annotation>
    		<xsd:documentation>
    			Shadow discriminator uniquely identifies a projection among other projections linked to the
    			same focus.
    		</xsd:documentation>
    	</xsd:annotation>
    	<xsd:sequence>
			<xsd:element name="resourceRef" type="c:ObjectReferenceType" minOccurs="0">
            	<xsd:annotation>
	                <xsd:documentation>
	                    Reference to a resource that is the target of reference. It may be implicit in some cases.
	                </xsd:documentation>
	                <xsd:appinfo>
	            		<a:objectReferenceTargetType>tns:ResourceType</a:objectReferenceTargetType>
	            	</xsd:appinfo>
	            </xsd:annotation>
	       	</xsd:element>
	       	<xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0" default="account"/>
            <xsd:element name="intent" type="xsd:string" minOccurs="0" default="default">
                <xsd:annotation>
                    <xsd:documentation>
                        Type of projection that is the target of reference. E.g "default", "admin", "testing"
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
    	</xsd:sequence>
    </xsd:complexType>
    
   <xsd:complexType name="ResourceObjectTypeDependencyType">
   		<xsd:complexContent>
   			<xsd:extension base="tns:ShadowDiscriminatorType">
   				<xsd:sequence>
   					<xsd:element name="strictness" type="tns:ResourceObjectTypeDependencyStrictnessType" minOccurs="0"/>
   					<xsd:element name="order" type="xsd:int" minOccurs="0" default="0">
   						<xsd:annotation>
   							<xsd:documentation>
   								Specifies the order in which the dependency is applied. Lower-order dependencies
   								are applied before higher-order dependencies. Dependencies with the same order
   								are applied at the same time. There must be no circular dependency formed from
   								dependencies of the same order.
   							</xsd:documentation>
   						</xsd:annotation>
   					</xsd:element>
   					<xsd:element name="forceLoad" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
   						<xsd:annotation>
   							<xsd:documentation>
   								Specifies if the shadow on which we depends has to be load. By default we do
   								not force to load full dependent shadow.
   							</xsd:documentation>
   						</xsd:annotation>
   					</xsd:element>
   				</xsd:sequence>
   			</xsd:extension>
   		</xsd:complexContent>
   </xsd:complexType>
   
   <xsd:simpleType name="ResourceObjectTypeDependencyStrictnessType">
        <xsd:annotation>
            <xsd:documentation>
                TODO 
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="strict">
                <xsd:annotation>
                	<xsd:documentation>
                		If the object that we depend on is not provisioned then the dependent object will
                		not be provisioned either. Attempt to provision it will end up with an error.
                		If the object that we depend on is being provisioned in the same operation (context) as
                		the dependent object then they will be provisioned in order: independent first, dependent second.
                		Proper inbound-template-outbound sequence of mapping will be executed between the provisionings.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="STRICT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="relaxed">
                <xsd:annotation>
                	<xsd:documentation>
                		If the object that we depend on is being provisioned in the same operation (context) as
                		the dependent object then they will be provisioned in order: independent first, dependent second.
                		Proper inbound-template-outbound sequence of mapping will be executed between the provisionings.
                		But no error is thrown if the dependent object is provisioned without the other object.
                		If both objects are being provisioned in the same operation (context) and provisioning of the
                		object that we depend on fails the provisioning of the dependent object will be skipped.
                		The relaxed strictness guarantees ordering in case that both objects are being provisioned 
                		in the same operation (context) and delaying of the operation on dependent resource in case
                		the operation on independent resource fails.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RELAXED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="lax">
                <xsd:annotation>
                	<xsd:documentation>
                		If the object that we depend on is being provisioned in the same operation (context) as
                		the dependent object then they will be provisioned in order: independent first, dependent second.
                		Proper inbound-template-outbound sequence of mapping will be executed between the provisionings.
                		But NO ERROR is thrown if the dependent object is provisioned without the other object. Not even if
                		they are provisioned in the same operation (context) an the independent object fails.
                		The lax strictness only guarantees ordering in case that both objects are being (successfully) provisioned.
                		It does not guarantee anything else.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LAX"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ItemRefinedDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Description of the common item handling details, such as display name,
                read/write access and value and synchronization expressions.
                These are the parts that are common to both attributes and associations.
                
                This is supposed to be used in schemaHandling part and therefore
                describe the decisions of the system administrator about the
                way how that attribute or association is used in midPoint.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="ref" type="t:ItemPathType">
                <xsd:annotation>
                    <xsd:documentation>
                        Path of the item or association that this
                        definition describes. It must point to property or the
                        attribute in the resource schema that belongs to an
                        object class that is being described here.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element ref="tns:displayName" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="displayOrder" type="xsd:int" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="limitations" type="tns:PropertyLimitationsType" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Limits the usage of the attribute, e.g. whether it may is read-only, read write or entirely ignored.
            			The limitations may apply to several system layers, therefore this element may be repeated several times.
            			But it there may be only one instance for each layer.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="matchingRule" type="xsd:QName" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Specification of a matching rule for an attribute. Matching rule is used to compare values
            			of the attribute. The default rule is a literal comparison which is good for most attribute
            			types and for case-sensitive strings. An alternative matching rule may be specified e.g.
            			for case insensitive strings.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="valueEnumerationRef" type="c:ObjectReferenceType" minOccurs="0">
            	<xsd:annotation>
	                <xsd:documentation>
	                    Reference to an object that directly or indirectly represents possible values for
						this item. We do not define here what exactly the object has to be. It can be a lookup
						table, script that dynamically produces the values or anything similar. 
						The object must produce the values of the correct type for this item otherwise an
						error occurs.
	                </xsd:documentation>
	                <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:LookupTableType</a:objectReferenceTargetType>
            		</xsd:appinfo>
	            </xsd:annotation>
	       	</xsd:element>
            <xsd:element name="tolerant" type="xsd:boolean" minOccurs="0" default="true">
                <xsd:annotation>
                    <xsd:documentation>
                        When set to true, allows attribute/property values that are set outside midPoint (or
                        outside object template mappings).
                        The synchronization will only remove values that are assigned by midPoint (or template mappings),
                        but will tolerate extra native values.
                        When set to false, extra values are not tolerated. When midPoint detects
                        such value (e.g. during reconciliation) it will remove it.

                        Support of non-tolerant items in object templates is currently EXPERIMENTAL.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="tolerantValuePattern" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Pattern (regexp) for attribute/property value. If the value matches the pattern such value is tolerated.
                        It is left in the attribute/property even if it is not derived from any mapping.

                        This element is currently supported only in resource object type definitions.
                        Support in object templates is planned.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="intolerantValuePattern" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Pattern (regexp) for attribute/property value. If the value matches the pattern such value is NOT tolerated.
                        The value must be derived from a mapping or it will be removed.

                        This element is currently supported only in resource object type definitions.
                        Support in object templates is planned.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="emphasized" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Set true for definitions that are more important than others and that should be emphasized
     					during presentation. E.g. the emphasized definitions will always be displayed in the user
     					interfaces (even if they are empty), they will always be included in the dumps, etc.
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:since>3.4</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="ResourceItemDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Description of the common item handling details, such as display name,
                read/write access and value and synchronization expressions.
                These are the parts that are common to both attributes and associations.
                
                This is supposed to be used in schemaHandling part and therefore
                describe the decisions of the system administrator about the
                way how that attribute or association is used in midPoint.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ItemRefinedDefinitionType">
        		<xsd:sequence>
		            <xsd:element name="exclusiveStrong" type="xsd:boolean" minOccurs="0" default="false">
		            	<xsd:annotation>
		            		<xsd:documentation>
		            			When set to false then both strong and normal mapping values are merged to produce
		            			the final set of values.
		            			When set to true only strong values are used if there is at least one strong mapping.
		            			Normal values are used if there is no strong mapping.
		            		</xsd:documentation>
		            	</xsd:annotation>
		            </xsd:element>
                    <xsd:element name="modificationPriority" type="xsd:int" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Modification priority of this item. Items with specified priorities are modified in order that
                                follows these priorities: these with lower numbers are modified first, these with higher numbers
                                next, and items with unspecified priorities are modified last. Each priority level gets its own
                                modify operation (or operations, if required by ICF limitations).
	
                                Currently this field is supported only for attributes, even it is present on associations as well.
	
                                (It is envisioned that 'addingPriority' could be created as well in the future; it would concern
                                creating new objects. In that case, attributes with numerically lowest adding priority would be
                                used to create an object, and other attributes would be set via MODIFY operation, again,
                                according to their priorities.)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="readReplaceMode" type="xsd:boolean" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Modifications to this attribute are executed in REPLACE form only. I.e. if ADD or DELETE VALUE is
                                requested, midPoint will fetch the object state, compute the expected result and write it to the
                                resource object via REPLACE VALUE operation. This works around some weird connector behavior.
	
                                BEWARE: READ+REPLACE is currently supported for attributes only - not for subjectToObject associations.
	
                                EXPERIMENTAL. May change in near future.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="secondaryIdentifier" type="xsd:boolean" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Indicated if the attribute should be considered as secondary identifier. If set to true,
                                this attribue is stored in repository and user for example by synchronization (correlation
                                rule), consistency mechanism, etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="volatilityTrigger" type="xsd:boolean" minOccurs="0" default="false">
                        <xsd:annotation>
                            <xsd:documentation>
                                If set to true it indicates that change of this attribute may cause
                                changes in other attributes. In that case midPoint re-reads the object
                                after the change of this attributes.
                            </xsd:documentation>
                            <xsd:appinfo>
	                            <a:since>3.4</a:since>
	                            <a:since>3.3.1</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="displayNameAttribute" type="xsd:boolean" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Indicated if the content of this attribute should be used as a human-readable name when
                                displaying resource objects of this type.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
	    		
                    <xsd:element name="fetchStrategy" type="tns:AttributeFetchStrategyType" minOccurs="0"/>
                    <xsd:element name="outbound" type="tns:MappingType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Defines how the attribute value is constructed in case of information flow from IDM to the
                                resource, e.g. in case of provisioning.
	
                                In case an expression is used, the expression variables should be as follows:
                                $user - the user to whom the account belongs
                                $account - the account to be changed
	
                                Motivation: This is "value construction" type, it is
                                using similar format that is used eleswhere in the system
                                (e.g. in roles) and therefore a common expression processor can be
                                used to process all of that. E.g. a single processor may take into a
                                consideration both schema handling and dynamic attributes set by roles.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="inbound" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Defines how the attribute values are used (assigned) in case of information flow from resource
                                to IDM, e.g. in case of synchronization, reconciliation or discovery.
	
                                In case a source expression is used, the expression variables should be as follows:
                                $user - the user to whom the account belongs
                                $account - the account that has been changed (after the change)
	
                                Explanation: This is not a "value construction" as it is not constructing a new
                                attribute value. It is rather using attribute value that was set be someone else.
                                A simpler way how to express the assignement is needed here, especially a simple way how
                                to express assignment target. Some rules may use that information and we definitelly need that
                                to
                                generate correct relative change descriptions.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="ResourceAttributeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Description of the attribute handling details, such as display name,
                read/write access and value and synchronization expressions.

                This is supposed to be used in schemaHandling part and therefore
                describe the decisions of the system administrator about the
                way how that attribute is used in midPoint.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ResourceItemDefinitionType">
        		<!-- No extra elements -->
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="resourceAttributeDefinition" type="tns:ResourceAttributeDefinitionType"/>
    
    <xsd:complexType name="PropertyLimitationsType">
    	<xsd:annotation>
    		<xsd:documentation>
    			TODO
    		</xsd:documentation>
    	</xsd:annotation>
    	<xsd:sequence>
    		<xsd:element name="layer" type="tns:LayerType" minOccurs="0" maxOccurs="unbounded">
    			<xsd:annotation>
    				<xsd:documentation>
    					Specification of a layers that this limitation applies to. If not specified then it applies
    					to all layers.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="minOccurs" type="xsd:string" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Override of schema minOccurs specification.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="maxOccurs" type="xsd:string" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Override of schema maxOccurs specification.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
    		<xsd:element ref="tns:ignore" minOccurs="0"/>
    		<xsd:element name="access" type="tns:PropertyAccessType" minOccurs="0"/>
    	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:simpleType name="LayerType">
        <xsd:annotation>
            <xsd:documentation>
                Defines a system layer.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="schema">
                <xsd:annotation>
                	<xsd:documentation>
                		The lowest layer. It means that the schema is taken in almost unmodified form.
                		This efficiently means "bottom of provisioning component" from the architectural perspective.
                		
                		This is the default.
                		
                		Note that this means that the schemaHandling is actually applied on the schema
                		on this layer. The LayerType does not apply to the "pure" schema, therefore this
                		is the lowest practically applicable level.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SCHEMA"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="model">
                <xsd:annotation>
                	<xsd:documentation>
                		Model layer means application of schema constraints inside the IDM model.
                		
                		This efficiently means "bottom of IDM model component" from the architectural perspective.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MODEL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="presentation">
                <xsd:annotation>
                	<xsd:documentation>
                		The presentation layer that is used to display information to the user but it
                		also means presentation of the data outside midpoint. Therefore it applies both to
                		GUI and also the web service interface and also to similar interfaces.
                		
                		This efficiently means "top of IDM model component" or "Model API" from the architectural perspective. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PRESENTATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="PropertyAccessType">
    	<xsd:sequence>
    		<xsd:element name="read" type="xsd:boolean" minOccurs="0"/>
    		<xsd:element name="add" type="xsd:boolean" minOccurs="0"/>
    		<xsd:element name="modify" type="xsd:boolean" minOccurs="0"/>
    		<!-- delete does not make sense here -->
    	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:simpleType name="AttributeFetchStrategyType">
        <xsd:annotation>
            <xsd:documentation>
                The way how an attribute is fetched from the resource. Or more exactly a way how midPoint requests the
                attribute from the connector.
                
                This setting is used if no other (more specific) setting is specified for an attribute in the run-time.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="implicit">
                <xsd:annotation>
                	<xsd:documentation>
                		MidPoint expects that the attribute will be implicitly returned by the connector
                		in each fetch request and there is no need to explicitly request the attribute.
                		
                		This is the default. This strategy will be used if no other strategy is specified.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IMPLICIT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="explicit">
                <xsd:annotation>
                	<xsd:documentation>
                		MidPoint expects that the attribute will NOT be implicitly returned by the connector.
                		To fetch the attribute midPoint has to explicitly request it. Therefore midPoint will
                		explicitly request this attribute in each fetch request.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXPLICIT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="minimal">
                <xsd:annotation>
                	<xsd:documentation>
                		Fetch the attribute only if absolutely necessary.
                		MidPoint expects that the attribute might be implicitly returned by the connector.
                		Therefore it will try to avoid fetching this value (if possible).
                		This option can be used for values that cause performance overhead (e.g. list of members
                		of large groups).
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MINIMAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="PasswordCompareStrategyType">
        <xsd:annotation>
            <xsd:documentation>
                The way how an resource password is compared with the current password.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.7.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="auto">
                <xsd:annotation>
                	<xsd:documentation>
                		Auto-detect comparison method. If no way of comparison
                		is possible then an error is indicated.
                		Note: Currently this strategy will end with an error if there
                		is no cached password value.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AUTO"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="error">
                <xsd:annotation>
                	<xsd:documentation>
                		There is no way to compare password. Any operation to that
                		tries to compare the password on the resource should end
                		up with an error.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="cached">
                <xsd:annotation>
                	<xsd:documentation>
                		Compare password with the value cached in the shadow.
                		This setting assumes that passwords for all accounts are
                		properly cached. Therefore if there is no password value
                		in the shadow then we assume that there is no resource password.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CACHED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <!-- TODO: ignore, read (compare password by readin password value), resourceAuthenticate, ... -->
        </xsd:restriction>
    </xsd:simpleType>


    <xsd:complexType name="ResourceCredentialsDefinitionType">
        <xsd:sequence>
            <xsd:element name="password" type="tns:ResourcePasswordDefinitionType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines how the password synchronization is handled for the resource.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ResourcePasswordDefinitionType">
    	<xsd:annotation>
    		<xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
    	</xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="fetchStrategy" type="tns:AttributeFetchStrategyType" minOccurs="0"/>
        	<xsd:element name="compareStrategy" type="tns:PasswordCompareStrategyType" minOccurs="0" default="auto">
        		<xsd:annotation>
        			<xsd:documentation>
        				The way how an resource password is compared with the current password.
        				This strategy is used when midPoint needs to compare candidate password
        				with existing resource passowrd. E.g. used in password policies that state
        				that passwords on several resources cannot be the same.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.7.1</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element name="outbound" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines how the password value is constructed in case of information flow from IDM to the
                        resource, e.g. in case of provisioning.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="inbound" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Defines how user password is constructed if he user is created or updated from this account.
            			The "target" part of the assignment is implictly set to user's password, therefore it may be
            			omitted.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="passwordPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the account type password policy settings.
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:ValuePolicyType</a:objectReferenceTargetType>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="caching" type="tns:CachingPolicyType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        Password caching policy.
                        Currently, password storage format (encrypted, hashed) will be the same
                        as the global password storage format used for the entire system.
                        Definition of a specific password storage format might be added later.
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:since>3.7.1</a:since>
            		</xsd:appinfo>
                </xsd:annotation>
                <!-- 
                	TODO: later, create PasswordCachingPolicyType as subtype of CachingPolicyType.
                	PasswordCachingPolicyType could specify password storage format.
                 -->
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ResourceActivationDefinitionType">
    	<xsd:annotation>
            <xsd:documentation>
                Defines how the mapping of the activation section is handled for the resource.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="existence" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Mapping for resource object existence. This mapping decides whether the resource object
		                should exist at all.
		            </xsd:documentation>
		        </xsd:annotation>                
            </xsd:element>
        	<xsd:element name="administrativeStatus" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Mapping for activation administrative status.
		            </xsd:documentation>
		        </xsd:annotation>
            </xsd:element>
        	<xsd:element name="validFrom" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Mapping for activation start of validity.
		            </xsd:documentation>
		        </xsd:annotation>                
            </xsd:element>
        	<xsd:element name="validTo" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Mapping for activation end of validity.
		            </xsd:documentation>
		        </xsd:annotation>                
            </xsd:element>
            <xsd:element name="lockoutStatus" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Mapping for activation lockout status.
		            </xsd:documentation>
		        </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ResourceObjectLifecycleDefinitionType">
    	<xsd:annotation>
            <xsd:documentation>
                Definition of resource object lifecycle handling. It defines
                how the initial lifecycle state is determined, constraints for lifecycle
                transitions, etc.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.6</a:since>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="lifecycleState" type="tns:ResourceBidirectionalMappingType" minOccurs="0" maxOccurs="1">
		    	<xsd:annotation>
		            <xsd:documentation>
		                Lifecycle state mapping. This mapping influences how shadow lifecycle state and focus
		                lifecycle state are mapped.
		                Default outbound lifecycleState mapping is somehow smart algorithm that will consider
		                presence of the focus password, resource password capability, operation and so on.
		                It is defined to work well with hashed passwords.
		                Default inbound lifecycle mapping is empty: no mapping at all. In midPoint 3.6 the inbound
		                lifecycle mapping is not implemented.
		            </xsd:documentation>
		        </xsd:annotation>                
            </xsd:element>
        	<!-- TODO: validation for each individual lifecycle state. 
        	           References to forms for each state. The forms may be used both for validation and
        	           for entering the missing properties.
        	           We need to align this with similar method to control lifecycle transitions 
        	           for all other objects -->
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ResourceBidirectionalMappingType">
    	<xsd:annotation>
    		<xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
    	</xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="fetchStrategy" type="tns:AttributeFetchStrategyType" minOccurs="0"/>
            <xsd:element name="outbound" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Maps information outbound from midpoint to the resource.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="inbound" type="tns:MappingType" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Maps information inbound to midpoint from the resource.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ResourceBidirectionalMappingAndDefinitionType">
    	<xsd:annotation>
    		<xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
    	</xsd:annotation>
	    <xsd:complexContent>
	    	<xsd:extension base="tns:ResourceBidirectionalMappingType">
	    		<xsd:sequence>
		    		<xsd:element name="tolerant" type="xsd:boolean" minOccurs="0">
			    		<xsd:annotation>
		                    <xsd:documentation>
		                        When set to true, allows attribute/property values that are set outside midPoint (or
		                        outside object template mappings).
		                        The synchronization will only remove values that are assigned by midPoint (or template mappings),
		                        but will tolerate extra native values.
		                        When set to false, extra values are not tolerated. When midPoint detects
		                        such value (e.g. during reconciliation) it will remove it.
		                    </xsd:documentation>
		                </xsd:annotation>
			            </xsd:element>
            	</xsd:sequence>
	    	</xsd:extension>
	    </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="IterationSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of iteration properties for a resource account or other resource objects.
                Iteration is a process of choosing unique (or otherwise acceptable) values. E.g. it
                is ususally used to generate unique usernames.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="maxIterations" type="xsd:int">
        		<xsd:annotation>
        			<xsd:documentation>
        				Maximum number of itteration attempts. The number specifies attempts
        				beyound the first one, which is not considered to be an iteration.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="tokenExpression" type="tns:ExpressionType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				An expression that will be used to format an iteration token.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="preIterationCondition" type="tns:ExpressionType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				A condition that will be executed prior to iteration. If it returns true
        				then the iteration will continue. If it returns false then the iteration
        				will be skipped (as if there is an conflict).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="postIterationCondition" type="tns:ExpressionType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				A condition that will be executed after the iteration. If it returns true
        				then the iteration will be accepted as valid. If it returns false then 
        				the iteration will be skipped (as if there is an conflict).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
     	</xsd:sequence>
     </xsd:complexType>
     
     <xsd:complexType name="ResourceObjectPatternType">
     	<xsd:annotation>
     		<xsd:documentation>
     			Resource object pattern. This data structure defines a pattern that is used to match resource
     			objects using a native identifier(s). This may be primary or secondary identifier.
     		</xsd:documentation>
     	</xsd:annotation>
     	<xsd:sequence>
     		<xsd:element name="filter" type="q:SearchFilterType" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
     					The filter used to match the object. If the object mathces then it is regarded to be
     					protected.
     					
     					Although this is minOccurs=0 it is a mandatory attribute for all current practical uses.
     					The minOccurs=0 is here only for compatibility and it will be changed to minOccurs=1
     					when the deprecated syntax is removed.
     				</xsd:documentation>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element ref="icfs:name" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
     					ICF name of the protected object. If the object matches this value then it is considered protected.
     					DEPRECATED. Use filter instead.
     				</xsd:documentation>
     				<xsd:appinfo>
     					<a:deprecated/>
     				</xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element ref="icfs:uid" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
     					ICF UID of the protected object. If the object matches this value then it is considered protected.
     					DEPRECATED. Use filter instead.
     				</xsd:documentation>
     				<xsd:appinfo>
     					<a:deprecated/>
     				</xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     	</xsd:sequence>
     </xsd:complexType>
     
     <xsd:complexType name="ResourceObjectReferenceType">
     	<xsd:annotation>
     		<xsd:documentation>
     			Reference to a resource object. This reference has many properties that influence when and how
     			to look for the object. We assume that the search for resource objects is quite expensive, therefore
     			we will need to optimize the number of searches. We also want this reference to be "sticky", e.g. to
     			survive resource object renames.
     		</xsd:documentation>
     		<xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
     	</xsd:annotation>
     	<xsd:sequence>
     		<xsd:element name="objectClass" type="xsd:QName" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
		     			Specifies the object class of the referenced object.
		     			This clause for objectClass may be omitted if it can be determined by other means.     				
     				</xsd:documentation>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="filter" type="q:SearchFilterType" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
     					The filter used to look for the object. This filter does NOT need to contain
     					clauses for resource. This will be automatically added by midpoint.
     				</xsd:documentation>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="shadowRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
	                <xsd:documentation>
	                    Reference to shadow that represents the resource object. If present, then it will be
	                    used directly. If not present then the search filter will be used to locate the shadow
	                    and the the result will be set to this reference.
	                </xsd:documentation>
	                <xsd:appinfo>
	        			<a:objectReferenceTargetType>tns:ShadowType</a:objectReferenceTargetType>
	        		</xsd:appinfo>
	            </xsd:annotation>
        	</xsd:element>
     		<xsd:element name="resolutionStrategy" type="tns:ResourceObjectReferenceResolutionStrategyType" minOccurs="0" maxOccurs="1" default="repository">
     		</xsd:element>
     		<xsd:element name="resolutionFrequency" type="tns:ResourceObjectReferenceResolutionFrequencyType" minOccurs="0" maxOccurs="1" default="once">
     		</xsd:element>
     	</xsd:sequence>
     </xsd:complexType>
     
     <xsd:simpleType name="ResourceObjectReferenceResolutionStrategyType">
        <xsd:annotation>
            <xsd:documentation>
                The strategy used to resolve resource object references.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="repository">
                <xsd:annotation>
                	<xsd:documentation>
                		Search only in midPoint identity repository. Do not look at the resource. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPOSITORY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="resource">
                <xsd:annotation>
                	<xsd:documentation>
                		Look only at the resource. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESOURCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="repositoryThenResource">
                <xsd:annotation>
                	<xsd:documentation>
                		Search in midPoint identity repository first. If the shadow is found, use it.
                		If the shadow is not found also search on the resource.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPOSITORY_THEN_RESOURCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

     <xsd:simpleType name="ResourceObjectReferenceResolutionFrequencyType">
        <xsd:annotation>
            <xsd:documentation>
                The strategy used to resolve resource object references.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="never">
                <xsd:annotation>
                	<xsd:documentation>
                		Never resolve reference. If it has shadowRef then use it. If it does not then throw an error.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NEVER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="once">
                <xsd:annotation>
                	<xsd:documentation>
                		Resolve reference once. Then store the OID. Use the OID in subsequent cases. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ONCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="always">
                <xsd:annotation>
                	<xsd:documentation>
                		Always reselve the reference. Do not store the OID. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALWAYS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
     
     <xsd:complexType name="ResourceObjectAssociationType">
     	<xsd:annotation>
     		<xsd:documentation>
     			Describes how entitlement is associated to the subject (e.g. account or other entitlement).
     			
     			Description of the entitlement handling details, such as display name,
                read/write access and so on.

                This is supposed to be used in schemaHandling part and in assignments/inducements
                and therefore it describes the decisions of the system administrator about the
                way how entitlements are used in midPoint.
     		</xsd:documentation>
     		<xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
     	</xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ResourceItemDefinitionType">
		     	<xsd:sequence>
		     		<xsd:element name="auxiliaryObjectClass" type="xsd:QName" minOccurs="0" maxOccurs="1">
		               <xsd:annotation>
		                   <xsd:documentation>
		                       This association is considered valid only if the resource object (subject)
		                       has the specified auxiliary object class.
		                   </xsd:documentation>
		               </xsd:annotation>
		           </xsd:element>
		     		<xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0"></xsd:element>
		     		<xsd:element name="intent" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                A set of intents corresponding to this association type.
                                NOTE: All of them must point to the same resource ObjectClass!

                                The association may point to many intents (many object types with different intents).
                                This is sometimes useful, especially if there are many types of groups and each type
                                is constructed in a slightly different way. The multi-intent associations are
                                supported and often very useful. But there is an important hard limitation: all
                                the object types referenced from a single association must have the same object
                                type, attributes, matching rules, .... they must be equivalent in every aspect
                                except for attribute mappings.
                            </xsd:documentation>
                        </xsd:annotation>
		     		</xsd:element>
		     		<xsd:element name="direction" type="tns:ResourceObjectAssociationDirectionType"  minOccurs="0">
		     			<xsd:annotation>
		     				<xsd:documentation>
		     					Specifies the direction of association, i.e. if the association point from object to
		     					subject or the other way around. 
		     				</xsd:documentation>
		     			</xsd:annotation>
		     		</xsd:element>
		     		<xsd:element name="associationAttribute" type="xsd:QName"  minOccurs="0">
		     			<xsd:annotation>
		     				<xsd:documentation>
		     					Name of the attribute which represents the association. This is the attribute
		     					that will be modifier when the association changes. In object-to-subject associations
		     					this is the attribute of the object (e.g. group). In subject-to-object associations this
		     					is an attribute of the subject (e.g. account).
		     					
		     					Typical examples are: roles, privileges, member, uniqueMember 
		     				</xsd:documentation>
		     			</xsd:annotation>
		     		</xsd:element>
		     		<xsd:element name="valueAttribute" type="xsd:QName"  minOccurs="0">
  		     			<xsd:annotation>
		     				<xsd:documentation>
		     					Name of the attribute from with a value for association attribute is taken. 
		     					The value is taken from this attribute and it will be stored in the association attribute.
		     					This 
		     					attribute will NOT be modifier when the association changes, it is only for reading.
		     					In object-to-subject associations this is the attribute of the subject (e.g. account).
		     					In subject-to-object associations this is an attribute of the object (e.g. group).
		     					
		     					This attribute usually contain identifiers.
		     					Typical examples are: name, username, uid, id 
		     				</xsd:documentation>
		     			</xsd:annotation>	     		
		     		</xsd:element>
		     		<xsd:element name="shortcutAssociationAttribute" type="xsd:QName"  minOccurs="0">
		     			<xsd:annotation>
		     				<xsd:documentation>
		     					Association attribute short-cut. There are cases when a object-to-subject association
		     					is the authoritative one, but reading object-to-subject is expensive. E.g. several searches
		     					must be done to fully resolve object-to-subject associations. This attribute provides a
		     					short-cut mechanism. It is used in cases when there is additional (virtual) attribute that
		     					goes in the opposite direction as the primary object-to-subject association attribute.
		     					The association short-cut is only usable for object-to-subject associations.
		     					
		     					This property specifies name of the attribute which represents the association short-cut.
		     					This is the attribute of the subject (e.g. account). This attribute will only be read,
		     					it is never written. The primary association attribute is used for writing.
		     					
		     					Typical examples are: memberOf, isMemberOf 
		     				</xsd:documentation>
		     			</xsd:annotation>
		     		</xsd:element>
		     		<xsd:element name="shortcutValueAttribute" type="xsd:QName"  minOccurs="0">
		     			<xsd:annotation>
		     				<xsd:documentation>
		     					Association attribute short-cut. There are cases when a object-to-subject association
		     					is the authoritative one, but reading object-to-subject is expensive. E.g. several searches
		     					must be done to fully resolve object-to-subject associations. This attribute provides a
		     					short-cut mechanism. It is used in cases when there is additional (virtual) attribute that
		     					goes in the opposite direction as the primary object-to-subject association attribute.
		     					The assocition short-cut is only usable for object-to-subject associations.
		     					
		     					This property specifies name of the attribute from with a value for association attribute
		     					short-cut is taken. The values of this attribute are expected to appear in association
		     					short-cut attribute. This is an attribute of the object (e.g. group).
		     					
		     					This attribute usually contain identifiers.
		     					Typical examples are: name, username, uid, id 
		     				</xsd:documentation>
		     			</xsd:annotation>
		     		</xsd:element>
		     		<xsd:element name="explicitReferentialIntegrity" type="xsd:boolean"  minOccurs="0" default="true">
                        <xsd:annotation>
                            <xsd:documentation>
                                Whether you require midPoint to provide referential integrity for object-to-subject associations.

                                Used for resources that do not provide referential integrity by themselves, e.g. for OpenDJ with
                                default settings (i.e. with referential integrity plugin turned off).

                                For resources having referential integrity, e.g. for Active Directory, set this parameter to false.
                            </xsd:documentation>
                        </xsd:annotation>
		     		</xsd:element>
		     	</xsd:sequence>
		     </xsd:extension>
	     </xsd:complexContent>
     </xsd:complexType>

     <xsd:simpleType name="ResourceObjectAssociationDirectionType">
        <xsd:annotation>
            <xsd:documentation>
                Direction of a resource object association.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="objectToSubject">
                <xsd:annotation>
                	<xsd:documentation>
                		The object has an attribute that contains subject identifiers as its values. E.g. a group has a list of members.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OBJECT_TO_SUBJECT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="subjectToObject">
                <xsd:annotation>
                	<xsd:documentation>
                		Subject has an attribute that contains object identifiers as its values. E.g. an account has a list of groups to which it belongs.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SUBJECT_TO_OBJECT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="CapabilitiesType">
        <xsd:annotation>
            <xsd:documentation>
                Collection of resource capabilities. Each element in this collection defines a specific resource
                capability. Stardard midpoint capabilities are defined in a separate namespace. But that is not
                a closed set. Resource may also specify additional capabilities. If the code that is processing
                capabilities encounters unknown capability it must ignore it.
                
                Each capability should have boolean propery "enabled" with true default value. This is used in
                the configured capabilities section to disable individual capabilities.
                
                This part defines native and configured capabilities. The effective capabilities of the resource
                are determined by application of configured capabilities to native capabilities.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:cachingMetadata" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				Metadata defining the "freshness" of the cached copy of native capabilities.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element name="native" type="c:CapabilityCollectionType" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			The capabilities natively supported by the connector without any simulation or any
                        other workaround. It is stored in the repository as a cache of the real capabilities
                        (connector can always produce the capabilities if the resource is online).
                        If this element is not present then the data were not yet retrieved from the resource.
                        If it is present, but the inner capability list is empty then the connector provides
                        no capabilities.
                        
                        The value of this element indicates what the connector can do.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="configured" type="c:CapabilityCollectionType" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			The configured capabilities of the resource. This part contains "tweaks" of the native capabilities.
            			Some of the native capabilities may be turned off, other capabilities may be simulated. 
            			
                        If this element is not present at all then the native capabilities in the unchanged form are assumed.
                        
                        The value of this element is not generated, it should be set by the administrator.
                        The value of this element indicates administrator decisions what connector capabilities
                        to use, what capabilities to simulate and how to simulate them.
                        
                        The value of this element indicates what the connector is allowed to do.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="capabilities" type="tns:CapabilitiesType"/>
    
    <xsd:complexType name="CapabilityCollectionType">
        <xsd:annotation>
            <xsd:documentation>
                Collection of resource capabilities. Each element in this collection defines a specific resource
                capability. Standard midpoint capabilities are defined in a separate namespace. But that is not
                a closed set. Resource may also specify additional capabilities. If the code that is processing
                capabilities encounters unknown capability it must ignore it.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
				<a:defaultNamespace>http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3</a:defaultNamespace>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
<!--          <xsd:element name="cap" type="cap:CapabilityType" minOccurs="0" maxOccurs="unbounded"> -->
<!--                 <xsd:annotation> -->
<!--                     <xsd:documentation> -->
<!--                         Elements defining individual capabilities. -->
<!--                     </xsd:documentation> -->
<!--                 </xsd:annotation> -->
<!--             </xsd:element> -->
            <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax">
                <xsd:annotation>
                    <xsd:documentation>
                        Elements defining individual capabilities.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:any>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="OperationProvisioningScriptsType">
        <xsd:annotation>
            <xsd:documentation>
                Collection of scripts to be executed for various provisioning operations.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="script" type="tns:OperationProvisioningScriptType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Specific script definition.
                        Note: More than one script definition may apply to a specific operation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="provisioningScripts" type="tns:OperationProvisioningScriptsType"/>

    <xsd:complexType name="OperationProvisioningScriptType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies how and when a script is executed during provisioning.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ProvisioningScriptType">
        	        <xsd:sequence>
			            <xsd:element name="operation" type="tns:ProvisioningOperationTypeType" minOccurs="0" maxOccurs="unbounded">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Defines a set of operations for which the script should be executed.
			                        If more than one operation is specified, the same
			                        script should be executed for each of them.
			                        If no operation is specified, the script will not be
			                        executed (this is meant as poor man's disable feature)
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:element>
			            <xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0" maxOccurs="unbounded">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Constraints script execution only to resource objects of a specified kind.
			                        If not present then the scrip will be executed for objects of all kinds.
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:element>
			            <xsd:element name="intent" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Constraints script execution only to resource objects with a specified intent.
			                        If not present then the scrip will be executed for objects with any intent.
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:element>
			            <xsd:element name="order" type="tns:BeforeAfterType">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Defines the order in which a script is executed.
			                        (before or after an operation).
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:element>
			             <xsd:element name="condition" type="tns:ExpressionType" minOccurs="0" maxOccurs="1">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Defines the condition when to execute script.
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:element>
			        </xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ProvisioningScriptType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies a script to be executed during provisioning.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="host" type="tns:ProvisioningScriptHostType" minOccurs="0" default="resource">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines where the script should be executed
                        (connector or resource). If no type is specified, it
                        defaults to resource.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="language" type="xsd:anyURI">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies the language of the script.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="argument" type="tns:ProvisioningScriptArgumentType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Script arguments. The arguments will passed to the script
                        in any way suitable for the script. The argument name
                        is "local" to the script (script-specific). Script name
                        must be unique in the argument set.
                        The order of arguments is not significant.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="code" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Script code represented as string. The interpretation
                        depends on script language. If XML elements are used
                        inside, they should be properly escaped. (e.g. using
                        CDATA).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="criticality" type="tns:CriticalityType" minOccurs="0" default="fatal">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines where the script should be executed
                        (connector or resource). If no type is specified, it
                        defaults to resource.
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:since>3.6.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="ProvisioningOperationTypeType">
        <xsd:annotation>
            <xsd:documentation>
                Type of an operation (change). It defines operations to change
                object, it is not limited to object modifications.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="get">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="GET"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="add">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ADD"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="modify">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MODIFY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="delete">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DELETE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="reconcile">
                <xsd:annotation>
                	<xsd:documentation>
                		Not stritcly a provisioning operation. But we understand it
                		in a broader sense of "comparing states".
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RECONCILE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="ProvisioningScriptHostType">
        <xsd:annotation>
            <xsd:documentation>
                An enumeration that defines where the script will be executed.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="connector">
                <xsd:annotation>
                    <xsd:documentation>
                        The script will be executed on "connector", it means
                        it will be executed on the same host as the connector
                        is running (which is usually IDM system).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CONNECTOR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="resource">
                <xsd:annotation>
                    <xsd:documentation>
                        The script will be executed on "resource", it means
                        it will be executed on the target sytem. Please refer
                        to the
                        connector documentation for more details, e.g.
                        in case of multi-host resources.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESOURCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ProvisioningScriptArgumentType">
        <xsd:annotation>
            <xsd:documentation>
                Script argument. It is subtype of Value Construction, therefore
                the value may be static of dynamically constructed using an
                expression. The "default" and "authoritative" flags are not
                applicable here.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ExpressionType">
                <xsd:sequence>
                    <xsd:element name="name" type="xsd:string">
                        <xsd:annotation>
                            <xsd:documentation>
                                Argument name. The name is "local" to the
                                script. It must comply with the limitations of
                                used script language.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
	
	<xsd:complexType name="CommandLineScriptType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies a command to be executen on an operating system command-line.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence> 
            <xsd:element name="macro" type="tns:ProvisioningScriptArgumentType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Command-line macro. Any occurence of the macro will be replaced in the command-line code.
                        The order of arguments is not significant.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO: later
            <xsd:element name="argument" type="tns:ProvisioningScriptArgumentType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Script arguments. The arguments will passed to the script
                        in any way suitable for the script. The argument name
                        is "local" to the script (script-specific). Argument name
                        must be unique in the argument set.
                        The order of arguments is not significant.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="environment" type="tns:ProvisioningScriptArgumentType" minOccurs="0" maxOccurs="unbounded">
            </xsd:element>
             -->
            <xsd:element name="executionMethod" type="tns:CommandLineExecutionMethod">
            </xsd:element>
            <xsd:element name="code" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Represents command with arguments. Sequences starting with percent sign (%) will be
                        replaced by the value of midPoint arguments to the command line script.
                        E.g. for the code bash -c "echo %source ; echo %name" the %source and %name strings will be
                        replaced by the value of midPoint arguments "source" for the path to the newly created report and "name" for the name
						of the same report file. 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:simpleType name="CommandLineExecutionMethod">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="exec">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Plain exececution using OS services (exec).
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXEC"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="shell">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
	                		Execution using UNIX-like shell (e.g. bash)
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SHELL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ConnectorConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Resource configuration (hostname, port, ...).
                Specific for each resource type.
                TODO

                This element belongs to ResourceType and should
                not be used elsewhere. This is a top-level
                element to make the implementation (JAXB
                marshall/unmarshall) easier.
            </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:complexType>


	<xsd:complexType name="MappingType">
        <xsd:annotation>
            <xsd:documentation>
                Defines how a value of a property (or attribute) should be
                constructed. The value may be static or constructed as an
                result of evaluating an expression.

                This structure also defines a method how to merge several value
                construction definitions, how to behave if a property already
                has a value, etc.

                This is reusable data structure, used in schemaHandling, roles
                and it may also be used in may other places.

                Motivation: We need to construct attribute or property values on
                many places in midPoint. E.g. we need that in roles to generate
                dynamic account attribute values, we need that to define "templates"
                for identifiers and default values for attributes when creating a
                new account. We also need that to specify values when creating a
                new user (user templates). Having the same data structure for all of
                these cases may simplify the code, as it all can be handled by a
                generic library reused in many places through the system.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Short name of the mapping. Used for debugging purposes.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:extension" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="trace" type="xsd:boolean" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			Explicitly trace the execution of this mapping. The execution will be
            			logged on INFO level if this property is set to true to make sure that it
            			will be visible in the logs. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="authoritative" minOccurs="0" type="xsd:boolean" default="true">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                           Authoritative flag controls the way how mapping is used to
                           remove values. It does not influence adding of values. If mapping is
                           authoritative then it will add value and also remove the value. If mapping
                           is not authoritative it will only add the value.
                        </p>

						<p>
						   Non-authoritative mappings are used if there are several possible sources
						   for a particular value. E.g. the value may be added by the mapping and
						   also added directly on the resource by system administrator. In this case
						   midPoint cannot remove the value when the assignment (or role) containing
						   the mapping is removed because the value might have been added manually.
						   Other settings, such as tolerance may apply on attribute level.
						</p>

						<p>
							The default value for authoritative flag is true.
						</p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="exclusive" minOccurs="0" type="xsd:boolean" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                        	Exclusive mapping may be applied only as a single mapping for a
                        	particular target property. If an exclusive mapping is applied
                        	together with any other mapping it results in an error.
                        </p>
                        <p>
							The default value for exclusive flag is false.
                        </p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="tolerant" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
	                        When set to true, allows attribute/property values that are set outside
	                        of this mapping. I. e. it allows other values than those set by this mapping.
                        </p>
                        <p>
	                        The default value for tolerant setting depends on when the mapping is used.
	                        It is assumed to be false for all mappings. However, for outbound mappings
	                        the real behavior of reconciliation is determined by the tolerance of the
	                        attribute and not tolerance of the mapping (see below).
	                        This default setting was chosen to maintain behaviour
	                        which is compatible with previous midPoint versions.
                        </p>
                        <p>
                        	Note: Mapping tolerance is an interim feature. In fact it is mostly
                        	redundant. The same behavior can be achieved by using mapping
                        	range. However, mapping range is not fully supported in all mappings
                        	and all situations. Therefore mapping tolerance can be used in the
                        	meantime to achieve the desired functionality. However, mapping
                        	tolerance will get deprecated in the midPoint version in which
                        	mapping range achieve full functionality. Therefore it is recommended
                        	to use mapping tolerance only as a last resort. It is recommended
                        	to use mapping range instead of tolerance if the range can be used.
                        </p>
                        <p>
							Note: Do not confuse with tolerant setting that applies to the
							resource attribute (schemaHandling). If in doubt, use that other
							setting instead. That resource attribute tolerance is usually the
							right answer.
						</p>
						<p>
                        	Support for this setting is currently EXPERIMENTAL.
                       	</p>
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:since>3.4</a:since>
                    </xsd:appinfo>                    
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="strength" minOccurs="0" type="tns:MappingStrengthType" default="normal">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                        	Strength of the mapping defines how aggressively will the mapping be applied.
                        	The strongest mappings are applied all the time (regardless of the consequences)
                        	and the weakest mappings are applied only if nothing else can be applied.
                        </p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="channel" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Limits application of this mapping only to specific channel. If the channel is listed then the
            			mapping will be applied. If it is not then it will not be applied.
            			If no channel is specified then no limitations apply and the mapping will be applied for all channels.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="exceptChannel" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			Limits application of this mapping except for channel specified. If the channel is listed then the
            			mapping will be not applied in this channel. If it is not then it will be applied.
            			If no channel is specified then no limitations apply and the mapping will be applied for all channels.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="timeFrom" type="tns:MappingTimeDeclarationType" minOccurs="0"/>
            <xsd:element name="timeTo" type="tns:MappingTimeDeclarationType" minOccurs="0"/>
            <xsd:element name="source" type="tns:VariableBindingDefinitionType" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="expression" type="tns:ExpressionType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="target" type="tns:VariableBindingDefinitionType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="condition" type="tns:ExpressionType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="inputFilter" type="tns:ValueFilterType" minOccurs="0"/>
            <xsd:element name="outputFilter" type="tns:ValueFilterType" minOccurs="0"/>
            <xsd:element name="range" minOccurs="0" type="tns:ValueSetSpecificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                        	Specifies the range of the mapping (in mathematical sense). I.e. this specifies the values
                        	that the mapping can produce. Range specification makes sense only for authoritative mappings.
                        	If the range is specified then the mapping will scan existing values of the target property.
                        	It will look for values that are there and that are also in the range of the mapping. If such
                        	values are not in the expression results, then such values will be removed (placed in the minus set).
                        </p>
                        <p>
                        	DEPRECATED. Do not use. Use the set definition in mapping target instead.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:deprecated>true</a:deprecated>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="mapping" type="tns:MappingType"/>
    
    <xsd:simpleType name="MappingStrengthType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                	Strength of the mapping defines how aggressively will
                	the mapping be applied. The strongest mappings are
                	applied all the time (regardless of the consequences)
                	and the weakest mappings are applied only if nothing
                	else can be applied.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="strong">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Always applied, regardless of context. Strong mappings enforce particular values.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="STRONG"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="normal">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Apply the mapping unless there is a more specific change.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NORMAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="weak">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Apply the mapping only if there is a no other change on target property
                			and the target property does not have any value. This mapping strength
                			is use to set initial (default) values for attributes and properties.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WEAK"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="MappingTimeDeclarationType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="referenceTime" type="tns:VariableBindingDefinitionType" minOccurs="0" maxOccurs="1"/>
           	<xsd:element name="offset" type="xsd:duration" minOccurs="0"/>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="VariableBindingDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of variable which is bound to the property. This is used
                for mapping sources and targets or similar definitions that can work
                on properties of objects. It is designed to handle relativistic behavior.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="name" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
           	<xsd:element name="path" type="t:ItemPathType" minOccurs="0">
           		<xsd:annotation>
           			<xsd:documentation>
           				Path of the item (property) that is the target of the binding.
           				This is the item which is source/target of the mapping or which
           				is used for the form field. The path may not be specified if it
           				can be inferred by other means (e.g. using default source or 
           				target definitions). But even in a case that the path is default
           				we may still want to define other aspects of the binding, e.g.
           				the value set or type override.
           			</xsd:documentation>
           		</xsd:annotation>
           	</xsd:element>
           	<xsd:element name="set" type="tns:ValueSetDefinitionType" minOccurs="0">
           		<xsd:annotation>
           			<xsd:documentation>
           				Definition of the set of values for this variable. The variable
           				definition will be valid only for those variable. The evaluation
           				of the set depends on the context that the definition is used.
           				E.g. if the set is used in mapping source then it defines the
           				domain of the expression. If it used in the mapping target
           				definition then it defines range of the expression. Etc.
           			</xsd:documentation>
           		</xsd:annotation>
           	</xsd:element>
			<xsd:element name="type" type="xsd:QName" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Type override. Normally the field type will be determined
                        by the type of backing item. This field can be used as type
                        override if a different presentation is required.
                        NOT IMPLEMENTED YET
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>           	
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ValueSetDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of value set. It can define a set of values by several
                methods. E.g. it can define set by a condition, enumeration of the values
                and so on.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="condition" type="c:ExpressionType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Expression that is evaluated to check whether the value belongs to the set.
                    	  If the condition returns true then the value belongs to the set. Otherwise
                    	  it does not.
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO: other set definition types:
                       * reference to lookup table
                       * reference to schema enumeration -->
        </xsd:sequence>
    </xsd:complexType>
        
    <xsd:complexType name="ValueFilterType">
        <xsd:annotation>
            <xsd:documentation>
                Defines value filter. The value filters are supposed to take a
                single value of a specific type and return a single value of
                the same type. Filters are used to transforms values, e.g.
                to clean up illegal characters, to do charset transcoding, etc.

                Note:
                Strictly speaking, filters should be used for things like
                transliteration of national characters, case conversions, etc.
                They should not be used to "technical" transformations such as
                character set conversions. Connector should do that and connector                
                should return nice, clean unicode strings. But some connectors
                are faulty and the ability of filters to do "technical" things
                may come handy.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:deprecated>true</a:deprecated>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax">
                <xsd:annotation>
                    <xsd:documentation>
                        Filter parameters.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:any>
        </xsd:sequence>
        <xsd:attribute name="type" type="xsd:anyURI">
            <xsd:annotation>
                <xsd:documentation>
                    URI identifying the type of the filter. This is a identifier
                    of the filter code. Individual filters may plug-in under a
                    specific URI.
                </xsd:documentation>
            </xsd:annotation>
        </xsd:attribute>
    </xsd:complexType>
    
    <xsd:complexType name="ValueSetSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies set of prism item values. E.g. specifies a set of string values,
                container values (e.g. assignments) and so on. It is used at places where
                we need to select particular values based on a flexible set of criteria.
                
                DEPRECATED. Do not use. Use ValueSetDefinitionType.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:deprecated>true</a:deprecated>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
           	<xsd:element name="isInSetExpression" type="tns:ExpressionType" minOccurs="0" maxOccurs="1">
           		<xsd:annotation>
           			<xsd:documentation>
           				Expression that is evaluated for each candidate value. 
           				The value is passed to the expression in the 'input' variable.
           				If this expression returns true then the value is part of the set.
           				If it returns false (or no value) then the value is not part of the set. 
           			</xsd:documentation>
           		</xsd:annotation>
           	</xsd:element>
           	<!-- More criteria specification may come here in the future.
           	     E.g. expression that generates all possible values, 
           	     reference to lookup that has all the values, 
           	     query that works on top of the values,
           	     string patterns, etc. -->
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ExpressionType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Name of the expression (function). The name is used for several purposed.
						If the expression is a function in a function library then this name identifies
						the function (the name must be unique in the whole library).
						But even if the expression is not part of the library the name may still be used
						for diagnostic purposes.
						
						Note: There are no formal limitations about the characters used in the
						name, length of the name and so on. However, special characters in the function
						name may prohibit reasonable use of the function in some scripting languages.
						Therefore the recommendation is to use only aplhanumeric names and to avoid
						white spaces in the names. 
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:extension" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="parameter" type="tns:ExpressionParameterType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Function input parameters
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="returnType" type="xsd:QName" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Formal definition of function return type. It may not be specified
						if the expression is used in places where the return type can be
						automatically determined (e.g. mappings).
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
            <xsd:element name="trace" type="xsd:boolean" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			Explicitly trace the execution of this expression. The execution will be
            			logged on INFO level if this property is set to true to make sure that it
            			will be visible in the logs. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="stringFilter" type="tns:StringFilterType" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="variable" type="tns:ExpressionVariableDefinitionType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of additional variables that should be
                        present during evaluation of the expression.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="returnMultiplicity" type="tns:ExpressionReturnMultiplicityType" minOccurs="0"></xsd:element>
            <xsd:element name="allowEmptyValues" type="xsd:boolean" minOccurs="0" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="queryInterpretationOfNoValue" type="tns:QueryInterpretationOfNoValueType" minOccurs="0" default="filterEqualNull">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="runAsRef" type="tns:ObjectReferenceType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the user whose identity will be used to execute the expression.
                        The expression will use authorizations that this user has. If the expression
                        triggers any change then the change will be audited under the identity of
                        this user.
                        If no user is specified then the identify of currently logged-in user or
                        the owner of the task will be used.
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element ref="tns:expressionEvaluator" minOccurs="1" maxOccurs="unbounded">
            	<xsd:annotation>
            		<xsd:documentation>
            			A single expression evaluator.
            			Although this element is formally multi-value it may be used only for multiple
            			instances of the same evaluator that in fact form a single group.
            			E.g. it may be used to define several "value" elements of literal evaluator that
            			define multiple values. But it must not be used to define multiple scripts or any
            			other combination of evaluators.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="expression" type="tns:ExpressionType">
    	<xsd:annotation>
            <xsd:documentation>
                The expression that can be used to dynamically evaluate the value, e.g. in the query filter.
                
                It must be a top-level element so the processor of Query schema can find it. See prism query-2 schema.
            </xsd:documentation>
        </xsd:annotation>
    </xsd:element>
    
    <xsd:complexType name="ExpressionParameterType">
    	<xsd:annotation>
    		<xsd:documentation>
    			Describes input parameters to the expression. 
    		</xsd:documentation>
    		<xsd:appinfo>
    			<a:since>3.7</a:since>
    			<a:container/>
    		</xsd:appinfo>
    	</xsd:annotation>
    	<xsd:sequence>
    		<xsd:element name="name" type="xsd:string" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Name of the parameter
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="type" type="xsd:QName" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Parameter type
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="expression" type="tns:ExpressionType" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Expression that determines parameter value.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:simpleType name="ExpressionReturnMultiplicityType">
        <xsd:annotation>
            <xsd:documentation>
                Expression result multiplicity.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="single">
                <xsd:annotation>
                    <xsd:documentation>
                        Single return value
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SINGLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="multi">
                <xsd:annotation>
                    <xsd:documentation>
                        Multiple return values
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MULTI"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="QueryInterpretationOfNoValueType">
        <xsd:annotation>
            <xsd:documentation>
                Defined how the expression will be interpreted in queries when it returns
                empty (or null) values.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="filterEqualNull">
                <xsd:annotation>
                    <xsd:documentation>
                        The expression will be intepreted as an EQUAL filter
                        that looks for entries with no (null) value.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FILTER_EQUAL_NULL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="filterUndefined">
                <xsd:annotation>
                    <xsd:documentation>
                        The expression will be intepreted as an UNDEFINED filter.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FILTER_UNDEFINED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="filterNone">
                <xsd:annotation>
                    <xsd:documentation>
                        The expression will be intepreted as an NONE filter.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FILTER_NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="filterAll">
                <xsd:annotation>
                    <xsd:documentation>
                        The expression will be intepreted as an NONE filter.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FILTER_ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="error">
                <xsd:annotation>
                    <xsd:documentation>
                        Error will be thrown if the expression results in
                        empty (null) values.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="StringFilterType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
    </xsd:complexType>
    
    <xsd:complexType name="ExpressionVariableDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of a variable. This type declares a variable name
                and defines the initial content of the variable.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="name" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        Variable name. The variable will be presented to the expression using specified name.

                        The name is a QName, which is good for XML-based expression languages such as XPath.
                        For languages with flat names the namespace is fixed (see documentation of midPoint
                        language binding) and the only relevant name is the local part.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element ref="tns:description" minOccurs="0"/>
            <!-- This needs to be a sequence of optional elements instead of choice due to a JAXB "feature" that generates XML not valid with the schema. -->
           	<xsd:element name="path" type="t:ItemPathType" minOccurs="0"/>
            <xsd:element name="objectRef" type="tns:ObjectReferenceType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element ref="tns:value" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="expressionEvaluator" abstract="true"/>

    <xsd:element name="value" type="xsd:anyType" substitutionGroup="tns:expressionEvaluator" nillable="true">
        <xsd:annotation>
            <xsd:documentation>
                Static value for the attribute or property.

                Static attribute values. The values in this element should be
                assigned to the account as-is.

                List of values for the attribute provided in an appropriate XML elements
                that specify attribute name. (as is usual for properties)

                Only one attribute may be specified here, although it may have multiple
                values. Multi-valued attributes are expressed by repeating the same XML
                element multiple times.
                Hence all the XML elements that match this xsd:any must have the same
                element names (may have different values of course).


                Please note that this is nillable and therefore it may be
                explicitly set to "nil" value. Doing this means that empty
                set of values should be constructed. E.g. setting
                this to "nil" and also setting "authoritative" flag
                may enforce removal of all attribute values (if used properly).
            </xsd:documentation>
            <xsd:appinfo>
                <a:rawType/>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:complexType name="AsIsExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Copy value as is, without any modification.
            </xsd:documentation>
        </xsd:annotation>
    </xsd:complexType>

    <xsd:element name="asIs" type="tns:AsIsExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>
	
	<!-- Here we use complexType to create a Java class named ConstExpressionEvaluatorType -->
    <xsd:complexType name="ConstExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:simpleContent>
            <xsd:extension base="xsd:string" />
        </xsd:simpleContent>
    </xsd:complexType>

	<xsd:element name="const" type="tns:ConstExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

	<xsd:complexType name="FunctionExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Evaluates custom defined functions from Function Library
            </xsd:documentation>
            <xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="libraryRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				Reference to the library where is the function
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="name" type="xsd:string" minOccurs="1">
				<xsd:annotation>
        			<xsd:documentation>
        				Name of the function to use
        			</xsd:documentation>
        		</xsd:annotation>
			</xsd:element>
			<xsd:element name="parameter" type="tns:ExpressionParameterType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
        			<xsd:documentation>
        				Parameters
        			</xsd:documentation>
        		</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
    </xsd:complexType>
	<xsd:element name="function" type="tns:FunctionExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>
	
	<xsd:complexType name="GenerateExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Generate value according to a policy that is associated with the property/attribute.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="mode" type="tns:GenerateExpressionEvaluatorModeType" minOccurs="0" default="policy"/>
        	<xsd:element name="valuePolicyRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
	                <xsd:documentation>
	                    Reference to the value policy that should be used to generate the value.
	                </xsd:documentation>
	                <xsd:appinfo>
	        			<a:objectReferenceTargetType>tns:PasswordPolicyType</a:objectReferenceTargetType>
	        		</xsd:appinfo>
	            </xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="generate" type="tns:GenerateExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>
    
    <xsd:simpleType name="GenerateExpressionEvaluatorModeType">
        <xsd:annotation>
            <xsd:documentation>
                Value generator mode.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="policy">
                <xsd:annotation>
                	<xsd:documentation>
                		Generator generates the value according to the applicable value policy (e.g. a password policy).
                		The it generates a random string that satisfies the policy. If no policy can be determined then
                		a reasonable default policy is assumed.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="POLICY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="uuid">
                <xsd:annotation>
                	<xsd:documentation>
                		The generator generates a random Universally Unique Identifier (UUID) string.
                		The generated UUID is currently version 4 and complies with ISO/IEC 11578:1996, but this
                		can change in the future.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UUID"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:element name="script" type="tns:ScriptExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

	<xsd:element name="path" type="t:ItemPathType" substitutionGroup="tns:expressionEvaluator"/>

    <xsd:complexType name="TransformExpressionEvaluatorType" abstract="true">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element ref="tns:description" minOccurs="0"/>
            <xsd:element name="trace" type="xsd:boolean" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			Explicitly trace the execution of this expression. The execution will be
            			logged on INFO level if this property is set to true to make sure that it
            			will be visible in the logs. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="relativityMode" type="tns:TransformExpressionRelativityModeType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="includeNullInputs" type="xsd:boolean" minOccurs="0" default="true">
                <xsd:annotation>
                    <xsd:documentation>
                        If set to true (which is the default) the script will be evaluated with null value
                        as argument when the input is changed from or to an empty value. This generally works
                        well for most cases. It may be set to false as an optimization.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="allowEmptyValues" type="xsd:boolean" minOccurs="0" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        DEPECATED. Used allowEmptyValues in ExpressionType instead.
                    </xsd:documentation>
                    <xsd:appinfo>
                    	<a:deprecated>true</a:deprecated>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:simpleType name="TransformExpressionRelativityModeType">
        <xsd:annotation>
            <xsd:documentation>
                Relativity mode of an expression.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="relative">
                <xsd:annotation>
                    <xsd:documentation>
                        Relative expression. Works on (partial) individual values transforming each of them one by one.
                        This is the default.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RELATIVE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="absolute">
                <xsd:annotation>
                    <xsd:documentation>
                        Absolute expression. Works on all the values at once. May not be entirely reliable.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ABSOLUTE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="ScriptExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Generic script expression. The purpose of the expression is to return
                a value. The expression must produce something that is a piece
                of XML, which means that it may produce either string value,
                XML node or a list of XML nodes.

                The expression may use variables or arguments. However, such
                variables or arguments passed to the expression will be different
                for each invocation. It should be documented in each case this type is used.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:TransformExpressionEvaluatorType">
		        <xsd:sequence>
		            <xsd:element name="language" type="xsd:anyURI" minOccurs="0" default="http://midpoint.evolveum.com/xml/ns/public/expression/language#Groovy">
		                <xsd:annotation>
		                    <xsd:documentation>
		                        Language of the expression. Groovy is the default language if other language is not specified.
		                    </xsd:documentation>
		                </xsd:annotation>
		            </xsd:element>
		            <xsd:element name="returnType" type="tns:ScriptExpressionReturnTypeType" minOccurs="0">
		                <xsd:annotation>
		                    <xsd:documentation>
		                        The type of the expression result, either "list" or "scalar". If not set it will be
		                        determined automatically from the target data type for the expression. This setting
		                        should be used only if the automatic mechanism does not work as expected.
		                    </xsd:documentation>
		                </xsd:annotation>
		            </xsd:element>
		            <xsd:element name="code" type="xsd:string">
		                <xsd:annotation>
		                    <xsd:documentation>
		                        Script code in the native format of the scripting language.
		                    </xsd:documentation>
		                </xsd:annotation>
		            </xsd:element>
		        </xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:simpleType name="ScriptExpressionReturnTypeType">
        <xsd:annotation>
            <xsd:documentation>
                The type of the expression result, either "list" or "scalar".
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="scalar">
                <xsd:annotation>
                    <xsd:documentation>
                        Single return value
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SCALAR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="list">
                <xsd:annotation>
                    <xsd:documentation>
                        Multiple return values
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LIST"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>    

	<xsd:complexType name="SearchObjectExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Create an expression based on search results.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:TransformExpressionEvaluatorType">
		        <xsd:sequence>
		        	<xsd:element name="targetType" type="xsd:QName" minOccurs="0" maxOccurs="1">
		        	</xsd:element>
		        	<xsd:element name="oid" type="xsd:string" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				Fixed OID. If this OID is present then no search will be done. 
		        				
		        				It is planned to be used to "remeber" the search result. E.g. to
		        				search for the target on import and then store the fixed OID.
		        				But this is not yet implemented.
		        			</xsd:documentation>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="filter" type="q:SearchFilterType" minOccurs="0" maxOccurs="1">
		        	</xsd:element>
		        	<xsd:element name="searchOnResource" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
                        <xsd:annotation>
                            <xsd:documentation>
                                DEPRECATED, use searchStrategy instead.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:deprecated/>
                            </xsd:appinfo>
                        </xsd:annotation>
		        	</xsd:element>
                    <xsd:element name="searchStrategy" type="tns:ObjectSearchStrategyType" minOccurs="0" maxOccurs="1">
                    </xsd:element>
                    <xsd:element name="defaultTargetRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				Reference that will be used if no target is found.
		        			</xsd:documentation>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="createOnDemand" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
		        	</xsd:element>
		        	<xsd:element name="populateObject" type="tns:PopulateType" minOccurs="0">
		            	<xsd:annotation>
		            		<xsd:documentation>
		            			TODO
		            		</xsd:documentation>
		            	</xsd:annotation>
		            </xsd:element>
		            <xsd:element name="populate" type="tns:PopulateType" minOccurs="0">
		            	<xsd:annotation>
		            		<xsd:documentation>
		            			Populate assignment, association,... (any container) specific attributes, e.g activation status, validTo, validFrom 
		            			and can be also used for setting assignmnet parameters
		            		</xsd:documentation>
		            	</xsd:annotation>
		            </xsd:element>
		        </xsd:sequence>
	        </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
	<xsd:element name="associationTargetSearch" type="tns:SearchObjectExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

    <xsd:simpleType name="ObjectSearchStrategyType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="inRepository">
                <xsd:annotation>
                    <xsd:documentation>
                        Search is carried out in repository only.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IN_REPOSITORY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="onResource">
                <xsd:annotation>
                    <xsd:documentation>
                        Search is always carried out on the resource.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ON_RESOURCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="onResourceIfNeeded">
                <xsd:annotation>
                    <xsd:documentation>
                        Search is carried out in the repository first. If not found, then the resource is queried.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ON_RESOURCE_IF_NEEDED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

	<xsd:complexType name="SearchObjectRefExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Create an expression based on search results. This is supposed to create an object reference.
                Therefore it has additional parameter (relation).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:SearchObjectExpressionEvaluatorType">
		        <xsd:sequence>
		        	<xsd:element name="assignmentProperties" type="tns:AssignmentPropertiesSpecificationType" minOccurs="0">
    					<xsd:annotation>
    						<xsd:documentation>
    							Properties of the new assignment.
    						</xsd:documentation>
    						<xsd:appinfo>
    							<a:since>3.7</a:since>
    						</xsd:appinfo>
    					</xsd:annotation>
    				</xsd:element>
		        	<xsd:element name="relation" type="xsd:QName" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				DEPRECATED. Use assignmentProperties instead.
		        			</xsd:documentation>
		        			<xsd:appinfo>
		        				<a:deprecated>true</a:deprecated>
		        				<a:deprecatedSince>3.7</a:deprecatedSince>
		        			</xsd:appinfo>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="activation" type="tns:ActivationType" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				DEPRECATED. Use assignmentProperties instead.
		        			</xsd:documentation>
		        			<xsd:appinfo>
		        				<a:deprecated>true</a:deprecated>
		        				<a:deprecatedSince>3.7</a:deprecatedSince>
		        			</xsd:appinfo>
		        		</xsd:annotation>
		        	</xsd:element>
		        </xsd:sequence>
	        </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
	<xsd:element name="assignmentTargetSearch" type="tns:SearchObjectRefExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>
	<xsd:element name="referenceSearch" type="tns:SearchObjectRefExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

	<xsd:complexType name="ShadowDiscriminatorExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Expression based on selecting a specific projection.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:description" minOccurs="0" maxOccurs="1">
        	</xsd:element>
        	<xsd:element name="projectionDiscriminator" type="tns:ShadowDiscriminatorType" minOccurs="0" maxOccurs="1">
        	</xsd:element>
        </xsd:sequence>
    </xsd:complexType>
	<xsd:element name="assignmentFromAssociation" type="tns:ShadowDiscriminatorExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

	<xsd:complexType name="AssociationFromLinkExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of an expression that creates association from links (linkRefs)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ShadowDiscriminatorExpressionEvaluatorType">
		        <xsd:sequence>
		        	<xsd:element name="recurseUpOrgType" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				Specifies orgType of an organization tree to recurse upward.
		        				In case that the expression applies to an org, it will recurse the org
		        				tree upwards and create associations for all the orgs in the hierarchy.
		        				Only orgs with the orgType mathing this specification will be processed.
		        			</xsd:documentation>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="assignmentPathIndex" type="xsd:int" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
			        			<p>
			        				Index to the assignment path. This index points to the object that should
			        				be used as a source to get the link from.
			        				Index 0 is the focal object, index 1 is the first (plain) role,
			        				index 2 is meta-role, index 3 is meta-meta-role and so on.
			        				Negative index can also be used, in that case the order is reversed:
			        				index -1 is that last meta-meta-meta-...-role. index -2 is the one before
			        				and so on.
		        				</p>
		        				<p>
			        				If the index is not specified then a legacy algorithm will be used.
			        				The legacy algorithm is guaranteed to work up to meta-role level.
			        				For plain roles (order-one inducement) the role itself is selected.
			        				For meta-roles (order-two inducement) the first (plain) role is selected.
			        				At the meta-meta role level (order-three inducement) and above the
			        				behavior is formally undefined and it may change in any future versions.
			        				However, current behaviour roughly corresponds to assignment path index -2.
		        				</p>
		        			</xsd:documentation>
		        			<xsd:appinfo>
		        				<a:since>3.7</a:since>
		        			</xsd:appinfo>
		        		</xsd:annotation>
		        	</xsd:element>
		        </xsd:sequence>
	        </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="associationFromLink" type="tns:AssociationFromLinkExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

	<xsd:complexType name="PopulateType">
		<xsd:annotation>
			<xsd:documentation>TODO</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="populateItem" type="tns:PopulateItemType" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="PopulateItemType">
		<xsd:annotation>
			<xsd:documentation>TODO</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element ref="tns:expression"/>
			<xsd:element name="target" type="tns:VariableBindingDefinitionType"/>
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="SequentialValueExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Get a sequential value from a named sequence.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="sequenceRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
	                <xsd:documentation>
	                    Reference to the sequence from which the value is taken.
	                </xsd:documentation>
	                <xsd:appinfo>
	        			<a:objectReferenceTargetType>tns:SequenceType</a:objectReferenceTargetType>
	        		</xsd:appinfo>
	            </xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="sequentialValue" type="tns:SequentialValueExpressionEvaluatorType" substitutionGroup="tns:expressionEvaluator"/>

    <xsd:element name="synchronization" type="tns:SynchronizationType"/>

    <xsd:complexType name="SynchronizationType">
        <xsd:annotation>
            <xsd:documentation>
                Defines a synchronization properties (configuration) for a
                resource. This applies to all flavors of synchronization
                (live sync, reconciliation, import, ...)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="objectSynchronization" type="tns:ObjectSynchronizationType" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:complexType>

    <xsd:complexType name="ObjectSynchronizationType">
        <xsd:annotation>
            <xsd:documentation>
                Defines a synchronization properties (configuration) for a
                specific type of object, e.g. User. This applies to all flavors of synchronization
                (live sync, reconciliation, import, ...)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				Free-form name. Used for diagnostics purposes.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element ref="tns:description" minOccurs="0"/>
        	<xsd:element name="objectClass" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				Object classes that will be processed by this definition.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Shadow kind assumed by this definition. If not specified then the kind
        				defined by schemaHandling part will be used. However this element can define
        				a more specific kind in case that the schemaHandling part is ambiguous
        				(e.g. the same objectclass is used for two kinds).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="intent" type="xsd:string" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Shadow intent assumed by this definition. If not specified then the intent
        				defined by schemaHandling part will be used. However this element can define
        				a more specific intent in case that the schemaHandling part is ambiguous
        				(e.g. the same objectclass is used for two intents).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="focusType" type="xsd:QName" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Type of the focus that would be applied to this type.
        				If not specified the User (c:UserType) is assumed.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element name="enabled" type="xsd:boolean" minOccurs="0" default="true">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>Flag indicating if this synchronization specification is enabled. If it is not,
                        then the system will ignore this definition.
                        If enabled, the synchronization should start with most recent change
                        after enabling synchronization. It will NOT pull in even the changes that
                        were done during disabled synchronization.</p>

                        <p>If this flag is not present the synchronization is assumed to be enabled.
                        This flag is meant to act as a tool to temporarily disable synchronization without loosing the
                        configuration and and state or for forcing the synchronization engine to "skip" some changes.</p>
                        
                        <p>Note that this is different than disabling/deleting the synchronization task. If the task
                        is stopped, midPoint will not poll for changes at all. This means that the changes will
                        still be "pending" on the resource and once the task is enabled it will pull such changes.
                        On the other hand, disabling synchronization using this flag and leaving the task running will
                        "acknowledge" all changes without doing anything.</p>
                        
                        <p>Also note that disabling synchronization using this flag will disable all the flavors, e.g.
                        it will also disable import from resource.</p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="condition" type="c:ExpressionType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>Expression that is evaluated to check whether this definition is applicable to
                        a particular shadow. It is assumed to return a boolean value. If it returns 'true'
                        then the shadow will be processed by this definition. If it returns 'false' it will
                        not be processed.</p>
                        
                        <p>If no condition is present then all applicable shadows will be processed.</p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="correlation" type="tns:ConditionalSearchFilterType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>Correlation filter expression. Running the query should return a list of candidate focus
                    	entries that may be owners of a particular shadow.</p>

                        <p>Correlation is an rough but an efficient way how to relate the shadow (e.g. an account)
                        to a focus (e.g. an user). The correlation expression is in fact just a search filter that can
                        contain expressions inside it. If correlation search returns more that one entry,
                        confirmation expression will be executed for each of them.</p>

                        <p>The filter in this case is conditional, i.e. there can be specified an expression
                        that denotes a necessary condition for the filter to be applied.</p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="confirmation" type="c:ExpressionType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Confirmation expression. The arguments are an account and a candidate owner (user). The
                        confirmation expressions should return true if the user should be owner of the account. It
                        should return false if the user cannot be owner of the account.

                        The evaluation of the confirmation expression may be relativelly inefficient, as it will only
                        be run for candidate entries returned by correlation expression.

                        The expression variables should be set as follows:
                        $user - the candidate user object (one of the results of correlation expression)
                        $account - the changed account object
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="objectTemplateRef" type="tns:ObjectReferenceType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Object template used in case the midPoint (focus) objects are created or modified.
            			This overrides the system global object templates.
            			
            			This option is usually used set per-resource user template.
            		</xsd:documentation>
            		<xsd:appinfo>
                    	<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                    </xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="reconcile" type="xsd:boolean" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			If set to true, applicable synchronization reactions will attempt to reconcile the real attributes
            			from the resource with the state of the midPoint repository. This may require additional read and
            			recompute, therefore may be slightly less efficient.
            			
            			If set to false, attribute values will not be reconciled.
            			
            			If not present the attribute values will only be reconciled if they are available ("automatic" mode).
            			No additional read will be executed. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
             <xsd:element name="limitPropagation" type="xsd:boolean" minOccurs="0" default="false">
            	<xsd:annotation>
            		<xsd:documentation>
            			If set to true, applicable synchronization reactions will propagate changes only form/to source 
            			resource. In the case focus cotains links to another resource this will be not recomputed
            			and after reaction execution there may be small inconsistencies.
            			
            			It can improve performance for example for initial import.
            			
            			Default value is false. 
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="opportunistic" type="xsd:boolean" minOccurs="0" default="true">
            	<xsd:annotation>
            		<xsd:documentation>
            			If set to true midPoint will try to link and synchronize objects whenever possible.
            			E.g. it will link accounts in a case if an account with a conflicting account is found
            			and correlation expression matches. MidPoint can be quite aggressive in this mode therefore
            			this switch is used to turn it off. It is on by default.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="reaction" type="tns:SynchronizationReactionType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ConditionalSearchFilterType">
        <xsd:annotation>
            <xsd:documentation>
                A filter with an expression that denotes a necessary condition for the filter to be applied.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="q:SearchFilterType">
                <xsd:sequence>
                    <xsd:element name="condition" type="tns:ExpressionType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                A condition that must be true in order to evaluate the filter.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:simpleType name="SynchronizationSituationType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="deleted">
                <xsd:annotation>
                    <xsd:documentation>
                        The account existed on the resource, but it has been deleted.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DELETED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="disputed">
                <xsd:annotation>
                    <xsd:documentation>
                        New account is found and two or more owners are found for it.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DISPUTED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="linked">
                <xsd:annotation>
                    <xsd:documentation>
                        The account exists and is linked to user. (synchronization event - modify)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LINKED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unlinked">
                <xsd:annotation>
                    <xsd:documentation>
                        The account was created and is not linked to user. (synchronization event - add)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNLINKED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unmatched">
                <xsd:annotation>
                    <xsd:documentation>
                        The new account is found on the resource (it exists) and
                        IDM cannot determine any owner for the account.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNMATCHED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="SynchronizationReactionType">
	    <xsd:annotation>
	        <xsd:documentation>
	            Reaction to a synchronization situation.
	            Situation identifier must be unique in this set (i.e. a situation definition may occur only once
	            for each situation).
	            If there is no definition for a particular situation, there will be no reaction ("do nothing").
	            The set of situation reactions is considered to be unordered.
	        </xsd:documentation>
	    </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="situation" type="tns:SynchronizationSituationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines a particular synchronization situation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="channel" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="synchronize" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="reconcile" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="limitPropagation" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="objectTemplateRef" type="tns:ObjectReferenceType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Object template used in case the focus object is created or modified.
            			This overrides other template definitions (system global, resource).
            		</xsd:documentation>
            		<xsd:appinfo>
                    	<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                    </xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="action" type="tns:SynchronizationActionType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SynchronizationActionType">
	    <xsd:annotation>
	        <xsd:documentation>
	            Defines an action to take when a synchronization situation is encountered.
	            The actions change the default midpoint behaviour.
	            If there is no action for a particular situation,there will be no special
	            reaction and the default activity takes place.
	            Several actions may be defined for a specific reaction. All of them will be
	            executed however the ordering is not guaranteed.
	        </xsd:documentation>
	    </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
        	<xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
        	<xsd:element name="handlerUri" type="xsd:anyURI" minOccurs="0" maxOccurs="1"/>
        	<xsd:element name="order" type="tns:BeforeAfterType" minOccurs="0" default="before"/>
        	<!-- TODO: ordering? -->
        	<xsd:element name="parameters" minOccurs="0">
        		<xsd:complexType>
        			<xsd:sequence>
			            <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Action parameters.
			                        TODO
			                    </xsd:documentation>
			                </xsd:annotation>
			            </xsd:any>
        			</xsd:sequence>
        		</xsd:complexType>
            </xsd:element>
        	<xsd:element name="userTemplateRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				DEPRECATED. For compatibility only. Use objectTemplateRef in reaction instead.
        			</xsd:documentation>
        			<xsd:appinfo>
                    	<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                    	<a:deprecated/>
                    </xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="objectTemplateRef" type="tns:ObjectReferenceType" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				DEPRECATED. For compatibility only. Use objectTemplateRef in reaction instead.
        			</xsd:documentation>
        			<xsd:appinfo>
                    	<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                    	<a:deprecated/>
                    </xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="ref" type="xsd:anyURI" use="optional">
            <xsd:annotation>
                <xsd:documentation>
                    Action identifier (URL)
                    DEPRECATED. Use handlerUri element instead.
                </xsd:documentation>
                <xsd:appinfo>
                	<a:deprecated/>
                </xsd:appinfo>
            </xsd:annotation>
        </xsd:attribute>
    </xsd:complexType>
   
    <xsd:complexType name="ResourceObjectShadowChangeDescriptionType">
        <xsd:annotation>
            <xsd:documentation>
            	Description of the change in the external resource. 
            </xsd:documentation>
        </xsd:annotation>
        	<xsd:sequence>
            	<xsd:element name="oldShadowOid" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Identifier of the old shadow. According to this identifier, the shadow will be
                                fetched from the repo (resource). It may be null in the case when the notification
                                describes the ADD object sitaution.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="currentShadow" type="tns:ShadowType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Current shadow. This is used in the "absolute" mode, when we do not have change description.
                                Shadow represents the current state with the modifications already applied to its. Current 
                                shadow is used to compare to the old state so the modifications may be computed and synchronized.
                                It may be null. If the current shadow is null, object delta have to be specified.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="objectDelta" type="t:ObjectDeltaType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Delta describing the changes made to the shadow. E.g. if the change in the resource was
                                to add new account, delta will contain ADD modification with the object specified.
                                It may be null. If the object delta is null, the current shadow have to be specified.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="channel" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Channel which triggers the execution of notification, e.g. synchronization, reconciliation etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
    </xsd:complexType>
    
    <xsd:element name="resourceObjectShadowChangeDescription" type="tns:ResourceObjectShadowChangeDescriptionType"/>

    <xsd:complexType name="ConnectorType">
        <xsd:annotation>
            <xsd:documentation>
                Description of a generic connector. Connector in midPoint is any method of connection to the resource.
                The
                actual implementation, connector framework or protocol does not matter.

                The values of "framework", "connectorType", "connectorVersion" and "connectorHost" (if present) together form a unique
                identification of the connector. That means that two ConnectorType objects that have these values same
                represent the same connector. Only one such instance of ConnectorType should exist in the repository.

                Note: The ConnectorType does not describe
                only Identity Connector Framework (ICF) connectors, it is much more generic.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ObjectType">
                <xsd:sequence>
                    <xsd:element name="displayName" type="t:PolyStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	Human-readable name of the connector. It may be quite long, container national characters
                            	and there is no uniqueness requirement.
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>ConnectorType.displayName</a:displayName>
		                    	<a:displayOrder>100</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="framework" type="xsd:anyURI">
                        <xsd:annotation>
                            <xsd:documentation>
                                Identification of the framework or mechanism
                                that implements this connector.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorType" type="xsd:string">
                        <xsd:annotation>
                            <xsd:documentation>
                                Type of the connector, as seen by the framework.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorVersion" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Version of the connector. Used only for display purposes and for searching during imports. Therefore it
                                may be any (sensible) string, but it should be reasonably stable to avoid broken imports.

                                May be any string (numeric convention is recommended, but not required).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorBundle" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Name of a package that the connector comes in. It may be a name of the JAR file, ICF
                                bundle name, URL or any other designation of the packaging.
                                This is optional, it may not be provided.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="targetSystemType" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Identification of the kind of target system
                                that the connector can connect to, such as "LDAP" or "DB Table". Used only for
                                display purposes and for searching during imports. Therefore it may
                                be any (sensible) string, but it should be reasonably stable to avoid
                                broken imports.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="namespace" type="xsd:anyURI" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Connector-private namespace. This is the namespace
                                that is private for a specific connector (and
                                optionally connector version).
                                It may be used by the connector to generate
                                connector configuration schema or for other purposes.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="connectorHost" type="tns:ConnectorHostType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Connector host that hosts this connector.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:connectorHostRef</a:objectReference>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="connectorHostRef" type="c:ObjectReferenceType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference to the connector host that hosts this connector.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ConnectorHostType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element ref="tns:schema" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Connector configuration schema.

                                This element contains the XSD-formatted definition of connector
                                configuration schema. It defines connector configuration variables and data types such
                                as host names, ports, administrator names and so on.

                                Connector schema is only
                                available at run-time and may be different
                                for every connector. It is supposed to be
                                dynamically interpreted in run-time.

                                Connector schema is read-only. Changing the
                                schema is not supported.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="connector" type="tns:ConnectorType" substitutionGroup="c:object"/>

    <xsd:complexType name="ConnectorHostType">
        <xsd:annotation>
            <xsd:documentation>
                Host definition for remote connector, remote
                connector framework or a remote "gateway".

                Note that this is a generic concept of a connector host, not specific to
                any connector framework. It can be extended with a framework-specific
                configuration using the usual "extension" element.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ObjectType">
                <xsd:sequence>
                    <xsd:element name="hostname" type="xsd:string">
                        <xsd:annotation>
                            <xsd:documentation>
                                Hostname of a remote host. May also be an IP address.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="port" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Port number of the remote service. If not present, default
                                port number is assumed by the implementation.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="sharedSecret" type="t:ProtectedStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Shared secret used to authenticate client to the host.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="protectConnection" type="xsd:boolean" minOccurs="0" default="false">
                        <xsd:annotation>
                            <xsd:documentation>
                            	If set to true then a protected connection will be established (usually SSL).
                                UNSTABLE. WILL CHANGE IN THE FUTURE.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="timeout" type="xsd:int" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Timeout (in milliseconds) used when initially connecting to the
                                host or during other connections when timeout is not otherwise specified.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="connectorHost" type="tns:ConnectorHostType" substitutionGroup="c:object"/>


    <xsd:complexType name="ShadowType">
        <xsd:annotation>
            <xsd:documentation>
                Local copy of any object on the provisioning resource that is related to provisioning.
                It may be account, group, role (on the target system), privilege, security label,
                organizational unit or anything else that is worth managing in identity management.
                
                In the minimal form it contains only identifiers and meta-data, but it may also be used
                for locally caching the account data (in local repository).

                This XML object provides a representation of the resource object in the IDM system, in
                the LOCAL REPOSITORY. It may represents a minimal data structure in IDM repository
                that contains only identifier and nothing else. It may also represent a rich structure
                with a lot of cached or fetched data. The actual content of this object depends on usage:
                on the specific interface and operation used and even on the system state and configuration.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                    <xsd:element name="resourceRef" type="c:ObjectReferenceType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference to a resource that this resource object shadow belongs to.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ResourceType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="resource" type="tns:ResourceType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Resource that this resource object shadow belongs to.
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:resourceRef</a:objectReference>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="result" type="tns:OperationResultType"  minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Result describing if shadow was successfully processed, or not. If not, the errors should  be saved.
							</xsd:documentation>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="objectChange" type="t:ObjectDeltaType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Description of changes that happened to an resource object shadow.
								This is still used in midPoint 3.6 for consistency mechanism. However, it is
								deprecated. Later midPoint versions will use pendingOperation instead.
							</xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
							</xsd:appinfo>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="attemptNumber" type="xsd:int" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Description of number of attempts made for the resolving account consistency issues. 
							</xsd:documentation>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="failedOperationType" type="tns:FailedOperationTypeType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Description of operation during the processing of account failed. 
								This is still used in midPoint 3.6 for consistency mechanism. However, it is
								deprecated. Later midPoint versions will use pendingOperation instead.
							</xsd:documentation>
							 <xsd:appinfo>
		                    	<a:displayName>ShadowType.failedOperationType</a:displayName>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="dead" type="xsd:boolean" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Description of operation during the processing of account failed. 
							</xsd:documentation>
							<xsd:appinfo>
		                    	<a:displayName>ShadowType.dead</a:displayName>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="pendingOperation" type="tns:PendingOperationType" minOccurs="0" maxOccurs="unbounded">
						<xsd:annotation>
							<xsd:documentation>
								Description of an operation which which execution is pending for this shadow.
								This may be asynchronous operation in progress. E.g. operation that has to be
								manually completed by human operator. It may also be operation that could not
								be completed because there was a temporary error while communicating with the
								resource. There may be also operations that are in fact already executed, but
								we have not yet received the feedback. Or operations that are executed but are
								still kept in the shadow for review by midPoint administrator. 
							</xsd:documentation>
							 <xsd:appinfo>
		                    	<a:displayName>ShadowType.pendingOperation</a:displayName>
		                    	<a:since>3.6</a:since>
		                    	<a:index>presence</a:index>
		                    </xsd:appinfo>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="synchronizationSituation" type="tns:SynchronizationSituationType" minOccurs="0">
	     				<xsd:annotation>
							<xsd:documentation>
								The most recent synchronization situation. Regardless of the channel.
								This simple enumeration property is used for (indexed) search of shadows in certain situation.
								It does not provide any further details. More details can be found in the "synchronizationSituationDescription"
								property.
							</xsd:documentation>
							 <xsd:appinfo>
		                    	<a:displayName>ShadowType.synchronizationSituation</a:displayName>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="synchronizationTimestamp" type="xsd:dateTime" minOccurs="0">
	     				<xsd:annotation>
							<xsd:documentation>
								The timestamp of the most recent synchronization. Regardless of the channel or result.
								It does not provide any further details. More details can be found in the "synchronizationSituationDescription"
								property.
							</xsd:documentation>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="fullSynchronizationTimestamp" type="xsd:dateTime" minOccurs="0">
	     				<xsd:annotation>
							<xsd:documentation>
								The timestamp of the most recent full synchronization. Regardless of the channel or result.
								It does not provide any further details. More details can be found in the "synchronizationSituationDescription"
								property.
							</xsd:documentation>
						</xsd:annotation>
     				</xsd:element>
     				<xsd:element name="synchronizationSituationDescription" type="tns:SynchronizationSituationDescriptionType" minOccurs="0" maxOccurs="unbounded">
     					<xsd:annotation>
							<xsd:documentation>
								Complex description of synchronization situations. This is multi-valued proprty and it should
								store only a single value for each channel (the most recent one). All the older values shoule be
								removed on each update.
							</xsd:documentation>
						</xsd:annotation>
     				</xsd:element>
                    <xsd:element name="objectClass" type="xsd:QName">
                        <xsd:annotation>
                            <xsd:documentation>
                                The reference to a type definition for this object. The reference should point
                                to the object class definition (complex type definition in resource schema).

                                The attributes contained in the "attributes" element below are expected to
                                comply with the type definition specified in this element (with addition of
                                auxiliary object class definitions).
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>ShadowType.objectClass</a:displayName>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="auxiliaryObjectClass" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                The reference to additional type definitions for this object. The reference should
                                point to object class definition (complex type definition in resource schema) and
                                this definition should be marked as auxiliary.

                                The attributes contained in the "attributes" element below are expected to
                                comply with the type definition specified in the objectClass element merged
                                with definitions specified in this element.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Kind of a shadow. This means the type of shadow use. 
                                E.g. an account, entitlement, etc.
                                If not specified defaults to "generic".
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="intent" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The intended usage type or purpose of the object. E.g. for accounts it may be
                                "user", "admin", "test".
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>ShadowType.intent</a:displayName>
		                    	<a:emphasized>true</a:emphasized>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="protectedObject" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Protected shadows cannot be changed. They are out of IDM control.
                    			This is only informational property. Changing it will have no effect on
                    			whether object is protected or not. Object protection is a strict policy that
                    			cannot be easily overriden.
                    			
                    			This is "virtual" property. It is not stored in the repository.
                    		</xsd:documentation>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="ignored" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Ignored shadows will not be processed during synchronization.
                    		</xsd:documentation>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="assigned" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Set to true if the object is "legally" assigned, i.e. if there is a valid
                    			assignment for this object. It shows the value from the last recompute of
                    			the object.
                    		</xsd:documentation>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="exists" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Set to true if the object is known to exist on the resource.
                    			There may be shadows for objects that do not exist yet (e.g. create operations in progress)
                    			or shadows for objects that we known nothing about yet.
                    		</xsd:documentation>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="iteration" type="xsd:int" minOccurs="0">
                    </xsd:element>
                    <xsd:element name="iterationToken" type="xsd:string" minOccurs="0">
                    </xsd:element>
                    <xsd:element name="attributes" type="tns:ShadowAttributesType" minOccurs="0">
	                    <xsd:annotation>
	                    	<xsd:appinfo>
	                    		<a:displayName>ShadowType.attributes</a:displayName>
	                    	</xsd:appinfo>
	                    </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="association" type="tns:ShadowAssociationType" minOccurs="0" maxOccurs="unbounded">
                    	<xsd:annotation>
                    		<xsd:appinfo>
                    			<a:displayName>ShadowType.association</a:displayName>
                    		</xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="activation" type="tns:ActivationType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                TODO

                                For more details see the ActivationType
                                documentation.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.activation</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="credentials" type="tns:CredentialsType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                The set of account credentials (such as
                                passwords).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element ref="tns:cachingMetadata" minOccurs="0">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			The shadow is essentially a bunch of metadata and cached data
                    			about the actual resource object. This caching metadata structure
                    			describes when the cached data were retrieved - therefore how fresh
                    			they are.
                    			For now the cachingMetadata are not stored in the repository.
                    			This is now a "virtual" and "transient" property filled in
                    			when the full shadow is retrieved from the resource.
                    			Later on this can get a more proper meaning when we implement
                    			full attribute caching.
                    		</xsd:documentation>
                    	</xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="account" type="tns:ShadowType" substitutionGroup="c:object">
     	<xsd:annotation>
     		<xsd:documentation>
     			DEPRECATED. Used only for compatibility back when there was an AccountShadowType.
     		</xsd:documentation>
     		<xsd:appinfo>
      			<a:deprecated>true</a:deprecated>
      		</xsd:appinfo>
     	</xsd:annotation>
     </xsd:element>
    <xsd:element name="shadow" type="tns:ShadowType" substitutionGroup="c:object"/>
    
    <xsd:simpleType name="ShadowKindType">
        <xsd:annotation>
            <xsd:documentation>
                Defines the kind of a shadow. 
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="account">
                <xsd:annotation>
                	<xsd:documentation>
                		Represents account on a target system.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ACCOUNT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="entitlement">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ENTITLEMENT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="generic">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="GENERIC"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="ShadowAttributesType">
    	<xsd:annotation>
            <xsd:documentation>
                Attribute values from the resource. The values may be freshly fetched from
                the resource or cached. The set of attributes may be empty, may provide a
                complete copy of the resource object or anything in between. This depends on
                the implementation of the caching and fetching strategy, configuration of the
                provisioning subsystem or operation that was invoked.

                When this object is stored, attribute set will contain attribute values that
                are (persistently) cached from the resource.

                In the normal case, there should be at least attributes that identify the
                resource object on the resource (identifiers). This will be a single attribute
                in a normal case, something like uid, username, DN, etc. But if a single attribute
                is not enough to identify the account, more than one attribute may be present.

                There also may be no attributes. This can happen e.g. if IDM system knows that
                user should have account on the resource, but the account is not yet created
                and no identifier is yet assigned to it.

                This schema does not distinguish which attributes are identifiers and which are
                ordinary attributes. That can be learned from the resource schema provided by
                resource or resource connector.

                Motivation: Resource schema is dynamic, the attribute that is identifier for a
                specific object may be different for different resources, even if the resources
                are of the same type (e.g. directory servers with different LDAP schema). And we
                do not really need to know which of the attributes is identifier in the compile-time.
                Knowing that in run-time is enough.

                Please note that this may be out of sync with regard to the resource. In some
                operations (e.g. lookup) it will be only milliseconds old, but in case of stored
                cached values this may be days or even weeks old value.

                Even though there is a single extensible element "attributes", we do not want to put
                its content directly to the body of resource object. Doing so will cause problems
                with UPA rule and it will effectively prohibit the the of type replacement extensibility
                on this object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
	    <xsd:sequence>
	        <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax">
	        </xsd:any>
	    </xsd:sequence>
	    <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:complexType name="ShadowAssociationType">
    	<xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
	    <xsd:sequence>
	        <xsd:element name="name" type="xsd:QName" minOccurs="0"/>
	        <xsd:element name="shadowRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:ShadowType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
	        <xsd:element name="identifiers" type="tns:ShadowIdentifiersType" minOccurs="0" maxOccurs="1"/>
	    </xsd:sequence>
	    <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    <xsd:element name="shadowAssociation" type="tns:ShadowAssociationType" />

    <xsd:complexType name="ShadowIdentifiersType">
    	<xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
	    <xsd:sequence>
	        <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax">
	        </xsd:any>
	    </xsd:sequence>
	    <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:complexType name="PendingOperationType">
    	<xsd:annotation>
            <xsd:documentation>
                Description of an operation that is pending (in progress) or that was
                recently completed.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
	    <xsd:sequence>
	        <xsd:element name="delta" type="t:ObjectDeltaType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Operation delta. This is the change that is executed by the operation.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="requestTimestamp" type="xsd:dateTime" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						The timestamp of operation request. The point in time when the operation was
    						recoded. It is set once and should never be changed.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.6</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="operationStartTimestamp" type="xsd:dateTime" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						The timestamp of operation start. The point in time when the operation was
    						initiated for the first time. It is set once and should never be changed.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.7.1</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
			<xsd:element name="completionTimestamp" type="xsd:dateTime" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						The timestamp of operation completion. The point in time when the operation was
    						successful or when it has failed for the last time. No attempts to re-try the
    						operation were done after this timestamp.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.6</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
			<xsd:element name="executionStatus" type="tns:PendingOperationExecutionStatusType" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						Execution status. This property indicates in which execution stage
    						the operation is, e.g. whether it is requeste, being executed, completed,
    						and so on.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.7.1</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element><xsd:element name="resultStatus" type="tns:OperationResultStatusType" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						Operation result status. This property specifies result of operation execution.
    						If execution status is present and set to anything else than "completed" then
    						resultStatus may be empty.
    					</p>
    					<p>  
    						Legacy meaning: If no execution status is present then resultStatus
    						defines the execution status (this is pre-3.7.1 behavior). 
    						If set to in_progress then the operation is
    						still executing. If not present at all then the operation was
    						not yet tried.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.6</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="asynchronousOperationReference" type="xsd:string" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					<p>
    						Reference to an asynchronous operation that can be used to refresh
							the status of the running operation.
    					</p>
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:since>3.6</a:since>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
    		<!-- TODO operation type? E.g. distinguish between manual connector and consistency mechanism? Or is that implicit? -->
	    </xsd:sequence>
	    <xsd:attribute name="id" type="xsd:long" use="optional"/>
    </xsd:complexType>
    
    <xsd:simpleType name="PendingOperationExecutionStatusType">
        <xsd:annotation>
            <xsd:documentation>
                Execution status. This property indicates in which execution stage
				the operation is, e.g. whether it is requeste, being executed, completed,
				and so on.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="requested">
                <xsd:annotation>
                	<xsd:documentation>
                		Operation is requested. Operation request is recorded.
                		The operation is in the preparation phase and it is
                		not being execute yet.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REQUESTED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="executionPending">
                <xsd:annotation>
                	<xsd:documentation>
                		Operation execution is pending. The operation is prepared
                		but it is not executed yet. The operation waits for the
                		execution process to pick it up, waits for a condition or signal, etc.
                		For manual operations this means that the case/ticket is not
                		created yet. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXECUTION_PENDING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="executing">
                <xsd:annotation>
                	<xsd:documentation>
                		Operation is being executed. The excution process is running,
                		manual execution task is created and still open and so on.
                		The execution may take quite a long time.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXECUTING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="completed">
                <xsd:annotation>
                	<xsd:documentation>
                		Execution is complete. Operation is not executed any more.
                		For manual operations this means that the case/ticket is closed.
                		The operation may be successful or it may have ended up with an error.
                		This informtion is in another property. This state indicates only that
                		the operation execution is done. It does NOT indicate success or failure.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="COMPLETED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="SynchronizationSituationDescriptionType">
    	<xsd:annotation>
    		<xsd:documentation>
    			Complex description of a synchronization situation. It describes the resulting situation
    			but also when it happened (timestamp) and from where it originated (channel).
    		</xsd:documentation>
    	</xsd:annotation>
    	<xsd:sequence>
    		<xsd:element name="situation" type="tns:SynchronizationSituationType"/>
    		<xsd:element name="timestamp" type="xsd:dateTime"/>
    		<xsd:element name="channel" type="xsd:anyURI" minOccurs="0"/>
    		<xsd:element name="full" type="xsd:boolean" minOccurs="0"/>
    	</xsd:sequence>
    </xsd:complexType>

    <!-- CONVENIENCE ELEMENTS Following definitions are there to use in examples, 
		import files, etc. These should not be used in the services -->

    <xsd:element name="objects">
        <xsd:complexType>
            <xsd:annotation>
                <xsd:documentation>
                    Object list, to be used in import files and
                    examples.
                </xsd:documentation>
                <xsd:appinfo>
                    <a:container/>
                </xsd:appinfo>
            </xsd:annotation>
            <xsd:sequence>
                <xsd:element ref="c:object" minOccurs="0" maxOccurs="unbounded"/>
            </xsd:sequence>
            <xsd:attribute name="id" type="xsd:long" use="optional"/>
        </xsd:complexType>
    </xsd:element>

    <!-- MODEL SCHEMA -->

    <!-- The following clauses belong to the model schema, not here. But due 
		to a couple of OpenESB bug (see OPENIDM-124) we were forced to include the 
		whole model and identity schema in this namespace. It's bad, ugly and very 
		dangerous. But there is no other known solution. If you know one, please 
		let us know. We will really appreciate that. -->

    <xsd:annotation>
        <xsd:documentation>
            IDM Model schema defines the structure of roles, rules, access policies, 
            method of assignment of accounts and other resource objects and all 
            the properties of access control model. It is based on the identity schema, 
            using concepts of User, Account Shadow and so on. IDM Model schema is 
            static, it is available in compile-time.

            Current IDM model schema defines very minimal RBAC model.
            It is defined as temporary model to allow midPoint to be usable
            while we take the time to design a full-featured complex IDM model.

            Expect that the model will be replaced and do not depend
            on this schema in low-level components (except perhaps repository).
        </xsd:documentation>
    </xsd:annotation>

    <xsd:complexType name="AbstractRoleType" abstract="true">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	            	Abstract class that conins the "essence" of a role.
	            	This is kind of "Roleable" interface when speaking in Java terms.
            	</p>
				<p>            	
	                A role implies assignments. The role may "grant" accounts on resources, 
	                attributes and entitlements for such accounts. The role can also assign
	                organizational units, other roles or various IDM objects
	                that can be assigned directly to user. Role is in fact just
	                a named set of assignments.
                </p>
				<p>
	                This is the basic building block of role-based access
	                control (RBAC) in the provisioning system. It defines what
	                rights (e.g. accounts) should be given to user, how they
	                should look like (attributes) and what groups or native
	                roles to assign to them (entitlements).
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:FocusType">
                <xsd:sequence>
                	<xsd:element name="displayName" type="t:PolyStringType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                            	Human-readable name of the role or org. It may be quite long, container national characters
	                            	and there is no uniqueness requirement. It is used if the "name" property contains a code that
	                            	is not entirelly user-friendly.
                            	</p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>AbstractRoleType.displayName</a:displayName>
		                    	<a:displayOrder>9</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="identifier" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
	                            <p>
	                                Identifier of the role or org. It should be a structured information usually used for
	                                referring to the role or org or correlating it in various systems. E.g. numeric organizational
	                                unit identifier, role code, etc. It should be unique in its "own" scope. E.g. an organizational
	                                unit identifier should be unique in the scope of all organizational units but it may conflict 
	                                with an identifier of a project.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
		                    	<a:displayName>AbstractRoleType.identifier</a:displayName>
		                    	<a:displayOrder>110</a:displayOrder>
		                    </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                   
                   <xsd:element name="inducement" type="tns:AssignmentType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                            		Inducements define the privileges and "features" that other objects should have. It is
                            		a form of indirect assignment.
                            	</p>
                            	<p>
                            		Unlike assignments inducements do not apply to the object in which they are specified.
                            		Inducements apply to the object that is has assigned the object which contains inducements.
                            		E.g. inducements specified in a role will not be applied to the role itself.
                            		The inducements will be applied to the user that is assigned to such role.
                            	</p>
                            	<p>
                            		See <a href="https://wiki.evolveum.com/display/midPoint/Assignment+vs+Inducement">Assignment vs Inducement</a>
                            		in midPoint wiki.
                            	</p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>AbstractRoleType.inducement</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="authorization" type="tns:AuthorizationType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Set of role authorizations. Authorization define fine-grained access to midPoint objects
	                                and system functionality. The authorizations that are defined in a role apply to all
	                                users that have this role assigned (such user is a "subject" of the authorizations).
                                </p>
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="requestable" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			<p>
	                    			If set to true then this role may be directly requested by the users.
	                    			The value of this property is only meant as a hint for role presentation.
	                    			It does NOT define any access control mechanisms. For access control please
	                    			use the authorization element.
                    			</p>
                    		</xsd:documentation>
                    		 <xsd:appinfo>
                                <a:displayName>AbstractRoleType.requestable</a:displayName>
                            </xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="delegable" type="xsd:boolean" minOccurs="0" default="false">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			<p>
	                    			If set to true then this role may be delegated to a deputy.
	                    			The value of this property is only meant as a hint for role presentation.
	                    			It does NOT define any access control mechanisms. For access control please
	                    			use the authorization element.
                    			</p>
                    		</xsd:documentation>
                    		 <xsd:appinfo>
                                <a:displayName>AbstractRoleType.delegable</a:displayName>
                                <a:since>3.5</a:since>
                            </xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="idempotence" type="tns:IdempotenceType" minOccurs="0" default="none">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			<p>
                    				<p>
		                    			This value indicates, whether the evaluation of this role gives the
		                    			same results regardless of its position in the assignment/inducement
		                    			hierarchy. I.e. evaluation of this roles does not depend on the assignment
		                    			parameters of focus or any of the preceding roles. This flag is used
		                    			to enable aggresive caching of role evaluation, so idempotent roles
		                    			are only evaluated once regardless of their position in the hierarchy
		                    			as we can assume that any subsequent eveluation will produce exactly
		                    			the same results as the first evaluation. This is a very important
		                    			feature that allows efficient evaluation of big role hierarchies.
		                    		</p>  
	                    			<p>
	                    				Marking role as idempotent is likely to result in huge performance
	                    				improvements in systems with large role hierarchies. But there are
	                    				also risks of incorrect evaluation of the roles.
	                    				If an role is idempotent then is is also assumed that any roles included
	                    				in this role are also idempotent. Therefore please take care when
	                    				constructing role hierarchies. This property has a default value
	                    				that indicates no idempotency.
	                    			</p>
	                    			<p>
	                    				Rules of the thumb: 
	                    				Roles that are frequently used, roles that are
	                    				included in many other roles and roles that combine many other roles
	                    				are should be idempotent. Typical example is a "basic" roles that is
	                    				assigned to almost any user and that contains a lot of smaller roles.
	                    				Roles that are parametric or very dynamic should NOT be idempotent.
	                    				Note: it is perfectly OK for some dynamic roles to be marked as
	                    				idempotent - even if the role contains complex expressions and conditions.
	                    				If those conditions depend only on the environment or properties of the
	                    				focus then their outcome does not depend on their posittion in
	                    				assignment/inducement hierarchy and these roles can be made idempotent.   
	                    			</p>
                    			</p>
                    		</xsd:documentation>
                    		 <xsd:appinfo>
                                <a:displayName>AbstractRoleType.idempotent</a:displayName>
                                <a:since>3.6</a:since>
                            </xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
					<xsd:element name="exclusion" type="tns:ExclusionPolicyConstraintType" minOccurs="0" maxOccurs="unbounded">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Specification of excluded roles (part of Segregation of Duties policy).
								</p>
								<p>
									DEPRECATED. Use policyConstraints instead.
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="riskLevel" type="xsd:string" minOccurs="0">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			<p>
	                    			Indication of the level of risk associated with the persissions that this role assigns.
	                    			This may be a numeric value, textual label are any other suitable machine-processable indication.
                    			</p>
                    		</xsd:documentation>
                    		 <xsd:appinfo>
                                <a:displayName>AbstractRoleType.riskLevel</a:displayName>
                            </xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
					<xsd:element name="ownerRef" type="c:ObjectReferenceType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Owner of this role. The owner is a person (or group) that is responsible for maintenance of
	                                role definition.
	                                This reference may point to object of type UserType of OrgType.
                                </p>
                            </xsd:documentation>
                             <xsd:appinfo>
                                <a:displayName>AbstractRoleType.owner</a:displayName>
                                <a:deprecated>true</a:deprecated>
                                <a:deprecatedSince>3.7</a:deprecatedSince>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
					<xsd:element name="approverRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Approvers for this role. The approver is a person (or group) that approves assignment
	                                of this role to other users.
	                                This reference may point to object of type UserType of OrgType.
                                </p>
                            </xsd:documentation>
                             <xsd:appinfo>
                                <a:displayName>AbstractRoleType.approver</a:displayName>
                                <a:deprecated>true</a:deprecated>
                                <a:deprecatedSince>3.7</a:deprecatedSince>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="approverExpression" type="c:ExpressionType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Approvers for this role. If specified, the expression(s) are evaluated and the result
	                                is used as a set of approvers (UserType, OrgType, RoleType, or any combination of them).
	                                May be used with approverRef element(s).
                                </p>
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="approvalSchema" type="c:ApprovalSchemaType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                More complex (multi-level) approval schema. If used, it overrides both
	                                approverRef and approverExpression elements.
                                </p>
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="approvalProcess" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Name of custom approval process. If used, it overrides
	                                approverRef, approverExpression, and approvalSchema elements.
                                </p>
								<p>
	                                For explicitness, only one of approverRef(s)/approverExpression(s),
	                                approvalSchema and approvalProcess should be specified.
                                </p>
                                <p>
                                    THIS PROPERTY (approvalProcess) IS NOT SUPPORTED YET.
                                </p>
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="automaticallyApproved" type="c:ExpressionType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Condition specifying when the assignment is automatically approved (e.g. "user is
	                                from Board of Directors"). This is an expression that should yield a boolean value.
                                </p>
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="condition" type="tns:MappingType" minOccurs="0">
		               <xsd:annotation>
		                   <xsd:documentation>
		                   		<p>
			                       The role is applied only if the condition is evaluated to true.
			                       The condition is used to define conditional roles.
			                       If condition is not present, it is assumed to be true.
		                       </p>
		                   </xsd:documentation>
		               </xsd:annotation>
		           </xsd:element>
		           <xsd:element name="policyConstraints" type="tns:PolicyConstraintsType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Set of governance, risk management, compliance (GRC) and similar policy constraints
									that influence the identity model.
								</p>
								<p>
									DEPRECATED. Use the policy rules in the assignments/inducements instead.
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.1.1</a:since>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.5</a:deprecatedSince>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="adminGuiConfiguration" type="tns:AdminGuiConfigurationType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Specifies the admin GUI configuration that should be used
									for the members of this role.
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.4</a:since>
                                <a:displayName>AdminGuiConfigurationType.adminGuiConfiguration</a:displayName>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="dataProtection" type="tns:DataProtectionType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								<p>
									Specifies the GDPR related attributes
								</p>
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.7</a:since>
                                <a:displayName>AbstractRoleType.dataProtection</a:displayName>
							</xsd:appinfo>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="autoassign" type="tns:AutoassignSpecificationType" minOccurs="0">
		               <xsd:annotation>
		                   <xsd:documentation>
		                   		<p>
			                       Specification of role autoassignmnt properties. Those properties
			                       are evaluated to detect whether a role should be automatically
			                       assigned to focus.
		                       </p>
		                   </xsd:documentation>
		               </xsd:annotation>
		           </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="abstractRole" type="tns:AbstractRoleType"/>

	<xsd:simpleType name="IdempotenceType">
        <xsd:annotation>
            <xsd:documentation>
                This value indicates, whether the evaluation of this role gives the
       			same results regardless of its position in the assignment/inducement
       			hierarchy. I.e. evaluation of this roles does not depend on the assignment
       			parameters of focus or any of the preceding roles. This flag is used
       			to enable aggresive caching of role evaluation, so idempotent roles
       			are only evaluated once regardless of their position in the hierarchy
       			as we can assume that any subsequent eveluation will produce exactly
       			the same results as the first evaluation. This is a very important
       			feature that allows efficient evaluation of big role hierarchies.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        Role is not idempotent. The role must be evaluated for all situations:
                        all assignment paths, all orders, etc. 
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="conservative">
                <xsd:annotation>
                    <xsd:documentation>
                        This value indicates, that the evaluation of this role gives the
               			same results regardless of its position in the assignment/inducement
               			hierarchy. I.e. evaluation of this roles does not depend on the assignment
               			parameters of focus or any of the preceding roles. However, the role
               			will still be re-evaluated if it is found with assignment path of
               			different depths or orders (e.g. in meta-role situations).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CONSERVATIVE"/>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="aggressive">
                <xsd:annotation>
                    <xsd:documentation>
                        This value indicates, that the evaluation of this role gives the
               			same results regardless of its position in the assignment/inducement
               			hierarchy including different path lengths and evaluation orders. 
               			I.e. evaluation of this roles does not depend on the assignment
               			parameters of focus or any of the preceding roles and it has no
               			meta-role capability (e.g. higher-order inducements).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AGGRESSIVE"/>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
     <xsd:complexType name="DataProtectionType">
     	<xsd:annotation>
     		<xsd:documentation>
     			<p>
     				Container which specify legal content for the role related to the GDPR.
     				E.g which law enforce the presence of the attribute, who is a recipient 
     				of the data, to which purposes are data used etc.
     			</p>
     		</xsd:documentation>
     		<xsd:appinfo>
     			<a:container/>
     			<a:since>3.7</a:since>
     		</xsd:appinfo>
     	</xsd:annotation>
     	<xsd:sequence>
     		<xsd:element name="controllerName" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					Name of the company, organization which controls data processing
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.controllerName</a:displayName>
		               	<a:displayOrder>100</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="controllerContact" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					Contact information about company, organization which controls data processing
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.controllerContact</a:displayName>
		               	<a:displayOrder>110</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="dpoContact" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					Contact information for data privacy oficier
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.dpoContact</a:displayName>
		               	<a:displayOrder>120</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="processingPurposesDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
     						Purposes for processing, e.g marketing, contract,...
     					</p>
     					<p>
     						This is a free-form field that can be used to describe data processing
     						purposes in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.processingPurposesDescription</a:displayName>
		               	<a:displayOrder>130</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="legitimateInterestDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
	     					Legitimate interest for data processing. This may be a legislation that allows
	     					data processing, consent or other lawful basis.
     					</p>
     					<p>
     						This is a free-form field that can be used to describe legitimate
     						interests in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.legitimateInterestDescription</a:displayName>
		               	<a:displayOrder>140</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="dataRecipientDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
	     					Contains information about recipient of the data.
     					</p>
     					<p>
     						This is a free-form field that can be used to describe recipients
     						in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.dataRecipientDescription</a:displayName>
		               	<a:displayOrder>150</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="periodOfStorageDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
	     					How long we need to store the data (e.g after the employee left the organization)
     					</p>
     					<p>
     						This is a free-form field that can be used to describe storage period
     						in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.periodOfStorageDescription</a:displayName>
		               	<a:displayOrder>160</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="dataErasureDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
	     					Desription of data erasure practices, especially the period for data erasure.
     					</p>
     					<p>
     						This is a free-form field that can be used to describe data erasure
     						in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.dataErasureDescription</a:displayName>
		               	<a:displayOrder>170</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="automatedDecisionMakingDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
     						Description whether automated decision making (e.g. profilig) is part of the
     						data processing.
     					</p>
     					<p>
     						This is a free-form field that can be used to describe automated decision making
     						in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.automatedDecisionMakingDescription</a:displayName>
		               	<a:displayOrder>180</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="securityMeasuresDescription" type="xsd:string" minOccurs="0">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
     						Description of the security measures that apply to data processing
     						(e.g. pseudonymization, confidentiality, ...)
     					</p>
     					<p>
     						This is a free-form field that can be used to describe security measures
     						in a human-readable form suitable to be displayed to user.
     						This is NOT structured information. Structurted information schema
     						is planned for future midPoint releases.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>DataProtectionType.securityMeasuresDescription</a:displayName>
		               	<a:displayOrder>190</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     	</xsd:sequence>
     </xsd:complexType>
     
     <xsd:complexType name="AutoassignSpecificationType">
     	<xsd:annotation>
     		<xsd:documentation>
     			<p>
     				Specification of role autoassignmnt properties. Those properties
                    are evaluated to detect whether a role should be automatically
                    assigned to focus.
     			</p>
     		</xsd:documentation>
     		<xsd:appinfo>
     			<a:container/>
     			<a:since>3.7</a:since>
     		</xsd:appinfo>
     	</xsd:annotation>
     	<xsd:sequence>
     		<xsd:element name="enabled" type="xsd:boolean" minOccurs="0" default="false">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
	     					Flag indicating whether autoassign functionality is enabled for this
	     					(abstract) role.
     					</p>
     					<p>
     						Use with care. MidPoint will will have to process all the roles that
     						have this flag set to true. All the roles will be looked up, autoassign
     						specification will be processed to see if the focus is matching.
     						This will happen all the time for all modification operations.
     						Therefore it is disabled by default. Also, autoassign functionality
     						needs to be globally enabled in system configuration.
     					</p>
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>AutoassignSpecificationType.enabled</a:displayName>
		               	<a:displayOrder>100</a:displayOrder>
		               	<a:indexed>true</a:indexed>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<xsd:element name="focus" type="tns:FocalAutoassignSpecificationType" minOccurs="0" maxOccurs="1">
     			<xsd:annotation>
     				<xsd:documentation>
     					This is "focal" specification. It is applied on the focus (similarly to object template).
     				</xsd:documentation>
     				<xsd:appinfo>
		               	<a:displayName>AutoassignSpecificationType.focus</a:displayName>
		               	<a:displayOrder>110</a:displayOrder>
		            </xsd:appinfo>
     			</xsd:annotation>
     		</xsd:element>
     		<!-- TODO: later: inbound -->
     	</xsd:sequence>
    </xsd:complexType>

     <xsd:complexType name="FocalAutoassignSpecificationType">
     	<xsd:annotation>
     		<xsd:documentation>
     			<p>
     				Specification of role autoassignmnt properties. Those properties
                    are evaluated to detect whether a role should be automatically
                    assigned to focus.
                    This is "focal" specification. It is applied on the focus (similarly
                    to object template).
     			</p>
     		</xsd:documentation>
     		<xsd:appinfo>
     			<a:container/>
     			<a:since>3.7</a:since>
     		</xsd:appinfo>
     	</xsd:annotation>
     	<xsd:sequence>
     		<xsd:element name="mapping" type="tns:AutoassignMappingType" minOccurs="0" maxOccurs="unbounded">
     			<xsd:annotation>
     				<xsd:documentation>
     					<p>
     						Mapping that decides whether the roles has to be assigned.
     						The mapping is supposed to produce an assignment for this role.
     						However, the assignment is fed as a default source to the
     						mapping. Therefore all that the mapping usually needs is to
     						specify the condition. However, mapping expression can still be
     						used to manipulate content of the assignment.
     					</p>
     					<p>
     						This is mostly equivalent to the object tempate mapping, but default
     						target is set to the assignment of this role.
     					</p>
     				</xsd:documentation>
     			</xsd:annotation>
     		</xsd:element>
     		<!-- TODO: later: mapping is too flexible. It is will be difficult for the
     		     role managers to be set from GUI. But we can support most of the policy rule
     		     constraints here (PolicyConstraintsType). -->
     	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="AutoassignMappingType">
    	<xsd:annotation>
    		<xsd:appinfo>
    			<a:container/>
    			<a:since>3.7</a:since>
    		</xsd:appinfo>
    	</xsd:annotation>
    	<xsd:complexContent>
    		<xsd:extension base="tns:MappingType">
    			<xsd:sequence>
    				<xsd:element name="assignmentProperties" type="tns:AssignmentPropertiesSpecificationType" minOccurs="0">
    					<xsd:annotation>
    						<xsd:documentation>
    							Properties of the new assignment.
    						</xsd:documentation>
    					</xsd:annotation>
    				</xsd:element>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="AssignmentPropertiesSpecificationType">
    	<xsd:annotation>
    		<xsd:appinfo>
    			<a:container/>
    			<a:since>3.7</a:since>
    		</xsd:appinfo>
    	</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="relation" type="xsd:QName" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Relation that will be set for new assignment.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<!-- TODO: later: activation, lifecycle -->
		</xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AuthorizationType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                	Authorization define fine-grained access to midPoint objects and system functionality.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0"/>
        	<xsd:element ref="tns:description" minOccurs="0"/>
        	<xsd:element name="decision" minOccurs="0" type="tns:AuthorizationDecisionType" default="allow">
        		<xsd:annotation>
        			<xsd:documentation>
        				<p>
        					Decision that this authorization specifies. If the decision is "allow" (which is the
        					default) then this authorization allows access. If the decision is "deny" then this
        					authorization denies access. Denial is a final decisions. If at least one applicable
        					authorization denies access then the access is always denied, regadless of any other
        					allow authorizations.
        				</p>
        				<p>
	        				Note: there is subtle (but important) difference between not allowing access and
	        				denying access. Authorization that denies access specifies a final decision. Denied
	        				access cannot be allowed by any other authorization. Deny authorization are very
	        				strong from a security perspective, but it is extremely difficult to combine them
	        				with other authorizations. Therefore deny authorizations are used very rarely.
	        				On the other hand if the access is not allowed by a specific authorization then
	        				it can still be allowed by another authorization. This makes authorizations "mergeable".
	        				Not allowing access is usually the right approach.
        				</p>
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="action" type="xsd:anyURI" minOccurs="1" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				Action part from the (subject,action,object) authorization triple. It is an URL to allow extension.
        				Multiple actions may be specified. In that case the authorization applies to all of them.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="phase" type="tns:AuthorizationPhaseType" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Specifies when to conduct authorizationa and what exactly to authorize.
        				If no phase is specified then the authorization applies to all phases.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="enforcementStrategy" type="tns:AuthorizationEnforcementStrategyType" minOccurs="0" maxOccurs="1" default="alwaysEnforce">
        		<xsd:annotation>
        			<xsd:documentation>
        				Setting that specifies when to enforce the authorization.
        				Default setting is to always enforce the authorization.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.6</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="object" type="tns:OwnedObjectSelectorType" minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				Object part from the (subject,action,object) authorization triple.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="item" type="t:ItemPathType"  minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				<p>
	        				Specification of items that form a scope of this authorization. This autorization will
	        				only affect the items specified in this element. If no items are specified then the
	        				authorization applies to all items in the objects.
        				</p>
        				<p>
        					The item specification must not be combined with exceptItem. One or the other can be
        					used, but not both. If neither item nor exceptItem is specified then it is assumed
        					that the authorization applies to all items.
        				</p>
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="exceptItem" type="t:ItemPathType"  minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				<p>
	        				Specification of items that are excluded from the scope of this authorization.
	        				I.e. the authorization applies to all the items except those items that are
	        				specified here.
        				</p>
        				<p>
	        				Note: there is subtle (but important) difference between not allowing access and
	        				denying access. Authorization that denies access specifies a final decision. Denied
	        				access cannot be allowed by any other authorization. Deny authorization are very
	        				strong from a security perspective, but it is extremely difficult to combine them
	        				with other authorizations. Therefore deny authorizations are used very rarely.
	        				On the other hand if the access is not allowed by a specific authorization then
	        				it can still be allowed by another authorization. This makes authorizations "mergeable".
	        				Not allowing access is usually the right approach.
	        				The exceptItem specification is a convenient way to "not allow" access to specific
	        				items.
        				</p>
        				<p>
        					The item specification must not be combined with exceptItem. One or the other can be
        					used, but not both. If neither item nor exceptItem is specified then it is assumed
        					that the authorization applies to all items.
        				</p>
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.7.1</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="target" type="tns:OwnedObjectSelectorType" minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				Target of the operation. E.g. an role that is being assigned. It can be considered an operation
        				parameter. If no target is specified then the authorization applies to all possible targets.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="relation" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
	   			<xsd:annotation>
    				<xsd:documentation>
    					Relation(s) to which the authorization applies.
    					This is applicable only to some authorizations, mostly those that
    					create new object references (e.g. assign/unassign authorizations).
    					If left empty it applies to all relations.
    				</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.7</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
    		</xsd:element>
        	<xsd:element name="limitations" type="tns:AuthorizationLimitationsType" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Limitations of this authorization when it is applied to other authorizations.
        				For example this specification may limit the power of attorney.
        				It is only applicable to some authorization types.
        			</xsd:documentation>
        			<xsd:appinfo>
        				<a:since>3.7</a:since>
        			</xsd:appinfo>
        		</xsd:annotation>
        	</xsd:element>
        	<!-- TODO: more elements will be added in the future: condition, parameters -->
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>
		
	<xsd:simpleType name="AuthorizationDecisionType">
        <xsd:annotation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="allow">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALLOW"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="deny">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DENY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="AuthorizationPhaseType">
        <xsd:annotation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="request">
                <xsd:annotation>
                	<xsd:documentation>
                		Authorize the requested operations. I.e. the authorization happens
                		at the beginning of request processing. 
                		The request may be spread to many other oprations but in this case
                		only the explicitly requested set is authorized.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REQUEST"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="execution">
                <xsd:annotation>
                	<xsd:documentation>
                		Authorize the executed operations. I.e. the authorization happens
                		at the end of request processing. 
                		The request may be spread to many other oprations but in this case
                		all the requested and computed operations are authorized.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXECUTION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="AuthorizationEnforcementStrategyType">
        <xsd:annotation>
        	<xsd:documentation>
        		Limitations of this authotization when it is applied to other authorizations.
   				For example this specification may limit the power of attorney.
        	</xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="alwaysEnforce">
                <xsd:annotation>
                	<xsd:documentation>
                		The authorization will always be enforced for all applicable operations.
                		Even at the cost of running inefficient operation. If the authorization
                		cannot be enforced then the operation results in an error. We would rather
                		stop the operation entirelly than risking data exposure.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALWAYS_ENFORCE"/>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="maySkipOnSearch">
                <xsd:annotation>
                	<xsd:documentation>
                	    If this setting is applied then midPoint may skip this authorization during evaluation
                	    of search operation. This is used for authorization that may be inefficient to evaluate
                	    for search operations, especially when used in situations where there is another broader
                	    authorization which is good enough to limit the seach results.
        				Setting this strategy may cause that broader search results are returned. Use with care.
        				This setting influences search operations only. It does not influence other operations, 
        				such as read, modify or assign.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAY_SKIP_ON_SEARCH"/>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="AuthorizationLimitationsType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                	Limitations of this authorization when it is applied to other authorizations.
      				For example this specification may limit the power of attorney.
       				It is only applicable to some authorization types.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="action" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded">
        		<xsd:annotation>
        			<xsd:documentation>
        				Limitation of action. If any action is specified then the authorization
        				is limited only to those actions.
        				E.g. if this is applied to attorney authorization then only those
        				actions from the object are considere to be delegated to attorney.
        				Actions that are not part of this list are not delegated.
        				If the list is empty then there is no limitation. All actions
        				are delegated.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<!-- Those limitations may come in the future:
        	<xsd:element name="object" type="tns:OwnedObjectSelectorType" minOccurs="0" maxOccurs="unbounded">
        	</xsd:element>
        	<xsd:element name="item" type="t:ItemPathType"  minOccurs="0" maxOccurs="unbounded">
        	</xsd:element>
        	<xsd:element name="target" type="tns:OwnedObjectSelectorType" minOccurs="0" maxOccurs="unbounded">
        	</xsd:element>  -->
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>

	<xsd:complexType name="ObjectSelectorType">
        <xsd:annotation>
            <xsd:documentation>
                Selects some objects from all the objects in midPoint.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:description" minOccurs="0"/>
        	<xsd:element name="type" minOccurs="0" type="xsd:QName">
        		<xsd:annotation>
        			<xsd:documentation>
        				Type of the object to select.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="subtype" minOccurs="0" type="xsd:string">
        		<xsd:annotation>
        			<xsd:documentation>
        				Subtype of the object to select.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
			<xsd:element name="orgRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                        	Top node of an organizational hierarchy. This node and all of its subnodes
                        	(transitively, unlimited depth) are considered selected.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
            			<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
            		</xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        	<xsd:element name="filter" type="q:SearchFilterType" minOccurs="0" maxOccurs="1">
        		<xsd:annotation>
        			<xsd:documentation>
        				Filter that an object must match to be considered selected by this statement.
        				This filter MUST NOT containt organization unit clauses. It may only contain
        				property clauses, logical operations and so on.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>

	<xsd:complexType name="SubjectedObjectSelectorType">
        <xsd:annotation>
            <xsd:documentation>
                Selects some objects from all the objects in midPoint.
                This is an extension of ObjectSelectorType that adds
                criteria that relate objects to a specific subject
                (logged-in user).
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ObjectSelectorType">
		        <xsd:sequence>
					<xsd:element name="orgRelation" type="tns:OrgRelationObjectSpecificationType" minOccurs="0" maxOccurs="1">
		                <xsd:annotation>
		                    <xsd:documentation>
		                        <p>
		                        	Definition of object with respect to subject membership in organizational hierarchy.
		                        	Used to specify authorizations for all objects that belong to an org where the subject a manager, etc.
		                        </p>
		                    </xsd:documentation>
		                    <xsd:appinfo>
				                <a:since>3.4</a:since>
				            </xsd:appinfo>
		                </xsd:annotation>
		            </xsd:element>
		        	<xsd:element name="roleRelation" type="tns:RoleRelationObjectSpecificationType" minOccurs="0" maxOccurs="1">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				<p>
		                        	Definition of object with respect to subject relation to a role.
		                        	Used to specify authorizations for role approvers, owners and so on.
		                        </p>
		                        <p>
		                        	EXPERIMENTAL. Use at your own risk.
		                        </p>
		        			</xsd:documentation>
		        			<xsd:appinfo>
		        				<a:since>3.6</a:since>
		        			</xsd:appinfo>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="special" type="tns:SpecialObjectSpecificationType" minOccurs="0" maxOccurs="unbounded">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				Defines special object by relative description, such as "self".
		        			</xsd:documentation>
		        		</xsd:annotation>
		        	</xsd:element>
		        	<xsd:element name="allowInactive" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
		        		<xsd:annotation>
		        			<xsd:documentation>
		        				If set to false (defaul) the specification will apply only to active relations
		        				(e.g active delegations). If set to true then the specificaiton will also be applied 
		        				to inactive relations (e.g. expired delegations).
		        				Only partially implemented. Works only for some cases (delegator).
		        				EXPERIMENTAL. Use at your own risk.
		        			</xsd:documentation>
		        			<xsd:appinfo>
		        				<a:since>3.6.1</a:since>
		        			</xsd:appinfo>
		        		</xsd:annotation>
		        	</xsd:element>
		        </xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
	</xsd:complexType>

	
	<xsd:complexType name="OwnedObjectSelectorType">
        <xsd:annotation>
            <xsd:documentation>
                Selects some objects from all the objects in midPoint.
                This is an extension of SubjectedObjectSelectorType that adds
                criteria that for objects that can be owned (resource objects, roles, etc.)
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:SubjectedObjectSelectorType">
		        <xsd:sequence>
			        <xsd:element name="owner" type="tns:SubjectedObjectSelectorType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								The object matches the specification if it has an owner specified by this element.
								The "owner" means a focus that has a link to the object.
							</xsd:documentation>
						</xsd:annotation>
			        </xsd:element>
			        <xsd:element name="delegator" type="tns:SubjectedObjectSelectorType" minOccurs="0" maxOccurs="1">
						<xsd:annotation>
							<xsd:documentation>
								The object matches the specification if it has a delegator specified by this element.
								The "delegator" means that the object has an active delegation assignment to delegator.
								
								LIMITATION: only "self" delegator is supported now.
							</xsd:documentation>
							<xsd:appinfo>
								<a:since>3.6</a:since>
							</xsd:appinfo>
						</xsd:annotation>
			        </xsd:element>
		        </xsd:sequence>        	
        	</xsd:extension>
        </xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="AssignmentSelectorType">
        <xsd:annotation>
            <xsd:documentation>
                Selects some assignments from all the assignments in the object.
                E.g. may be used to select only some assignments/inducements for a role.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:description" minOccurs="0"/>
        	<xsd:element name="targetRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
               <xsd:annotation>
                   <xsd:documentation>
                       Selects assignments that have this target reference.
                       (Target OID, type and relation is matched.)
                       Note: Filter in the reference is not yet supported.
                   </xsd:documentation>
               </xsd:annotation>
           </xsd:element>
           <xsd:element name="allowTransitive" type="xsd:boolean" minOccurs="0" default="false">
				<xsd:annotation>
					<xsd:documentation>
						If set to true then transitive processing is enabled. E.g. transitive deputy
						delegations (deputy of a deputy) will be processed.
						If set to false then transitive processing is disabled. E.g. transitive
						deputy delegations will be ignored.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>
	
	<xsd:complexType name="OtherPrivilegesLimitationType">
        <xsd:annotation>
            <xsd:documentation>
				Limitations related to other privileges, like the ability to complete work items.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
				<a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
			<xsd:element name="approvalWorkItems" type="c:WorkItemSelectorType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Selects approval work items access to which will be delegated. If not present, access to these work items is NOT delegated.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="certificationWorkItems" type="c:WorkItemSelectorType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Selects certification work items access to which will be delegated. If not present, access to these work items is NOT delegated.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="caseManagementWorkItems" type="c:WorkItemSelectorType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Selects case management work items access to which will be delegated. If not present, access to these work items is NOT delegated.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>

	<xsd:complexType name="WorkItemSelectorType">
		<xsd:annotation>
			<xsd:documentation>
				Selects some work items from all the items (perhaps of a given type, like approval work items).
				E.g. may be used to delegate access to some work items only.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
				<a:since>3.6</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element ref="tns:description" minOccurs="0"/>
			<xsd:element name="all" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						True if all work items should be selected.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<!-- TODO finer specification of work items to allow access to -->
		</xsd:sequence>
		<xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>

	<xsd:complexType name="OrgRelationObjectSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of object with respect to subject membership in organizational hierarchy.
                Used to specify authorizations for all objects that belong to an org where the subject a manager, etc.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.4</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="subjectRelation" minOccurs="0" type="xsd:QName">
        		<xsd:annotation>
        			<xsd:documentation>
        				Specifies the relation that the subject needs to have to the org for this condition to
        				trigger. This is usually null (memeber) realtion or manager relation.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="scope" type="tns:OrgScopeType" minOccurs="0" maxOccurs="1" default="allDescendants">
	        	<xsd:annotation>
        			<xsd:documentation>
        				Scope of application that will be used to select objects relative to the reference node.
        				It determines which objects will be selected (those above or below the refence node, shallow or deep, etc.)
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="includeReferenceOrg" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				If set to true then the reference org (the one which the subjects belongs to) is included
        				in the scope.
        				If set to false then the reference org is excluded from the scope. 
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>
	
	<xsd:complexType name="RoleRelationObjectSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                	Definition of object with respect to subject relation to a role.
                	Used to specify authorizations for role approvers, owners and so on.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="subjectRelation" minOccurs="0" type="xsd:QName">
        		<xsd:annotation>
        			<xsd:documentation>
        				Specifies the relation that the subject needs to have to the role for this condition to
        				trigger. This is usually approver or owner.
        				If not specified then any relation is accepted.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="objectRelation" minOccurs="0" maxOccurs="1" type="xsd:QName">
        		<xsd:annotation>
        			<xsd:documentation>
        				Specifies the relation that the target needs to have to the role for this condition to
        				trigger. This is usually default relation (member).
        				If not specified then any relation is accepted.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="includeMembers" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="true">
        		<xsd:annotation>
        			<xsd:documentation>
        				If set to true then the members of reference role (the one which the subjects belongs to) 
        				are included in the scope (limited by objectRelation).
        				If set to false then the members of reference role is excluded from the scope 
        				(objectRelation is not used in this case).
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="includeReferenceRole" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
        		<xsd:annotation>
        			<xsd:documentation>
        				If set to true then the reference role (the one which the subjects belongs to) is included
        				in the scope.
        				If set to false then the reference role is excluded from the scope. 
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>
	
	
	    <xsd:simpleType name="OrgScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Defines applicability scope in the organizational structures. 
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.4</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="directDescendants">
                <xsd:annotation>
                	<xsd:documentation>
                		Direct descendants of the reference node. I.e. all the nodes
                		that are exactly one level below.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DIRECT_DESCENDANTS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="allDescendants">
                <xsd:annotation>
                	<xsd:documentation>
                		All descendants of the reference node, including descendants of descendants.
                		I.e. all the nodes that are one or more levels below.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL_DESCENDANTS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="allAncestors">
                <xsd:annotation>
                	<xsd:documentation>
                		All ancestors of the reference node, including ancestors of ancestors.
                		I.e. all the nodes that are on any path between the refernce node and the
                		root node.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL_ANCESTORS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="none">
                <xsd:annotation>
                	<xsd:documentation>
                		No objects belong to the scope. Used in conjuction with
                		includeReferenceOrg option to target only the reference node
                		and no other node in the hierarchy.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
    	</xsd:restriction>
    </xsd:simpleType>
	

	<xsd:simpleType name="SpecialObjectSpecificationType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specification used to select special cases that are usually context-relative.
        	</xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="self">
                <xsd:annotation>
                    <xsd:appinfo>
                    	<xsd:documentation>
                    		Object that represents itself. This usually represents an
                    		object that corresponds to a currently logged-in user.
                    		E.g. it may be used to allow each user to change his own password.
                    	</xsd:documentation>
                        <jaxb:typesafeEnumMember name="SELF"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="RoleType">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	                A role in the extended Role-Based Access Control (RBAC) sense.
	                The roles specify privileges that the user (or other object) should have.
                </p>
                <p>
	                The role may "grant" accounts on resources, attributes and
	                entitlements for such accounts. The role can also assign
	                organizational units, other roles or various IDM objects
	                that can be assigned directly to user. From this point of
	                view the role is in fact just a named set of assignments.
                </p>
				<p>
	                The roles form the basic building block of midPoint's extended
	                role-based access control (RBAC) mechanism. It defines what
	                rights (e.g. accounts) should be given to user, how they
	                should look like (attributes) and what groups or native
	                roles to assign to them (entitlements).
                </p>
                <p>
                	Roles can also specify user authorizations to access specific
                	parts of midPoint. This is used to implement fine-grained authorization
                	mechanism. When combined with organizational structure it forms a
                	delegated administration mechanism.
                </p>
                <p>
                	Roles can also be conditional, i.e. applicable only if a specific
                	condition is true. Roles can be parametric, e.g. the expressions
                	inside the role can use parameters that were specified at the time
                	when the role was assigned (as opposed to parameters defined when
                	the role was defined).
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractRoleType">
                <xsd:sequence>
                    <xsd:element name="roleType" type="xsd:string" minOccurs="0">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			<p>
                    				Type of a role, usually denotes a "layer" or "purpose" of the role.
                    				Such as "business", "IT", "asset", etc.
                    				This field has no special meaning in the IDM computation logic. Its purpose
                    				is to organize roles for presentation (GUI) and management. Therefor it is
                    				assumed that the values of the roleType will be an enumeration.
                    			</p> 
                    			<p>
                    				In a complex RBAC structures the role type is usually defined by an
                    				assignment of a meta-role. However, selecting the roles by (sometimes transitive)
                    				meta-role assignment is not very efficient. Therefore the recommended
                    				use is for a meta-role to set the value of (focal) role roleType property to
                    				a simple string value (focusMapping in a meta-role is ideal for this purpose).
                    				The roleType property should also be associated with a LookupTable (or similar mechanism)
                    				to allow GUI to efficiently display and select role types.
                    			</p>
                    			<p>
                                Examples:
                                    <ul>
                                        <li>application</li>
                                        <li>business</li>
                                        <li>it</li>
                                        <li>technical</li>
                                        <li>asset</li>
                                    </ul>
                                </p>
                    		</xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>RoleType.roleType</a:displayName>
                            </xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="role" type="tns:RoleType" substitutionGroup="tns:object"/>

    <xsd:element name="approverRef" type="tns:ObjectReferenceType" />
    
    <xsd:complexType name="AbstractConstructionType" abstract="true">
       <xsd:annotation>
       		<xsd:documentation>
       			Abstract supertype for constructions.
       		</xsd:documentation>
		   <xsd:appinfo>
			   <a:container/>
		   </xsd:appinfo>
	   </xsd:annotation>
        <xsd:sequence>
           <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
           		<xsd:annotation>
                   <xsd:appinfo>
					<a:displayName>AbstractConstructionType.description</a:displayName>
                   </xsd:appinfo>
               </xsd:annotation>
           </xsd:element>
           <xsd:element name="strength" type="tns:ConstructionStrengthType" minOccurs="0" maxOccurs="1" default="strong">
               <xsd:annotation>
                   <xsd:documentation>
                       Strength of the construction defines how aggressively will
	                	the construction be applied. Strong constructions are applied
    	            	all the time (relative changes, reconciliation, ...).
        	        	Weak constructions are applied only if there is another
            	    	strong construction.
                   </xsd:documentation>
                   <xsd:appinfo>
					<a:since>3.5</a:since>
					<a:displayName>AbstractConstructionType.strength</a:displayName>
					<a:help>AbstractConstructionType.strength.help</a:help>
                   </xsd:appinfo>
               </xsd:annotation>
           </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ConstructionType">
       <xsd:annotation>
       		<xsd:documentation>
       			Projection construction. This structure defines how a projection
                (e.g. account) should be constructed.
       		</xsd:documentation>
		   <xsd:appinfo>
			   <a:container/>
		   </xsd:appinfo>
	   </xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractConstructionType">
				<xsd:sequence>
					 <xsd:element ref="c:extension" minOccurs="0" maxOccurs="1"/>
					 <xsd:choice>
					     <xsd:element name="resourceRef" type="c:ObjectReferenceType" minOccurs="0">
					         <xsd:annotation>
					             <xsd:documentation>
					                 Reference to a resource that should host the implied account.
					             </xsd:documentation>
					             <xsd:appinfo>
					         		<a:objectReferenceTargetType>tns:ResourceType</a:objectReferenceTargetType>
					         	</xsd:appinfo>
					         </xsd:annotation>
					     </xsd:element>
					     <xsd:element name="resource" type="tns:ResourceType" minOccurs="0">
					         <xsd:annotation>
					             <xsd:documentation>
					                 Resource that should host the implied resource object.
					             </xsd:documentation>
					             <xsd:appinfo>
					         		<a:objectReference>tns:resourceRef</a:objectReference>
					         	</xsd:appinfo>
					         </xsd:annotation>
					     </xsd:element>
					 </xsd:choice>
					 <xsd:choice>
					     <xsd:element name="kind" type="tns:ShadowKindType" minOccurs="0" default="account">
					         <xsd:annotation>
					             <xsd:documentation>
					                 Kind of resource object that should be created on the resource.
					
					                 This element is optional. If not specified defaults to account kind.
					             </xsd:documentation>
					             <xsd:appinfo>
					             	<a:displayName>ConstructionType.kind</a:displayName>
					             	<a:help>ConstructionType.kind.help</a:help>
					             </xsd:appinfo>
					         </xsd:annotation>
					     </xsd:element>
					 </xsd:choice>
					 <xsd:choice>
					     <xsd:element name="intent" type="xsd:string" minOccurs="0">
					         <xsd:annotation>
					             <xsd:documentation>
					                 Intent of resource object that should be created on the resource.
					
					                 This must point to the a valid definition in
					                 the resource object (in schemaHandling section).
					
					                 This element is optional. If not specified then the definition
					                 marked as default in the resource definition should be used.
					             </xsd:documentation>
					             <xsd:appinfo>
					             	<a:displayName>ConstructionType.intent</a:displayName>
					             	<a:help>ConstructionType.intent.help</a:help>
					             </xsd:appinfo>
					         </xsd:annotation>
					     </xsd:element>
					 </xsd:choice>
					 <xsd:element name="attribute" type="tns:ResourceAttributeDefinitionType" minOccurs="0" maxOccurs="unbounded">
					     <xsd:annotation>
					         <xsd:documentation>
					             Resource object attribute values implied by this role.
					             When the role is assigned the attributes specified
					             below should be assigned values specified below.
					         </xsd:documentation>
					     </xsd:annotation>
					 </xsd:element>
					 <xsd:element name="association" type="tns:ResourceObjectAssociationType" minOccurs="0" maxOccurs="unbounded"/>
					 <xsd:element name="auxiliaryObjectClass" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
					    <xsd:annotation>
					        <xsd:documentation>
					            The reference to additional type definitions for this object. These auxiliary object
					            classes will be added to the resource object when the construction is provisioned. 
					            
					            The reference should
					            point to object class definition (complex type definition in resource schema) and
					            this definition should be marked as auxiliary.
					        </xsd:documentation>
				             <xsd:appinfo>
				             	<a:displayName>ConstructionType.auxiliaryObjectClass</a:displayName>
				             	<a:help>ConstructionType.auxiliaryObjectClass.help</a:help>
				             </xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>
			   </xsd:sequence>
	   		</xsd:extension>
		</xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="construction" type="tns:ConstructionType"/>
    
    <xsd:simpleType name="ConstructionStrengthType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                	Strength of the construction defines how aggressively will
                	the construction be applied. Strong constructions are applied
                	all the time (relative changes, reconciliation, ...).
                	Weak constructions are applied only if there is another
                	strong construction.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="strong">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Always applied, regardless of context.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="STRONG"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="weak">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Construction is applied only if there is another
                			strong construction for the same project. I.e.
                			weak construction do not entitle the focus to anything
                			just by themselves. There must be another reason for the
                			projection to exist. If there is, then the weak construction
                			will be also applied. If it is not then the weak construction
                			is ignored.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WEAK"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="PersonaConstructionType">
       <xsd:annotation>
       		<xsd:documentation>
       			Persona construction. This structure defines how a persona
                (e.g. virtual identity) should be constructed.
       		</xsd:documentation>
		   <xsd:appinfo>
			   <a:container/>
			   <a:since>3.6</a:since>
		   </xsd:appinfo>
	   </xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractConstructionType">
				<xsd:sequence>
			            <xsd:element name="targetType" type="xsd:QName" minOccurs="1">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Object type of the target persona (e.g. UserType).
			                    </xsd:documentation>
			                    <xsd:appinfo>
			                    	<a:since>3.6</a:since>
			                	</xsd:appinfo>
			                </xsd:annotation>
			            </xsd:element>
			            <xsd:element name="targetSubtype" type="xsd:string" minOccurs="1" maxOccurs="unbounded">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Object subtype of the target persona.
			                        Constructions with the same type and substype configuraton are
			                        interpretes as if they describe the same persona.
			                    </xsd:documentation>
			                    <xsd:appinfo>
			                    	<a:since>3.6</a:since>
			                	</xsd:appinfo>
			                </xsd:annotation>
			            </xsd:element>
			            <xsd:element name="objectMappingRef" type="c:ObjectReferenceType" minOccurs="0">
			                <xsd:annotation>
			                    <xsd:documentation>
			                        Reference to the object template that will be used to map values
			                        from the source object (e.g. physical user) to the persona 
			                        (e.g. virtual identity user).
			                        Unlike ordinary object template that has the same object as input and
			                        output, this object mapping will have one object as an input and the
			                        other as an output.
			                    </xsd:documentation>
			                    <xsd:appinfo>
			                		<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
			                	</xsd:appinfo>
			                </xsd:annotation>
			            </xsd:element>
			        </xsd:sequence>
				</xsd:extension>
			</xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ObjectTemplateType">
        <xsd:annotation>
            <xsd:documentation>
            	TODO: update
                The user template used to create new users. It
                contains fixed values or expressions that can set-up
                a new user obejct. It is used only during user creation in the
                synchronization code, but will be most likely used also
                on other places later.

                The goal is to make this a kind of "policy" how the use object
                should look like and check it on every user modification.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                	<xsd:element name="includeRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
                		<xsd:annotation>
                			<xsd:documentation>
                				Included template. All the mappings of the included template are processed as if they
                				were directly placed in this template.
                			</xsd:documentation>
                			<xsd:appinfo>
                				<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                			</xsd:appinfo>
                		</xsd:annotation>
                	</xsd:element>
                	<xsd:element name="iteration" type="tns:IterationSpecificationType" minOccurs="0"/>
                	<xsd:element name="item" type="tns:ObjectTemplateItemDefinitionType" minOccurs="0"
                                 maxOccurs="unbounded"/>
                    <xsd:element name="mapping" type="tns:ObjectTemplateMappingType" minOccurs="0"
                                 maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Defines how any of the User's properties should
                                be constructed. It can contain fixed value or
                                an expression.

                                In case an expression is used following variables should be set:
                                $user - The user object being created.
                                $account - (optional) the account from which was the user created (if present)

                                Note: the expressions will be evaluated in the order as
                                they are specified in the XML file for now, as the dependency
                                mechanism does not work yet. Later, the order should be insignificant.
                                
                                DEPRECATED. Use "item" mechanism instead.
                            </xsd:documentation>
							<xsd:appinfo>
								<a:deprecated>true</a:deprecated>
							</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
	<xsd:element name="userTemplate" type="tns:ObjectTemplateType" substitutionGroup="c:object">
		<xsd:annotation>
			<xsd:appinfo>
				<a:deprecated>true</a:deprecated>
			</xsd:appinfo>
		</xsd:annotation>
	</xsd:element>
	<xsd:element name="objectTemplate" type="tns:ObjectTemplateType" substitutionGroup="c:object"/>
    
    <xsd:complexType name="ObjectTemplateItemDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
            	TODO
            	
                Description of the common item handling details, such as display name,
                read/write access and value and synchronization expressions.
                These are the parts that are common to both attributes and associations.
                
                This is supposed to be used in schemaHandling part and therefore
                describe the decisions of the system administrator about the
                way how that attribute or association is used in midPoint.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:ItemRefinedDefinitionType">
        		<xsd:sequence>
	            <xsd:element name="mapping" type="tns:ObjectTemplateMappingType" minOccurs="0" maxOccurs="unbounded">
	                <xsd:annotation>
	                    <xsd:documentation>
	                        Defines how any of the object property value should
                            be constructed. It can contain fixed value or
                            an expression.

                            In case an expression is used following variables should be set:
                            $user - The user object being created.
                            $account - (optional) the account from which was the user created (if present)
	                    </xsd:documentation>
	                </xsd:annotation>
	            </xsd:element>
	        </xsd:sequence>
	      </xsd:extension>
	   </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="ObjectTemplateMappingType">
    	<xsd:annotation>
    		<xsd:appinfo>
            	<a:container/>
            </xsd:appinfo>
    	</xsd:annotation>
    	<xsd:complexContent>
    		<xsd:extension base="tns:MappingType">
    			<xsd:sequence>
    				<xsd:element name="evaluationPhase" type="tns:ObjectTemplateMappingEvaluationPhaseType" 
    								minOccurs="0" default="beforeAssignments"/>
    			</xsd:sequence>
    		</xsd:extension>
    	</xsd:complexContent>
    </xsd:complexType>
    
    <xsd:simpleType name="ObjectTemplateMappingEvaluationPhaseType">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="beforeAssignments">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="BEFORE_ASSIGNMENTS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="afterAssignments">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AFTER_ASSIGNMENTS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="OrgType">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	            	Organizational unit, division, section, object gropup, team, project or any other form of
	            	organizing things and/or people. The OrgType objects are designed to form a hierarchical
	            	organizational structure (or rather several parallel organizational structures).
            	</p>
            	<p>
            		Orgs are designed for grouping of objects. Orgs usually group users, but they can group any kind
            		of objects (roles, policies, resources, etc.) This can be used to create a flexible delegated
            		administration setup.
            	</p>
            	<p>
            		See <a href="https://wiki.evolveum.com/display/midPoint/Organizational+Structure">Organizational Structure</a>
            		in midPoint wiki for a general introduction to the concepts.
            	</p>
            	<p>
            		The OrgType is also used as a focal object for generic synchronization. In that case the Orgs can correspond
            		to LDAP OUs or groups or any similar resource objects.
            	</p>
            	<p>
	            	OrgType is also a role (RoleType). This feature may not be used for majority of
	            	OrgType instances. But it is very useful if membership in an org unit automatically
	            	grants some accounts or roles. Although roles and orgs are very similar there is one principal
	            	difference: Orgs are designed for grouping, roles are designed for flexible policy definition.
            	</p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:AbstractRoleType">
                <xsd:sequence>
                    
                    <xsd:element name="orgType" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Type of the organizational tree. It is used to distinguish what a specific
                                	Org represents. Whether it is a functional organizational unit, project, team,
                                	etc. 
                                </p>
                                <p>
                                	It is generally assumed that all Org objects in the same tree will have
                                	the same value of this property. Although this is not a strict requirement
                                	the operation in the scripting libraries and some pre-defined structures
                                	work with this assumption. 
                                </p>
                                <p>
                                Examples:
                                    <ul>
                                        <li>functional</li>
                                        <li>project</li>
                                        <li>team</li>
                                        <li>realm</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.type</a:displayName>
                                <a:displayOrder>120</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

					<xsd:element name="tenant" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Flag indicating whether this object is a tenant or not. Tenants are top-level
	                                organizational units of organizational structures that are designed to be independent
	                                of one another. It represents a "customer" is service provider environment.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.isTenant</a:displayName>
                                <a:displayOrder>130</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="costCenter" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	The name, identifier or code of the cost center that applies to this org.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.CostCenter</a:displayName>
                                <a:displayOrder>200</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="locality" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Primary locality of the org, the place where
	                                the org is usually placed, the country, city or
	                                building that it belongs to. The specific meaning
	                                and form of this property is deployment-specific.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.locality</a:displayName>
                                <a:displayOrder>210</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="mailDomain" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Domain part of RFC822 e-mail address that applies to this organization.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.mailDomain</a:displayName>
                                <a:displayOrder>220</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="displayOrder" type="xsd:int" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                The content of this property specifies an order in which the organization
	                                should be displayed relative to other organizations at the same level.
	                                Organizations will be displayed by sorting them by the values of displayOrder
	                                property (ascending). These that do not have any displayOrder annotation
	                                will be displayed last. Organizations with the same displayOrder
	                                are displayed in alphabetic order.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>OrgType.displayOrder</a:displayName>
                                <a:displayOrder>300</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="securityPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Reference to the security policy settings which will be used for this organization.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:SecurityPolicyType</a:objectReferenceTargetType>
                    			<a:displayName>OrgType.securityPolicy</a:displayName>
                                <a:displayOrder>230</a:displayOrder>
                                <a:since>3.6</a:since>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="passwordPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Reference to the password policy settings which will be used for generate/validate password for this organization.
                                	Use either securityPolicyRef or passwordPolicyRef in orgs. Do not use both at the same time. This is not supported.
                                </p>
                            	<p>
                                	DEPRECATED. Use securityPolicyRef instead.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ValuePolicyType</a:objectReferenceTargetType>
                    			<a:displayName>OrgType.passwordPolicy</a:displayName>
                                <a:displayOrder>240</a:displayOrder>
                                <a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="org" type="tns:OrgType" substitutionGroup="c:object"/>

    <xsd:complexType name="ServiceType">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	            	This object type represents any kind of abstract or concrete services or devices such as servers, virtual machines,
	            	printers, mobile devices, network nodes, application servers, applications or anything similar. The "service" is a
	            	very abstract concept.
            	</p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:AbstractRoleType">
                <xsd:sequence>
                    
                    <xsd:element name="serviceType" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                	Type of the service. It is used to distinguish what a specific
                                	Service object represents. Whether it is a server, virtual machine, network node, etc.
                                </p>
                                <p>
                                Examples:
                                    <ul>
                                        <li>server</li>
                                        <li>vm</li>
                                        <li>printer</li>
                                        <li>device</li>
                                    </ul>
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ServiceType.type</a:displayName>
                                <a:displayOrder>120</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="locality" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                Informal description of the place where the service is located. 
	                                E.g. the location where the printer is placed, the name of the
	                                datacenter, etc.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ServiceType.locality</a:displayName>
                                <a:displayOrder>210</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="displayOrder" type="xsd:int" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                The content of this property specifies an order in which the organization
	                                should be displayed relative to other organizations at the same level.
	                                Organizations will be displayed by sorting them by the values of displayOrder
	                                property (ascending). These that do not have any displayOrder annotation
	                                will be displayed last. Services with the same displayOrder
	                                are displayed in alphabetic order.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ServiceType.displayOrder</a:displayName>
                                <a:displayOrder>300</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="url" type="xsd:anyURI" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
	                                URL that points to the location of the service.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ServiceType.URL</a:displayName>
                                <a:displayOrder>150</a:displayOrder>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="service" type="tns:ServiceType" substitutionGroup="c:object"/>
    
    <xsd:complexType name="LookupTableType">
        <xsd:annotation>
            <xsd:documentation>
            	<p>
	                An object that represents lookup table. The lookup table can be used for two purposes:
	                value enumerations (e.g. for GUI or validation) and value mapping (translation).
	                The same lookup table can serve both purposes at the same time.
                </p>
                <p>
                	The content of the lookup table can be used as enumeration. E.g. the labels for each
                	table row can be displayed in the user interface. When a particular label is selected then
                	the associated key will be stored. Similar approach can be used for validation, e.g. when only
                	a selected set of values is legal for a certain property. In this case the "key" and "label"
                	columns are used.
                </p>
                <p>
                	The content of the lookup table can also be used for value mapping. E.g. in cases when
                	input value needs to be mapped to the output value. In this case the "key" and "value"
                	columns are used.
                </p>
                <p>
                	Even though the lookup table is represented as a prism object, it is designed to be
                	stored and queried efficiently. Therefore the contents of the lookup table will
                	be stored in a specialized table tuned for this purpose. This data type is not
                	designed to be used with the usual midPoint query mechanism (e.g. searchObjects operation).
                	Specialized operations are used to efficiently query the lookup tables. The prism 
                	representation (e.g. XML) of the lookup tables is used only for backup, restore, migrations,
                	upgrades and similar purposes.
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                	<xsd:element name="row" type="tns:LookupTableRowType" minOccurs="0" maxOccurs="unbounded"/>
                	<!-- TODO: Maybe more settings describing the intended use of the lookup table. -->
                	<!-- TODO: Lookup table synchronization settings? (e.g. resourceRef) -->
                </xsd:sequence>
           </xsd:extension>
       </xsd:complexContent>
   </xsd:complexType>
   <xsd:element name="lookupTable" type="tns:LookupTableType" substitutionGroup="c:object"/>
   
   <xsd:complexType name="LookupTableRowType">
       	<xsd:annotation>
    		<xsd:documentation>
    			Data structure that represents entire content of the lookup table, organized into table rows.
    			The delta semantics has a slightly different meaning for the lookup tables. Each key must be unique and the key
    			functions as an implicit identifier. E.g. adding a new row with a key that does not exist yet
    			will insert a new row. Adding a new row with key that already exists will overwrite existing row.
    			Replace operation on this property will efficiently clear the entire table and replace it with a new data.
    			We do not recommend using this operation as it may be very inefficient. Add and delete operations are
    			expected during normal operation.
    		</xsd:documentation>
    		<xsd:appinfo>
    			<a:container/>
    			<a:relational/>
    			<a:expensive/>
    		</xsd:appinfo>
    	</xsd:annotation>
    	<xsd:sequence>
    		<xsd:element name="key" type="xsd:string" minOccurs="1" maxOccurs="1">
    			<xsd:annotation>
    				<xsd:documentation>
    					Lookup table key column. This is the mandatory (non-null) column that usually
    					works as a mapping key. If the lookup table is used as an emumeration (there is no value column)
    					then the value of key column will be stored in the property when selected.
    					If the lookup table is used as a map, the value of key column will be matched to the
    					input variable.
    					
    					The value of the key is limited to a usual size of a "databse string". The actual size
    					constraint depends on the type of the database used as midPoint repository. It is
    					not recommended to use long values as keys.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="value" type="xsd:string" minOccurs="0" maxOccurs="1">
    			<xsd:annotation>
    				<xsd:documentation>
    					Lookup table value column. This is optional column that represents mapping output.
    					The appropriate row will be selected by using the key. The corresponding value will be used
    					as output.
    					
    					This column has no use if the lookup table is used as an enumeration.
    					The value of the key is limited to a usual size of a "databse string". The actual size
    					constraint depends on the type of the database used as midPoint repository. We expect that
    					this column may contain quasi-structured data. But this column is not intended for a very rich
    					data structures, such as long XML snippets. If structured data must be stored in this column
    					then we recommend to use very tight "microformats" such as separating the values with collons.
    					
    					A special-purpose CLOB column for richer data formats might be added in the future.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="label" type="t:PolyStringType" minOccurs="0" maxOccurs="1">
    			<xsd:annotation>
    				<xsd:documentation>
    					Columnt that contains a user-friendly label for corresponding to the key.
    					This label will be displayed in user interface as a representation of the key.
    					The label has no meaning when the lookup table is used to map values.
    				</xsd:documentation>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="lastChangeTimestamp" type="xsd:dateTime" minOccurs="0" maxOccurs="1">
    			<xsd:annotation>
    				<xsd:documentation>
    					Timestamp of the last change of the row. This is automatically manintaned by
    					the repository. It is updated every time the row is created or updated.
    					This row is intended to act as a "token" if the lookup table needs to be synchronized
    					with external resource.
    				</xsd:documentation>
    				<xsd:appinfo>
    					<a:operational>true</a:operational>
    				</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
   		</xsd:sequence>
        <xsd:attribute name="id" type="xsd:long" use="optional"/>
 	</xsd:complexType>

    <!-- OPERATIONAL SCHEMA -->

    <!-- The following clauses belong to the operation support. -->

    <xsd:complexType name="ValuePolicyType">
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                    <xsd:element name="lifetime" type="c:PasswordLifeTimeType" minOccurs="1" maxOccurs="1">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			DEPRECATED. Use the lifetime settings in security policy.
                    		</xsd:documentation>
                    		<xsd:appinfo>
                    			<a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="stringPolicy" type="tns:StringPolicyType" minOccurs="1" maxOccurs="1"/>
                    <xsd:element name="prohibitedValues" type="tns:ProhibitedValuesType" minOccurs="0" maxOccurs="1">
                    	<xsd:annotation>
                    		<xsd:appinfo>
                    			<a:since>3.7</a:since>
                    		</xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="minOccurs" type="xsd:string" minOccurs="0" default="0">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Minimal number of value occurrences. minOccurs set to zero means that the value
                    			is optional.
                    			E.g. when applied to passwords the minOccurs=0 means that the policy will
                    			accept no password at all. But it will still validate the password using
                    			stringPolicy if a password is present.
                    			DEPRECATED. Use equivalent setting in security policy instead.
                    		</xsd:documentation>
                    		<xsd:appinfo>
                    			<a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                    <xsd:element name="maxOccurs" type="xsd:string" minOccurs="0">
                    	<xsd:annotation>
                    		<xsd:documentation>
                    			Maximal number of value occurrences.
                    			If not specified then the default schema limitation is imposed.
                    			DEPRECATED. Use equivalent setting in security policy instead.
                    		</xsd:documentation>
                    		<xsd:appinfo>
                    			<a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                    	</xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:element name="valuePolicy" type="tns:ValuePolicyType" substitutionGroup="c:object"/>

    <xsd:complexType name="PasswordLifeTimeType">
        <xsd:sequence>
            <xsd:element name="expiration" type="xsd:int" default="-1" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of days before password expires
                        -1 : means password doesn't expire
                        0 : means password is expired
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="warnBeforeExpiration" default="0" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of days before password expiration to
                        send warnings (0 means no warnings)
                    </xsd:documentation>
                </xsd:annotation>
                <xsd:simpleType>
                    <xsd:restriction base="xsd:int">
                        <xsd:minInclusive value="0"/>
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:element>
            <xsd:element name="lockAfterExpiration" default="0" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of days after password after password
                        expiration the account will be locked (0 means never
                        will be locked)
                    </xsd:documentation>
                </xsd:annotation>
                <xsd:simpleType>
                    <xsd:restriction base="xsd:int">
                        <xsd:minInclusive value="0"/>
                    </xsd:restriction>
                </xsd:simpleType>
            </xsd:element>
            <xsd:element name="minPasswordAge" type="xsd:int" default="0" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of days before password may be changed (0
                        means password can be changed immediately)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="passwordHistoryLength" type="xsd:int" default="0" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of unique passwords in history (0 - no
                        history)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="passwordLifeTime" type="tns:PasswordLifeTimeType"/>

    <xsd:complexType name="StringPolicyType">
    	 <xsd:annotation>
            <xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
        </xsd:annotation>
    
        <xsd:sequence>
            <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="limitations" type="tns:LimitationsType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="characterClass" type="tns:CharacterClassType" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="LimitationsType">
        <xsd:annotation>
            <xsd:documentation>Definition of complexity and string policy
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="minLength" type="xsd:int" default="0" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="maxLength" type="xsd:int" default="-1" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="minUniqueChars" type="xsd:int" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Minimum number of unique characters in the generated string.
                    	  Defaults to minLength.
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>            
            </xsd:element>
            <xsd:element name="checkAgainstDictionary" type="xsd:boolean" default="false" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="checkPattern" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="checkExpression" type="c:CheckExpressionType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Expression that is used to check the resulting value whether it is acceptable
                    	  or not. If the expression returns true, then the value is accepted.
                    	  If the expression returns false value, then the value is rejected and it
                    	  will be generated again. Until the maximum number of attempts is reached.
                    	  If there are several expressions that all of them must pass for the value to
                    	  be accepted. However each of them may produce a different failure message.
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="maxAttempts" type="xsd:int" default="10" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Maximum number of attempts to generate an expression. Attempts are used
                    	  with limitations that cannot be incorporated directly into the generation
                    	  algorithm (check expression, pattern, dictionary).
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>            
            </xsd:element>
            <xsd:element name="limit" type="tns:StringLimitType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="StringLimitType">
        <xsd:annotation>
            <xsd:documentation>Definition of valid single string limitation
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="minOccurs" type="xsd:int" default="0" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="maxOccurs" type="xsd:int" default="-1" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="mustBeFirst" type="xsd:boolean" default="false" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="characterClass" type="tns:CharacterClassType" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="CharacterClassType">
        <xsd:annotation>
            <xsd:documentation>Definition of valid characters in class. Default
                value is ASCII printable characters (Codes 0x20
                to 0x7E)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:choice>
                <xsd:element name="characterClass" type="tns:CharacterClassType" minOccurs="1" maxOccurs="unbounded"/>
                <xsd:element name="value" type="xsd:string" minOccurs="1"/>
            </xsd:choice>
        </xsd:sequence>
        <xsd:attribute name="ref" type="xsd:QName" use="optional"/>
        <xsd:attribute name="name" type="xsd:QName" use="optional"/>
    </xsd:complexType>
    
    <xsd:complexType name="CheckExpressionType">
        <xsd:annotation>
            <xsd:documentation>
            	Expression used to check the data and report a user-friendly message in case
            	that the check fails.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="expression" type="c:ExpressionType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Expression that is used to check the resulting value whether it is acceptable
                    	  or not. If the expression returns true, then the value is accepted.
                    	  If the expression returns false value, then the value is rejected.
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
			<xsd:element name="localizableFailureMessage" type="tns:LocalizableMessageType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Localizable message that will be displayed to user when the expression check fails.
							This one takes precedence over (non-localizable) failureMessage.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
            <xsd:element name="failureMessage" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                    	<p>
                    	  Message that will be displayed to user when the expression check fails.
                    	</p> 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO: sucess message? -->
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ProhibitedValuesType">
    	 <xsd:annotation>
            <xsd:appinfo>
				<a:container/>
				<a:since>3.7</a:since>
			</xsd:appinfo>
        </xsd:annotation>    
        <xsd:sequence>
            <xsd:element name="item" type="tns:ProhibitedValueItemType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ProhibitedValueItemType">
    	 <xsd:annotation>
            <xsd:appinfo>
				<a:container/>
				<a:since>3.7</a:since>
			</xsd:appinfo>
        </xsd:annotation>    
        <xsd:sequence>
            <xsd:element name="origin" type="tns:ValuePolicyOriginType" minOccurs="0" maxOccurs="1" default="object"/>
            <xsd:element name="path" type="t:ItemPathType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="projectionDiscriminator" type="tns:ShadowDiscriminatorType" minOccurs="0" maxOccurs="1">
            	<xsd:annotation>
            		<xsd:documentation>
            			Specifies which projection should be used in case that projection origin is selected.
            		</xsd:documentation>
            		<xsd:appinfo>
            			<a:since>3.7.1</a:since>
            		</xsd:appinfo>
            	</xsd:annotation>
            </xsd:element>
            <!-- TODO: matching (exact, norm, case ignore, partial, ...), matching parameters ( 3 characters difference ) -->
        </xsd:sequence>
    </xsd:complexType>
    
        <xsd:simpleType name="ValuePolicyOriginType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="object">
                <xsd:annotation>
                	<xsd:documentation>
                		Object is the orgin. Object usually means the user.
                		E.g. in case of password policy, object is the user
                		who's password is changed. 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OBJECT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="persona">
                <xsd:annotation>
                	<xsd:documentation>
                		Object's persona is the origin.
                		E.g. in case of password policy all user personas
                		will be scanned.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PERSONA"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="owner">
                <xsd:annotation>
                	<xsd:documentation>
                		Object's owner is the origin.
                		E.g. in case of user password policy all personas that
                		point to this user will be scanned. In case of
                		account password policy the user who owns the
                		account is scanned.
                		Note: owner for accounts is not implemented yet
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OWNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="projection">
                <xsd:annotation>
                	<xsd:documentation>
                		One of object's projecion is the origin.
                		E.g. in case of user password specific projection
                		linked to the user will be scanned.
                		If this origin type is selected then also
                		the projectionDiscriminator must be specified.
                		Note: Currently the only supported value is
                		resource password.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PROJECTION"/>
                        <a:since>3.7.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    

    <xsd:complexType name="OperationResultType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="operation" type="xsd:string"/>
            <xsd:element name="status" type="tns:OperationResultStatusType"/>
            <xsd:element name="minor" type="xsd:boolean" minOccurs="0" default="false"/>
            <xsd:element name="count" type="xsd:int" minOccurs="0" default="1"/>
            <xsd:element name="hiddenRecordsCount" type="xsd:int" minOccurs="0" default="0"/>
            <xsd:element name="params" type="tns:ParamsType" minOccurs="0"/>
            <xsd:element name="context" type="tns:ParamsType" minOccurs="0"/>
            <xsd:element name="returns" type="tns:ParamsType" minOccurs="0"/>
            <xsd:element name="token" type="xsd:long" minOccurs="0"/>
            <xsd:element name="messageCode" type="xsd:string" minOccurs="0"/>
            <xsd:element name="message" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Error or warning message.
                        This is optional, as some types does not need a message (e.g. success).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="userFriendlyMessage" type="tns:LocalizableMessageType" minOccurs="0"/>
            <xsd:element name="details" type="xsd:string" minOccurs="0"/>
            <xsd:element name="partialResults" type="tns:OperationResultType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="operationResult" type="tns:OperationResultType"/>

    <xsd:complexType name="ParamsType">
        <xsd:sequence>
            <xsd:element name="entry" type="tns:EntryType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="params" type="tns:ParamsType"/>

    <xsd:complexType name="EntryType">
        <xsd:sequence>
        	<xsd:element ref="tns:entryValue" minOccurs="0" />
<!--             <xsd:any processContents="lax" minOccurs="0"> -->
<!--                 <xsd:annotation> -->
<!--                     <xsd:documentation> -->
<!--                         Value of the entry. If there is a object that can native XML representation, such representation -->
<!--                         should -->
<!--                         be used. Otherwise the UnknownJavaObject can be used. -->
<!--                     </xsd:documentation> -->
<!--                 </xsd:annotation> -->
<!--             </xsd:any> -->
        </xsd:sequence>
        <xsd:attribute name="key" type="xsd:string" use="required"/>
    </xsd:complexType>
    
    <xsd:element name="entryValue" abstract="true"/>
    
    <xsd:element name="paramValue" type="xsd:anyType" substitutionGroup="tns:entryValue" nillable="true">
        <xsd:annotation>
            <xsd:documentation>
                Static value for the attribute or property.

                Static attribute values. The values in this element should be
                assigned to the account as-is.

                List of values for the attribute provided in an appropriate XML elements
                that specify attribute name. (as is usual for properties)

                Only one attribute may be specified here, although it may have multiple
                values. Multi-valued attributes are expressed by repeating the same XML
                element multiple times.
                Hence all the XML elements that match this xsd:any must have the same
                element names (may have different values of course).


                Please note that this is nillable and therefore it may be
                explicitly set to "nil" value. Doing this means that empty
                set of values should be constructed. E.g. setting
                this to "nil" and also setting "authoritative" flag
                may enforce removal of all attribute values (if used properly).
            </xsd:documentation>
            <xsd:appinfo>
                <a:rawType/>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:simpleType name="OperationResultStatusType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="success">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SUCCESS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="warning">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WARNING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="partial_error">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PARTIAL_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="fatal_error">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FATAL_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="handled_error">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HANDLED_ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="not_applicable">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NOT_APPLICABLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="in_progress">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IN_PROGRESS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unknown">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNKNOWN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="UnknownJavaObjectType">
        <xsd:annotation>
            <xsd:documentation>
                Type used to represent Java objects that are otherwise unknown to the system and cannot be
                represented in "canonical" XML form. This must be used only in diagnostics messages intended
                to be displayed to the human user. It must not be used in places indended for computer processing.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="class" type="xsd:string"/>
            <xsd:element name="toString" type="xsd:string"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="unknownJavaObject" type="tns:UnknownJavaObjectType" substitutionGroup="tns:entryValue"/>

    <!-- Configuration types -->

    <xsd:complexType name="SystemConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                System configuration object.

                Holds global system configuration setting. There will be just one object of
                this type in the system. It will have a well-known OID.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ObjectType">
                <xsd:sequence>
                    <xsd:element name="globalAccountSynchronizationSettings"
                                 type="tns:ProjectionPolicyType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                System-global account synchronization settings. These will be used if there is no
                                specific settings
                                (e.g. per resource or per request).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="globalPasswordPolicy" type="tns:ValuePolicyType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                System-global password policy settings. These will be used if there is no specific settings 
                                (e.g. per account)

                                DEPRECATED: use equivalent setting in security policy
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:globalPasswordPolicyRef</a:objectReference>
                    			<a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="globalPasswordPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference to the global password policy settings.

                                DEPRECATED: use equivalent setting in security policy
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ValuePolicyType</a:objectReferenceTargetType>
                    			<a:deprecated>true</a:deprecated>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="globalSecurityPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference to the global security policy settings.

                                TODO: better documentation
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:SecurityPolicyType</a:objectReferenceTargetType>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="modelHooks" type="tns:ModelHooksType" minOccurs="0"/>
                    <xsd:element name="logging" type="tns:LoggingConfigurationType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Persistent configuration of logging levels, categories, etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="defaultUserTemplate" type="tns:ObjectTemplateType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                User template that will be used "universally" in all situations regarding user internal
                                consistency.
                                </p>

                                <p>DEPRECATED: use objectTemplate instead.</p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReference>tns:defaultUserTemplateRef</a:objectReference>
                    			<a:deprecated/>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="defaultUserTemplateRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                            	<p>
                                Reference to the default user template that will be used "universally" in all
                                situations regarding user internal consistency.
                                </p>

								<p>DEPRECATED: use objectTemplate instead.</p>
                            </xsd:documentation>
                            <xsd:appinfo>
                    			<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
                    			<a:deprecated/>
                    		</xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="objectTemplate" type="tns:ObjectPolicyConfigurationType" minOccurs="0" maxOccurs="unbounded">
	                    <xsd:annotation>
							<xsd:documentation>
								Definition of default object templates for a individual object type. The templates will be used
								"universally" during all operations with specified object types - unless the templates are overriden
								in other definitions (e.g. in resource).
								
								DEPRECATED. Use defaultObjectPolicyConfiguration instead.
							</xsd:documentation>
							<xsd:appinfo>
								<a:container/>
								<a:deprecated>true</a:deprecated>
							</xsd:appinfo>
						</xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="defaultObjectPolicyConfiguration" type="tns:ObjectPolicyConfigurationType" minOccurs="0" maxOccurs="unbounded">
	                    <xsd:annotation>
							<xsd:documentation>
								Definition of default object policy for a individual object type. The definition of this policy
								contains object template and other similar settings. The policy will be used
								"universally" during all operations with specified object types - unless it is overridden
								in other definitions (e.g. in resource or org).
							</xsd:documentation>
							<xsd:appinfo>
								<a:container/>
							</xsd:appinfo>
						</xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="connectorFramework" minOccurs="0" maxOccurs="1" type="tns:ConnectorFrameworkType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Global configuration of connectors and connector frameworks.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="notificationConfiguration" type="tns:NotificationConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for user notifications. In future, it might be overriden e.g. at a level
                                of a user.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="workflowConfiguration" type="tns:WfConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for workflows. Some static aspects (e.g. database connection for Activiti)
                                are stored in the system configuration file.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="accessCertification" type="tns:AccessCertificationConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for access certifications.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="roleManagement" type="tns:RoleManagementConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for role management: role catalog, role assignments, etc.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="globalPolicyRule" type="tns:GlobalPolicyRuleType" minOccurs="0" maxOccurs="unbounded">
					    <xsd:annotation>
					        <xsd:documentation>
					            Global policy rules that are applied to all (selected) objects in the system.
					            These rules specify compliance and governance constraints.
					        </xsd:documentation>
					        <xsd:appinfo>
								<a:since>3.5</a:since>
							</xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>

                    <xsd:element name="profilingConfiguration" type="tns:ProfilingConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for profiling purposes. The first iteration of profiling integration has
                                only few configuration options, but profiling feature will grow in near future.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="cleanupPolicy" type="tns:CleanupPoliciesType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration of cleanup intervals and other parameters.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="internals" type="tns:InternalsConfigurationType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Various internals configuration.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>

					<xsd:element name="adminGuiConfiguration" type="tns:AdminGuiConfigurationType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Administration GUI configuration.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>AdminGuiConfigurationType.adminGuiConfiguration</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="mergeConfiguration" type="tns:MergeConfigurationType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Configurations for object merging. E.g. for merging two users.
                            </xsd:documentation>
                            <xsd:appinfo>
                            	<a:since>3.5</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="defaultHostname" type="xsd:string" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Hostname that will be used as a public hostname for the midPoint deployment.
                                E.g. it will be used in URLs that point to the midPoint in notification mails.
								DEPRECATED. Use infrastructure/defaultHostname instead.
                            </xsd:documentation>
                            <xsd:appinfo>
                            	<a:since>3.5</a:since>
								<a:deprecated>true</a:deprecated>
								<a:deprecatedSince>3.6</a:deprecatedSince>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    
                    <xsd:element name="deploymentInformation" type="tns:DeploymentInformationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Information about midPoint deployment: subscription information, deployment name,
                                description, color and so on.
                            </xsd:documentation>
                            <xsd:appinfo>
                            	<a:since>3.5.1</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="infrastructure" type="tns:InfrastructureConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Technical (infrastructure) configuration of midPoint deployment.
                            </xsd:documentation>
                            <xsd:appinfo>
                            	<a:since>3.6</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element name="fullTextSearch" type="tns:FullTextSearchConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Configuration of the full text search feature.
                            </xsd:documentation>
                            <xsd:appinfo>
                            	<a:since>3.6</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="systemConfiguration" type="tns:SystemConfigurationType"/>

	<xsd:complexType name="FullTextSearchConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				Configuration of the full text search feature.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.6</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="enabled" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Whether full text search indexing is enabled. The default is true, if there are any indexed entries defined.
						(This property is to allow temporary disabling existing configuration.)
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="indexed" type="tns:FullTextSearchIndexedItemsConfigurationType" minOccurs="0" maxOccurs="unbounded">
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="FullTextSearchIndexedItemsConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				What items to index.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.6</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="objectType" type="xsd:QName" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						To what object type(s) should this entry be applied.
						Empty list means "all object types".
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="item" type="t:ItemPathType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						What items to index for the given object type(s).
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="FunctionLibraryType">
		<xsd:annotation>
			<xsd:documentation>
				Define reusable functions
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		 <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                	<xsd:element name="function" type="tns:ExpressionType" minOccurs="0" maxOccurs="unbounded"/>
            	</xsd:sequence>
            </xsd:extension>
       </xsd:complexContent>
	</xsd:complexType>
	<xsd:element name="functionLibrary" type="tns:FunctionLibraryType" substitutionGroup="c:object"/>
	
	

	<xsd:complexType name="InternalsConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Various internals configuration elements.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="enableExperimentalCode" type="xsd:boolean" minOccurs="0" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        Whether experimental parts of midPoint code should be enabled.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="maxModelClicks" type="xsd:int" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        How many clicks are allowed for the clockwork to make in one operation.
                        (Default: 200.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="subresultStripThreshold" type="xsd:int" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
						When aggregation of the same subresults (same operation and status) is to be applied,
						during operation result "summarize" operation.
                        (Default: 10.)

						TEMPORARY/EXPERIMENTAL. We plan to provide more elaborate operation result aggregation strategies.
						This is just a quick way how to reduce large operation results for some deployments.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="AdminGuiConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Administration GUI configuration.
                Note: This complexType is NOT a container. We need to guarantee ordering of some sub-items (e.g. links)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="additionalMenuLink" type="tns:RichHyperlinkType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Extra menu item that will appear in addition to standard menu items.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="userDashboardLink" type="tns:RichHyperlinkType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Application or shortcut links placed on end-user dashboard.
                        TODO: align with userDashboard
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="objectLists" type="tns:GuiObjectListsType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies the set of pages that are used for displaying lists of objects
      						such as Users, Roles, Orgs, ...
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.4</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
            <xsd:element name="objectForms" type="tns:ObjectFormsType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies the set of default forms that are used for displaying and
      						editing of objects, such as User, Role, Org, ...
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.4</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="objectDetails" type="tns:GuiObjectDetailsSetType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies the look and feel of the pages for displaying object details and
      						editing of objects, such as User, Role, Org, ...
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="userDashboard" type="tns:DashboardLayoutType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies the layout of the user dashboard (home screen): 
							it defines which boxes should be visible, which should be hidden, etc.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<!-- TODO: role catalog views: define collections (additional views), default search type, etc. -->
			<xsd:element name="defaultTimezone" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
                               Default timezone for the GUI. It is specified in the "tz database" (a.k.a "Olson")
                               format. If not specified then system default timezone is assumed.
                        </p>
						<p>
                         Examples:
                             <ul>
                                 <li>Europe/Bratislava</li>
                             </ul>
                         </p> 
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.4</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="preferredDataLanguage" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Preferred data language (e.g. xml, json, yaml - written in lowercase). Default is xml.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.5</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="enableExperimentalFeatures" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Enabled experimental and alternative user interface features.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="defaultExportSettings" type="tns:GuiExportSettingsType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies the default settings for GUI object export.
							This setting apply to object export that is accessible to common users
							(e.g. the user list page, resource list). 
							This does NOT necessarily controls the export of repository objects.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="feature" type="tns:UserInterfaceFeatureType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Generic configuration for individual UI features. Mostly specifies whether to show
						them or hide them. 
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="feedbackMessagesHook" type="tns:FeedbackMessagesHookType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						<p>
							Specifies scripting hook which can modify operation results or messages
							before they are shown in UI.
						</p>
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="FeedbackMessagesHookType">
		<xsd:annotation>
			<xsd:appinfo>
				<a:container/>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="operationResultHook" type="tns:ExpressionType" minOccurs="0" />
		</xsd:sequence>
	</xsd:complexType>
    
    <xsd:complexType name="DashboardLayoutType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies layout of a dashboard, such as the user dashboard (home screen)
        		or administration dashboard. It specifies which boxes should be visible, which
        		should be hidden and so on.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
           		<xsd:element name="widget" type="tns:DashboardWidgetType" minOccurs="0" maxOccurs="unbounded"/>
           	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:complexType name="DashboardWidgetType">
        <xsd:annotation>
        	<xsd:documentation>
        		Defines properties of a specific dashboard widget.
        		
        		The identifier property defines the identity of the widget and currently
				also the placement on the dashboard. The widget specifications that come
				from different roles will be merged if they have the same identifier.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:UserInterfaceFeatureType">
	       		<xsd:sequence>
	           		<!-- TODO: type
	           		<xsd:element name="type" type="xsd:QName" minOccurs="0" maxOccurs="1">
	           			<xsd:annotation>
	           				<xsd:documentation>
	           					Type of the widget. It is an identifier that specifies the content
	           					of the winget (e.g. what will be inside the box).
	           					THIS IS NOT USED YET. It is only for future use.
	           				</xsd:documentation>
	           			</xsd:annotation>
	           		</xsd:element>
	           		 -->
	           		<!-- TODO: placement -->
	           	</xsd:sequence>	
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
	<xsd:complexType name="UserInterfaceFeatureType">
        <xsd:annotation>
        	<xsd:documentation>
        		Defines properties of a specific user interface feature (e.g. button, button set, widget, etc.)
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="identifier" type="xsd:anyURI" minOccurs="1" maxOccurs="1">
           			<xsd:annotation>
           				<xsd:documentation>
           					Widget identifier. The feature specifications that come
           					from different roles will be merged if they have the same identifier.
           				</xsd:documentation>
           			</xsd:annotation>
           		</xsd:element>
           		<xsd:element name="visibility" type="tns:UserInterfaceElementVisibilityType" 
           		             minOccurs="0" maxOccurs="1" default="vacant">
           			<xsd:annotation>
           				<xsd:documentation>
           					Defines, whether this feature will be visible or it will be hidden.
           				</xsd:documentation>
           			</xsd:annotation>
           		</xsd:element>
           	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:simpleType name="UserInterfaceElementVisibilityType">
        <xsd:annotation>
            <xsd:documentation>
                Defines, whether a user interface element (form, widget) will be visible or it will be hidden.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="automatic">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AUTOMATIC"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The element will be visible if the authorisations of the current user
                        allows to see (at least a part) of the content that the element displays.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="visible">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="VISIBLE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The element will be always visible (if not hidden).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="vacant">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="VACANT"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The element will not be visible. Not even if the authorizations allow
                        to see its content. But if any other role specifies the element as visible
                        or automatic then it will be visible. This setting is easily overridden.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="hidden">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HIDDEN"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The element is never visible. Even if any other role specifies the element as
                        visible then the element will still remain invisible. This setting cannot be
                        overridden. 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

	<xsd:complexType name="RichHyperlinkType">
        <xsd:annotation>
            <xsd:documentation>
                Hyperlink with a label, menu and other data that control a rich presentation of the link.
                Not all parameters that are present in this data strucutre might be supported in all the places
                where a link is used. Which parameter will be used depends on where exactly is the link used and
                how it is rendered (as an menu item, application launch button, etc.)
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="targetUrl" type="xsd:string" minOccurs="1" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	URL of the link target. It can be absolute URL with method specification or it can be relative URL.
                    	If the URL is relative, it is assumed that it is relative to the application root URL context.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="label" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	Human-readable label to display with the link (or a key to the localization file).
                    	The label should be quite short (several words). It is meant to be displayed as a menu item
                    	label, launcher label, etc.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	Human-readable description to display with the link (or a key to the localization file).
                    	The description can be longer (several sentences). It is mean to be displayed as a multi-line
                    	description, tooltip, etc. 
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="icon" type="tns:IconType" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	Icon to display for this link.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="color" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	Primary color that will be used to render this link in case that multiple color options are supported.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="authorization" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Authorizations needed to display this link. If specified, the the link will be displayed
                        only if the active user has one of the specified the authorizations.
                         If no authorization is specified then the link will be always displayed.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="IconType">
        <xsd:annotation>
            <xsd:documentation>
                User interface icon specification.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="imageUrl" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	URL of the image to use as an icon. It is expected that this will be a relative URL
                    	that is relative to the application root URL context.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="cssClass" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                    	CSS class to use for icon representation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ObjectPolicyConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of policy for a specific object type. It defines object template
				and similar settings that apply to the object alone. This policy settings
				apply to the object internal structure without regard to other objects.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="type" type="xsd:QName" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Specification of the type (class) of the object to apply this definition to.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="subtype" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Specification of the subtype of the object to apply this template to.
						If no subtype is specified then this definition will be applied to all subtypes.
						The subtype is compared against the subType property but it is also compared to the
						deprecated employeeType, roleType, orgType and serviceType properties.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="objectTemplateRef" type="tns:ObjectReferenceType">
				<xsd:annotation>
					<xsd:documentation>
						Reference to the template.
					</xsd:documentation>
					<xsd:appinfo>
						<a:objectReferenceTargetType>tns:ObjectTemplateType</a:objectReferenceTargetType>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="propertyConstraint" type="tns:PropertyConstraintType" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="oidNameBoundMode" type="xsd:boolean" minOccurs="0" default="false">
				<xsd:annotation>
					<xsd:documentation>
						A mode in which OID and name of the specified object are the same.
					</xsd:documentation>
					<xsd:appinfo>
						<a:deprecated>true</a:deprecated>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="conflictResolution" type="tns:ConflictResolutionType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						How to resolve write-write conflicts on focal objects, i.e. if two threads modify given objects at once.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
						<a:experimental>true</a:experimental>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="lifecycleStateModel" type="tns:LifecycleStateModelType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Specification of lifecycle states and state transitions.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7.1</a:since>
						<a:experimental>true</a:experimental>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="ConflictResolutionType">
		<xsd:annotation>
			<xsd:documentation>
				How to resolve write-write conflicts on focal objects, i.e. if two threads modify given objects at once.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
				<a:since>3.6.1</a:since>
				<a:experimental>true</a:experimental>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="action" type="tns:ConflictResolutionActionType">
				<xsd:annotation>
					<xsd:documentation>
						What action to take.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="maxAttempts" type="xsd:int" minOccurs="0" default="1">	<!-- synchronize with Clockwork.java -->
				<xsd:annotation>
					<xsd:documentation>
						How many attempts to undertake at most.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="delayUnit" type="xsd:int" minOccurs="0" default="5000">	<!-- synchronize with Clockwork.java -->
				<xsd:annotation>
					<xsd:documentation>
						What delay (in milliseconds) to introduce between attempts. Actual delay is taken as
						a random number between 0 and delayUnit*(2^(n-1)), where n is the number of conflict resolution attempt,
						starting at 1. (In other words, the potential delay is multiplied by two after each unsuccessful
						resolution attempt.)
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="ConflictResolutionActionType">
		<xsd:annotation>
			<xsd:documentation>
				What to do in the case of modify-modify conflict during model (clockwork) operation.
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
				<a:since>3.6.1</a:since>
				<a:experimental>true</a:experimental>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="none">
				<xsd:annotation>
					<xsd:documentation>
						Nothing should be done. This is the default behavior.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="NONE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="log">
				<xsd:annotation>
					<xsd:documentation>
						Warning should be issued into the log file.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="LOG"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="error">
				<xsd:annotation>
					<xsd:documentation>
						Operation should be end with an error. 
						This is a recoverable error (precondition failed).
						TODO: align with "fail"
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="ERROR"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="restart">
				<xsd:annotation>
					<xsd:documentation>
						Operation should be restarted.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="RESTART"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="recompute">
				<xsd:annotation>
					<xsd:documentation>
						The focus object should be recomputed.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="RECOMPUTE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="reconcile">
				<xsd:annotation>
					<xsd:documentation>
						The focus object should be recomputed and all projections reconciled.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="RECONCILE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="fail">
				<xsd:annotation>
					<xsd:documentation>
						The whole operation should fail. This is to be used mainly for testing purposes,
						to check if conflict detection algorithm does not yield false positive results.
						This fails with a system error. This is a definitive, non-recoverable fauilure.
						TODO: align with "error"
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="FAIL"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:complexType name="PropertyConstraintType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of a property constraints.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="path" type="t:ItemPathType" minOccurs="1" maxOccurs="1">
			</xsd:element>
			<!-- TODO: uniqueness constraint -->
             <xsd:element name="oidBound" type="xsd:boolean" minOccurs="0" default="false">
             	<xsd:annotation>
             		<xsd:documentation>
             			The property value will be bound to OID. This property will be set to the value
             			of OID and it cannot be changed.
             		</xsd:documentation>
             		<xsd:appinfo>
             			<a:deprecated>true</a:deprecated>
             		</xsd:appinfo>
             	</xsd:annotation>
             </xsd:element>
		</xsd:sequence>
	</xsd:complexType>

    <xsd:complexType name="ConnectorFrameworkType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="configuration" type="tns:ConnectorFrameworkConfigurationType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Global configuration properties of a connector framework.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ConnectorFrameworkConfigurationType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element ref="tns:extension" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        This element may contain any framework-specific global
                        configuration.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="connectorPath" type="xsd:string" minOccurs="0"
                         maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        The path to the connector artifacts such as JAR files or
                        directories containing the connector
                        code. The specific meaning may vary slightly for each connector
                        framework. The connector framework may also
                        provide a default path in case nothing is specified here (or
                        addition to what is specified here).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ProjectionPolicyType">
        <xsd:annotation>
            <xsd:documentation>
                Specification of the way how projections are handled on the resource. This defines the ways how
                assignments are enforced and so on.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="assignmentPolicyEnforcement" type="tns:AssignmentPolicyEnforcementType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Full enforcement is the default setting.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="legalize" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
            	<xsd:annotation>
            		<xsd:documentation>
            			If set to true then the illegal resource objects (e.g. accounts) will be made legal.
            			Illegal resource object is a linked resource object for which there is no assignment.
            			If this option is set to true then it will automatically add a (direct) assignment for
            			this object.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>   
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="AssignmentPolicyEnforcementType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        No enforcement. Assignments will be ignored.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="positive">
                <xsd:annotation>
                    <xsd:documentation>
                        Assignements will be enforced only in a positive manner.
                        E.i. If a non-existing account is assigned it will be created.
                        If existing account is not assigned it will NOT be removed.
                        
                        This is the default policy of no other policy is set.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="POSITIVE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="full">
                <xsd:annotation>
                    <xsd:documentation>
                        Full enforcement
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FULL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="relative">
                <xsd:annotation>
                    <xsd:documentation>
                        Relative enforcement
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RELATIVE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ModelHooksType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="change" type="tns:HookListType" minOccurs="0"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="HookListType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="hook" type="tns:HookType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="HookType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				Free-form hook name. Used for diagnostic purposed (e.g. in logfiles)
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
        	<xsd:element name="description" type="xsd:string" minOccurs="0"/>
        	<xsd:element name="enabled" type="xsd:boolean" minOccurs="0" default="true"/>
            <xsd:element name="state" type="tns:ModelStateType" minOccurs="0"/>
            <xsd:element name="focusType" type="xsd:QName" minOccurs="0"/>
            <xsd:element name="ref" type="xsd:anyURI" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			URL of hook handler.
            			Exactly one of "ref" or "script" has to be specified.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="script" type="tns:ScriptExpressionEvaluatorType" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Script that will be executed instead of hook handler.
            			Exactly one of "ref" or "script" has to be specified.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="LoggingConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of logging levels, categories, log
                files, etc.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="subSystemLogger" type="tns:SubSystemLoggerConfigurationType" minOccurs="0"
                         maxOccurs="unbounded"/>
            <xsd:element name="classLogger" type="tns:ClassLoggerConfigurationType" minOccurs="0"
                         maxOccurs="unbounded"/>
            <xsd:element name="appender" type="tns:AppenderConfigurationType" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="rootLoggerAppender" type="xsd:string"/>
            <xsd:element name="rootLoggerLevel" type="tns:LoggingLevelType"/>
            <xsd:element name="auditing" type="tns:AuditingConfigurationType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Persistent auditing configuration. It is placed in "logging" for practical reasons as the only
                        available auditing option is to use logging.
                        THIS WILL CHANGE IN THE FUTURE.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="advanced" type="tns:AdvancedLoggingConfigurationType" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="debug" type="xsd:boolean" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Whether to include 'debug=true' in generated logback configuration file.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AuditingConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Auditing configuration
                UNSTABLE. THIS WILL CHANGE IN THE FUTURE.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="enabled" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="true"/>
            <xsd:element name="details" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
            <xsd:element name="appender" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AdvancedLoggingConfigurationType" mixed="true">
        <xsd:annotation>
            <xsd:documentation>
                Contains free form loging configuration.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:any maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ClassLoggerConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of the logger: the facility that
                collects log messages from the code.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="level" type="tns:LoggingLevelType">
                <xsd:annotation>
                    <xsd:documentation>
                        Logger level
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="package" type="xsd:string" minOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO: packages are OR-ed
                        TODO: string, wildcards
                        allowed (* as in java)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="appender" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Appender name defined in appenders section in
                        logging configuration
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SubSystemLoggerConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of the logger: the facility that
                collects log messages from subsystem code.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="level" type="tns:LoggingLevelType">
                <xsd:annotation>
                    <xsd:documentation>
                        Logger level
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="component" type="c:LoggingComponentType" minOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO: components are OR-ed
                        TODO: string, but there should be a way how to determine
                        list of valid categories. Maybe switch to enum later.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="appender" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        Appender name defined in appenders section in
                        logging configuration
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>


    <xsd:simpleType name="LoggingLevelType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ALL">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="OFF">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OFF"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ERROR">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="WARN">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WARN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="INFO">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="INFO"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="DEBUG">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DEBUG"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="TRACE">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TRACE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ALL">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="LoggingComponentType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ALL">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="MODEL">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MODEL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="PROVISIONING">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PROVISIONING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="REPOSITORY">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPOSITORY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="WEB">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WEB"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="GUI">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="GUI"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="TASKMANAGER">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TASKMANAGER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="RESOURCEOBJECTCHANGELISTENER">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RESOURCEOBJECTCHANGELISTENER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="WORKFLOWS">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="WORKFLOWS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="NOTIFICATIONS">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NOTIFICATIONS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ACCESS_CERTIFICATION">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ACCESS_CERTIFICATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="SECURITY">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SECURITY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="AppenderConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of the logger: the facility that
                collects log messages from the code.

                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="pattern" type="xsd:string"/>
        </xsd:sequence>
        <xsd:attribute name="name" type="xsd:string"/>
    </xsd:complexType>

    <xsd:complexType name="FileAppenderConfigurationType">
        <xsd:complexContent>
            <xsd:extension base="tns:AppenderConfigurationType">
                <xsd:sequence>
                    <xsd:element name="fileName" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="filePattern" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="maxHistory" type="xsd:int" minOccurs="0"/>
                    <xsd:element name="maxFileSize" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="append" type="xsd:boolean" minOccurs="0"/>
                    <xsd:element name="prudent" type="xsd:boolean" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Prudent mode allows remote and shared file destinations (see https://logback.qos.ch/manual/appenders.html#prudentWithRolling )
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="SyslogAppenderConfigurationType">
        <xsd:complexContent>
            <xsd:extension base="tns:AppenderConfigurationType">
                <xsd:sequence>
                    <xsd:element name="syslogHost" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="port" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="facility" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="suffixPattern" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="stackTracePattern" type="xsd:string" minOccurs="0"/>
                    <xsd:element name="throwableExcluded" type="xsd:boolean" minOccurs="0"/>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="RoleManagementConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                A configuration for role management: role catalog, role assignments, etc.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:container>true</a:container>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="description" type="xsd:string" minOccurs="0"/>
        	<xsd:element name="roleCatalogRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
			    <xsd:annotation>
			        <xsd:documentation>
			            Reference to the root object of the role catalog.
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:objectReferenceTargetType>tns:OrgType</a:objectReferenceTargetType>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<xsd:element name="roleCatalogCollections" type="tns:ObjectCollectionsUseType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Specifies the set of object collections ("role catalog views") to display in role
						catalog. If this element is not specified then the default (hardcoded) collections
						will be displayed. If this element is specified then only those collections specified
						in this element are displayed.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="defaultCollection" type="tns:ObjectCollectionUseType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Specifies the default object collections ("role catalog view") to display in role
						catalog.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="defaultAssignmentConstraints" type="tns:AssignmentConstraintsType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Default assignment constraints. These constraints are applied globally to
						the entire system. 
						This value defines whether the same
						abstract role may be assigned only once or multiple times to the same focus.
						This is the system-wide default value.
						It will be possible to override this value for each individual role using the
						policy rules in the future midPoint versions.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="defaultExecuteAfterAllApprovals" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Default value for "Execute after all approvals" flag.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="autoassignEnabled" type="xsd:boolean" minOccurs="0" default="false">
				<xsd:annotation>
					<xsd:documentation>
						Global switch that enables autoassign functionality for roles.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="AssignmentConstraintsType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies constraints on assignments that are placed in the same focus. It can be used
                to prohibit multiple assignment of the same role and for similar cases.
                There are several individual constraints in the type. There is a logical AND between them.
                This means that if no contraint can be violated. All active constratints must be satified
                at the same time.
            </xsd:documentation>
            <xsd:appinfo>
				<a:since>3.6</a:since>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="description" type="xsd:string" minOccurs="0"/>
        	<xsd:element name="allowSameTarget" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="true">
			    <xsd:annotation>
			        <xsd:documentation>
			            Constraint all assignments that have the same target. I.e. multiple assignments
			            of the same (abstract) role.
			            If allowSameTarget=true then multiple assignments of the same role are allowed.
			            If allowSameTarget=false then multiple assignments of the same role are prohibited.
			            (but see also other constraints in this type)
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<xsd:element name="allowSameRelation" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="true">
			    <xsd:annotation>
			        <xsd:documentation>
			            Constraint all assignments that have the same relation.
			            E.g. if allowSameTarget=true and allowSameRelation=false then multiple assignments
			            of the same role are allowed as long as they have different relation.
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<!-- TODO: prohibitSameOrg, prohibitSameTenant, parameter prohibitions -->
        </xsd:sequence>
    </xsd:complexType>
        
    <xsd:complexType name="ObjectCollectionsUseType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies a set of object collections ("views") to be displayed (used) at
                a specific location in the system.
                This is generic type that can be used to specify collections to display
                in role catalog, menu, dashboard and so on.
            </xsd:documentation>
	        <xsd:appinfo>
				<a:since>3.6</a:since>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="collection" type="tns:ObjectCollectionUseType" minOccurs="0" maxOccurs="unbounded">
			    <xsd:annotation>
			        <xsd:documentation>
			            Reference to the colleciot, its visibility, etc.
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<!-- TODO: other elements that influence the way how the whole collection set
			           is displayed or how the collection sets configuration is merged. -->
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ObjectCollectionUseType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies how a specific collection ("view") is to be displayed (used) at
                a specific location in the system.
                This is generic type that can be used to specify collection to display
                in role catalog, menu, dashboard and so on.
            </xsd:documentation>
	        <xsd:appinfo>
				<a:since>3.6</a:since>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="collectionUri" type="xsd:anyURI" minOccurs="0">
			    <xsd:annotation>
			        <xsd:documentation>
			            Reference to the built-in collection.
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<!-- TODO: visibility, ordering, etc. -->
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="PolicyRuleType">
        <xsd:annotation>
            <xsd:documentation>
                These rules specify compliance and governance constraints.
                E.g. role exclusion (SoD), number of assignees, 
                approvals, remediation, etc.
                
                This is the form suitable for use in assignments/inducements.
            </xsd:documentation>
            <xsd:appinfo>
				<a:since>3.5</a:since>
				<a:experimental>true</a:experimental>
				<a:container>true</a:container>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Name of the rule. It is used to record processing of the rule
    					in the logfiles and for similar diagnostic reasons.
    				</xsd:documentation>
    				<xsd:appinfo>
		            	<a:displayName>PolicyRuleType.name</a:displayName>
		            	<a:help>PolicyRuleType.name.help</a:help>
                   	</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
        	<xsd:element name="description" type="xsd:string" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Free-form description of the rule (comment).
    				</xsd:documentation>
    				<xsd:appinfo>
		            	<a:displayName>PolicyRuleType.description</a:displayName>
		            	<a:help>PolicyRuleType.description.help</a:help>
                   	</xsd:appinfo>
    			</xsd:annotation>
        	</xsd:element>
 		    <xsd:element name="policyConstraints" type="tns:PolicyConstraintsType">
    			<xsd:annotation>
    				<xsd:documentation>
    					Constraints to be applied to selected objects.
    				</xsd:documentation>
					<xsd:appinfo>
						<a:displayName>PolicyRuleType.policyConstraints</a:displayName>
						<a:help>PolicyRuleType.policyConstraints.help</a:help>
					</xsd:appinfo>
				</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="policySituation" type="xsd:anyURI" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Policy situation that is the result when this policy rule is
    					triggered. If the situation is not explicitly stated then
    					default situation will be selected instead. The situation
    					is determined by the constraint that triggered the rule.
    				</xsd:documentation>
					<xsd:appinfo>
						<a:displayName>PolicyRuleType.policySituation</a:displayName>
						<a:help>PolicyRuleType.policySituation.help</a:help>
					</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="policyActions" type="tns:PolicyActionsType" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Action(s) that has to be takes as a reaction to this rule being
    					triggered.
    				</xsd:documentation>
					<xsd:appinfo>
						<a:displayName>PolicyRuleType.policyActions</a:displayName>
						<a:help>PolicyRuleType.policyActions.help</a:help>
					</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
    		<xsd:element name="evaluationTarget" type="tns:PolicyRuleEvaluationTargetType" minOccurs="0">
    			<xsd:annotation>
    				<xsd:documentation>
    					Whether this rule has to be applied on an object or an assignment. Normally this is determined
						by looking at policy constraints. But this setting can be used to override that.
    				</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.7</a:since>
						<a:displayName>PolicyRuleType.evaluationTarget</a:displayName>
						<a:help>PolicyRuleType.evaluationTarget.help</a:help>
					</xsd:appinfo>
    			</xsd:annotation>
    		</xsd:element>
        </xsd:sequence>
    </xsd:complexType>

	<xsd:simpleType name="PolicyRuleEvaluationTargetType">
		<xsd:annotation>
			<xsd:documentation>
				On what target is the policy rule intended to be evaluated.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="object">
				<xsd:annotation>
					<xsd:documentation>
						The rule is to be evaluated against an object.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="OBJECT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="assignment">
				<xsd:annotation>
					<xsd:documentation>
						The rule is to be evaluated against an assignment.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="ASSIGNMENT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
    
    <xsd:complexType name="GlobalPolicyRuleType">
        <xsd:annotation>
            <xsd:documentation>
                Policy rule for use in global configuration.
            </xsd:documentation>
            <xsd:appinfo>
				<a:since>3.5</a:since>
				<a:container>true</a:container>
			</xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:PolicyRuleType">
		        <xsd:sequence>
		        	<xsd:element name="focusSelector" type="tns:ObjectSelectorType" minOccurs="0">
		    			<xsd:annotation>
		    				<xsd:documentation>
		    					Selector for focus object. This is the object that is being changed
		    					(in object modification situations) or the focus object that contains
		    					the assignments (in assignment/inducement situations).
		    				</xsd:documentation>
		    			</xsd:annotation>
		    		</xsd:element>
		        	<xsd:element name="targetSelector" type="tns:ObjectSelectorType" minOccurs="0">
		    			<xsd:annotation>
		    				<xsd:documentation>
		    					Selector for assignment/inducement target object. It is used only in
		    					assignment situations.
		    				</xsd:documentation>
		    			</xsd:annotation>
		    		</xsd:element>
		 		    <xsd:element name="condition" type="tns:MappingType" minOccurs="0">
		                <xsd:annotation>
		                    <xsd:documentation>
		                        The rule is applied only if the condition is evaluated to true.
		                        If condition is not present, it is assumed to be always true.
		                    </xsd:documentation>
		                </xsd:annotation>
		            </xsd:element>
		        </xsd:sequence>
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:simpleType name="PolicyConstraintKindType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="exclusion">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXCLUSION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="minAssigneesViolation">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MIN_ASSIGNEES_VIOLATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="maxAssigneesViolation">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAX_ASSIGNEES_VIOLATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="objectModification">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OBJECT_MODIFICATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="assignmentModification">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASSIGNMENT_MODIFICATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="assignment">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASSIGNMENT"/>
						<a:deprecated>true</a:deprecated>
						<a:deprecatedSince>3.7</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="hasAssignment">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HAS_ASSIGNMENT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="hasNoAssignment">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HAS_NO_ASSIGNMENT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="objectTimeValidity">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OBJECT_TIME_VALIDITY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="assignmentTimeValidity">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASSIGNMENT_TIME_VALIDITY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="objectState">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OBJECT_STATE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="assignmentState">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASSIGNMENT_STATE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="situation">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SITUATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="transition">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TRANSITION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="and">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AND"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="or">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="not">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NOT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
       </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="SecurityPolicyType">
        <xsd:annotation>
            <xsd:documentation>
                System that contains definitions of overall security policy.
                It contains configuration of authentication mechanisms, credentials management
                (such as password resets) and so on.
                Please note that this NOT contain authorization and auditing. Authorization is
                defined in roles (see RoleType) and auditing has a separate configuration.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ObjectType">
                <xsd:sequence>
                	<xsd:element name="authentication" type="tns:AuthenticationsPolicyType" minOccurs="0">
                	</xsd:element>
                	<xsd:element name="credentials" type="tns:CredentialsPolicyType" minOccurs="0">
                	</xsd:element>
                	<xsd:element name="registration" type="tns:RegistrationsPolicyType" minOccurs="0">
                	</xsd:element>
                	<xsd:element name="credentialsReset" type="tns:CredentialsResetPolicyType" minOccurs="0">
                	</xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="securityPolicy" type="tns:SecurityPolicyType" substitutionGroup="c:object"/>
    
    <xsd:complexType name="AuthenticationsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of the use of authentication mechanisms. This is in fact practically
				applicable only in default security policy (the policy that is referenced from
				system configuration).
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="mailAuthentication" type="tns:MailAuthenticationPolicyType" minOccurs="0" maxOccurs="unbounded">
			</xsd:element>
			<xsd:element name="smsAuthentication" type="tns:SmsAuthenticationPolicyType" minOccurs="0" maxOccurs="unbounded">
             </xsd:element>
			<!-- TODO: radovan -->
		</xsd:sequence>
	</xsd:complexType>
    
    <xsd:complexType name="CredentialsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Credentials management policy. It specifies the management details for each supported
				credentials type. It defines parameters such as credential lifetime. It may define even
				a very complex schemes for some credential types. E.g. it may define a complete security
				questions.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="default" type="tns:CredentialPolicyType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Common setting applied to all other credetials type. Any of this
						setting can be overridden in the individual credentials setting.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="password" type="tns:PasswordCredentialsPolicyType" minOccurs="0">
			</xsd:element>
			<xsd:element name="securityQuestions" type="tns:SecurityQuestionsCredentialsPolicyType" minOccurs="0">
             </xsd:element>
             <xsd:element name="nonce" type="tns:NonceCredentialsPolicyType" minOccurs="0" maxOccurs="unbounded">
             	<xsd:annotation>
					<xsd:documentation>
						Nonce settings used to generate one-time random values.
						Used in self-registration, e-mail-based password reset and possibly also
						other scenarios.
					</xsd:documentation>
				</xsd:annotation>
             </xsd:element>
             <!-- More credential types may come here in the future. -->
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="RegistrationsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Credentials management policy. It specifies the management details for each supported
				credentials type. It defines parameters such as credential lifetime. It may define even
				a very complex schemes for some credential types. E.g. it may define a complete security
				questions.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="selfRegistration" type="tns:SelfRegistrationPolicyType" minOccurs="0">
			</xsd:element>
             <!-- More registration types may come here in the future. -->
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="CredentialsResetPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Credentials reset management policy. It specifies the management details for each supported
				credentials reset type. It defines parameters such as reset method. 
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
		<xsd:element name="name" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="securityQuestionReset" type="tns:SecurityQuestionsResetPolicyType" minOccurs="0">
			</xsd:element>
			<xsd:element name="mailReset" type="tns:MailResetPolicyType" minOccurs="0">
			</xsd:element>
			<xsd:element name="smsReset" type="tns:SmsResetPolicyType" minOccurs="0">
			</xsd:element>
			
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="AbstractAuthenticationPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Authentication management policy. It specifies configurations for differrent authentication methods
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="notificationConfiguration" type="tns:NotificationConfigurationType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                A configuration for user notifications. In future, it might be overriden e.g. at a level
                                of a user.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
			<xsd:element name="name" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="displayName" type="xsd:string" minOccurs="0">
			</xsd:element>
             <!-- More registration types may come here in the future. -->
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="AbstractCredentialsResetPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Authentication management policy. It specifies configurations for differrent authentication methods
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="displayName" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="additionalAuthenticationName" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="formRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
					    <xsd:annotation>
					        <xsd:documentation>
					            Reference to form which is dispalyed for registration
					        </xsd:documentation>
					        <xsd:appinfo>
								<a:objectReferenceTargetType>tns:FormType</a:objectReferenceTargetType>
							</xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>
             <!-- More registration types may come here in the future. -->
		</xsd:sequence>
	</xsd:complexType>
	
	 <xsd:complexType name="SecurityQuestionsResetPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractCredentialsResetPolicyType">
				<xsd:sequence>
					
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="MailResetPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractCredentialsResetPolicyType">
				<xsd:sequence>
			
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="SmsResetPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractCredentialsResetPolicyType">
				<xsd:sequence>
				
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	 <xsd:complexType name="MailAuthenticationPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractAuthenticationPolicyType">
				<xsd:sequence>
					<xsd:element name="mailNonce" type="xsd:string" minOccurs="0">
			</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="SmsAuthenticationPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractAuthenticationPolicyType">
				<xsd:sequence>
					<xsd:element name="smsNonce" type="xsd:string" minOccurs="0">
			</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	
	<xsd:complexType name="AbstractRegistrationPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Credentials management policy. It specifies the management details for each supported
				credentials type. It defines parameters such as credential lifetime. It may define even
				a very complex schemes for some credential types. E.g. it may define a complete security
				questions.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="initialLifecycleState" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="requiredLifecycleState" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="displayName" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="additionalAuthenticationName" type="xsd:string" minOccurs="0">
			</xsd:element>
			<xsd:element name="defaultRole" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
			        <xsd:documentation>
			            Reference to the default roles which will be assigned to the user automatically after registration
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:objectReferenceTargetType>tns:AbstractRoleType</a:objectReferenceTargetType>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
             <!-- More registration types may come here in the future. -->
		</xsd:sequence>
	</xsd:complexType>
	
	 <xsd:complexType name="SelfRegistrationPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractRegistrationPolicyType">
				<xsd:sequence>
					<xsd:element name="formRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
					    <xsd:annotation>
					        <xsd:documentation>
					            Reference to form which is dispalyed for registration
					        </xsd:documentation>
					        <xsd:appinfo>
								<a:objectReferenceTargetType>tns:FormType</a:objectReferenceTargetType>
							</xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	
	 <xsd:complexType name="CredentialPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies common elements to all the credential policies.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="storageMethod" type="c:CredentialsStorageMethodType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Method used to store the values of this credential (encrypted, hashed, ...)
						If storage method is not specified it defaults to encryption
						(due to compatibility and convenience reasons).
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="resetMethod" type="c:CredentialsResetMethodType" minOccurs="0" maxOccurs="1">
			</xsd:element>
			<xsd:element name="propagationUserControl" type="c:CredentialsPropagationUserControlType" minOccurs="0" maxOccurs="1" default="userChoice">
				<xsd:annotation>
					<xsd:documentation>
						Constraints that define how propagation of the credentials can be controlled by the
						user. E.g. if user can choose where the password change will be propagated.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="minOccurs" type="xsd:string" minOccurs="0" default="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Minimal number of value occurrences. minOccurs set to zero means that the value
            			is optional.
            			E.g. when applied to passwords the minOccurs=0 means that the policy will
            			accept no password at all. But it will still validate the password using
            			stringPolicy if a password is present.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
            <xsd:element name="maxOccurs" type="xsd:string" minOccurs="0">
            	<xsd:annotation>
            		<xsd:documentation>
            			Maximal number of value occurences.
            			If not specified then the default schema limitation is imposed.
            		</xsd:documentation>
            	</xsd:annotation>
            </xsd:element>
			<xsd:element name="maxAge" type="xsd:duration" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Maximum age of the credential, counted from the last credential value update.
						The credential must not be used after the age is exceeded (it is expired).
						Any authentication with such credential must fail.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="minAge" type="xsd:duration" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Minimum age of the credential, counted from the last credential value update.
						The credential cannot be changed before its minimal age is reached.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="warningBeforeExpirationDuration" type="xsd:duration" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						The time interval before credential expiration (exceeded maxAge) that the user will be
						warned that the credential is about to expire.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="lockoutMaxFailedAttempts" type="xsd:int" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Maximum number of failed authentication attempts that can be tried before the credential
						is locked-out.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="lockoutFailedAttemptsDuration" type="xsd:duration" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						The duration in which the failed attemps must happen for the credential to be locked-out.
						The failed attempt counter is re-set after this duration (counted from the last failed attempt).
						The credential is NOT locked-out during this duration.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="lockoutDuration" type="xsd:duration" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						The duration for which the credential remains locked-out. The credential is automatically
						unlocked after this duration.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="valuePolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
			    <xsd:annotation>
			        <xsd:documentation>
			            Reference to the value policy for the credential.
			        </xsd:documentation>
			        <xsd:appinfo>
						<a:objectReferenceTargetType>tns:ValuePolicyType</a:objectReferenceTargetType>
					</xsd:appinfo>
			    </xsd:annotation>
			</xsd:element>
			<xsd:element name="historyLength" type="xsd:int" minOccurs="0" maxOccurs="1" default="0">
			    <xsd:annotation>
			        <xsd:documentation>
			            The number of entries to keep in the credential history. Also specifies the
			            number of past credential values that will be checked before accepting a new
			            credential change.
			        </xsd:documentation>
			    </xsd:annotation>
			</xsd:element>
			<xsd:element name="historyStorageMethod" type="c:CredentialsStorageMethodType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Method used to store historical values of the credential (encrypted, hashed, ...)
						If storage type is not specified then it defaults to hashing.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<!-- TODO: similarity criteria (history vs new password) -->
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:simpleType name="CredentialsPropagationUserControlType">
        <xsd:annotation>
            <xsd:documentation>
                Constraintes that define how propagation of credentials can be controled by the
						user. E.g. if user can choose where the password change will be propagated.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="mapping">
                <xsd:annotation>
                	<xsd:documentation>
                		Credentials propagation will be determined by the mappings.
                		User cannot choose where the credentials will be propagated.
                		The credentials propagation dialog will not be shown.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAPPING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="userChoice">
                <xsd:annotation>
                	<xsd:documentation>
                		The user can choose where the credentials will be propagated.
                		The propagation dialog will be shown.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="USER_CHOICE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
	
	<xsd:complexType name="CredentialsResetMethodType">
		<xsd:annotation>
			<xsd:documentation>
				Specifies the method of resetting the credential. This usually applies to a
				self-service credential reset.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="resetType" type="c:CredentialsResetTypeType" minOccurs="0" maxOccurs="1" default="none">
				<xsd:annotation>
					<xsd:documentation>
						The type of credential reset.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	
    <xsd:simpleType name="CredentialsResetTypeType">
        <xsd:annotation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                	<xsd:documentation>
                		Credential reset is disabled.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="mail">
                <xsd:annotation>
                	<xsd:documentation>
                		Use security questions to reset the credential.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAIL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="sms">
                <xsd:annotation>
                	<xsd:documentation>
                		Use security questions to reset the credential.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SMS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="securityQuestions">
                <xsd:annotation>
                	<xsd:documentation>
                		Use security questions to reset the credential.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SECURITY_QUESTIONS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             <xsd:enumeration value="securityQuestionsWithEmail">
                <xsd:annotation>
                	<xsd:documentation>
                		Use security questions to reset the credential.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SECURITY_QUESTIONS_EMAIL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
             </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="CredentialsStorageMethodType">
		<xsd:annotation>
			<xsd:documentation>
				Specifies the method of storing the credential in midPoint.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="storageType" type="c:CredentialsStorageTypeType" minOccurs="0" maxOccurs="1" default="encryption">
				<xsd:annotation>
					<xsd:documentation>
						The type of credential storage.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<!-- Storage parameters (ciphers, digest methods, key lengths, ... -->
		</xsd:sequence>
	</xsd:complexType>
	
    <xsd:simpleType name="CredentialsStorageTypeType">
        <xsd:annotation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="encryption">
                <xsd:annotation>
                	<xsd:documentation>
                		Credential will be stored in an encrypted form.
                		This is a symmetric (reversible) encryption.
                		MidPoint will be able to get a cleartext form of
                		the credential if needed.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ENCRYPTION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="hashing">
                <xsd:annotation>
                	<xsd:documentation>
                		Credential will be stored in a hashed form.
                		One-way (irreversible) cryptographic hash or key derivation function
                		will be used to transform the credential before storage.
                		MidPoint will NOT be able to get a cleartext form of
                		the credential, but it can still compare credential values.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HASHING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="none">
                <xsd:annotation>
                	<xsd:documentation>
                		MidPoint will not store the credential at all.
                		MidPoint will only work with credential in the memory
                		while it is needed to complete current operation.
                		The credential will be discarded after the operation.
                		
                		THIS IS ONLY PARTIALLY SUPPORTED
                		
                		MidPoint should be able not to store the credentials when
                		this setting is used. But there may be side effects
                		that are not completely addressed yet.
                		This is not entirelly tests and not supported.
                		Use at your own risk.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
    </xsd:restriction>
    </xsd:simpleType>

	 <xsd:complexType name="PasswordCredentialsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for password management. It is in fact only a simple reference
				to a password policy.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:CredentialPolicyType">
				<xsd:sequence>
					<xsd:element name="passwordPolicyRef" type="c:ObjectReferenceType" minOccurs="0" maxOccurs="1">
					    <xsd:annotation>
					        <xsd:documentation>
					            Reference to the password policy settings.
					            DEPRECATED. Use valuePolicyRef instead.
					        </xsd:documentation>
					        <xsd:appinfo>
								<a:objectReferenceTargetType>tns:ValuePolicyType</a:objectReferenceTargetType>
								<a:deprecated>true</a:deprecated>
							</xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>
					<xsd:element name="passwordChangeSecurity" type="c:PasswordChangeSecurityType" minOccurs="0" default="oldPassword">
						<xsd:annotation>
							<xsd:documentation>
								Additional security applied when changing a password.
								This applies when user is changing his own password. It does NOT apply
								when administrator changes password of other user.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="passwordHistoryLength" type="xsd:int" minOccurs="0" maxOccurs="1">
					    <xsd:annotation>
					        <xsd:documentation>
					            The number of entries to keep in the password history. Also specifies the
					            number of past passwords that will be checked before accepting a new password
					            change.
					            DEPRECATED. use historyLength instead.
					            This is not even implemented. It does not work.
					        </xsd:documentation>
					        <xsd:appinfo>
					        	<a:deprecated>true</a:deprecated>
					        </xsd:appinfo>
					    </xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:simpleType name="PasswordChangeSecurityType">
        <xsd:annotation>
            <xsd:documentation>
                Additional security applied when changing a password.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                	<xsd:documentation>
                		No additional security. Password can be changed by supplying new value.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="oldPassword">
                <xsd:annotation>
                	<xsd:documentation>
                		User must supply old password to change the password.
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OLD_PASSWORD"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
	
	<xsd:complexType name="SecurityQuestionsCredentialsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for security questions. It actually contains text for the
				questions (or rather a reference to localization catalog file). But it also contains a policy
				how the questions can be used, e.g. how many questions to display to a user.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:CredentialPolicyType">
				<xsd:sequence>
					   <xsd:element name="questionNumber" type="xsd:int" minOccurs="0"  maxOccurs="1">
		                <xsd:annotation>
		                    <xsd:documentation>
		                       Number of Questions in order to change the passwords
		                    </xsd:documentation>
		                </xsd:annotation>
		            </xsd:element>
					 <xsd:element name="question" type="tns:SecurityQuestionDefinitionType" minOccurs="0" maxOccurs="unbounded">
					 	<xsd:annotation>
					 		<xsd:documentation>
					 			The set of all the security questions in this policy.
					 		</xsd:documentation>
					 	</xsd:annotation>
					 </xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="SecurityQuestionDefinitionType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of a single security question.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="identifier" type="xsd:anyURI">
				<xsd:annotation>
					<xsd:documentation>
						Unique identified of a security question. This can be used in the answer to refer to this
						definition (see SecurityQuestionAnswerType).
						
						It is expected that midPoint will come with a pre-configured set of frequently used security
						questions (such as "what is your mother's maiden name?"). Therefore URI is a good mechanism for
						this identifier. URI has a natural namespacing. Which means that the identifiers of built-in
						questions will not clash with identifiers of questions configured by midPoint administrators.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="enabled" type="xsd:boolean" minOccurs="0" default="true">
				<xsd:annotation>
					<xsd:documentation>
						Simple flag that could be used to disable a use of a specific question without actually
						deleting it. This may be used to select only some questions, e.g. to disable the low-security
						built-in questions such as "what is your mother's maiden name?".
						If not present at all then the question is assumed to be enabled.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="questionText" type="xsd:string" maxOccurs="1">
        	    <xsd:annotation>
                    <xsd:documentation>
                        The question itself, or the localization identifier to it.
                    </xsd:documentation>
                </xsd:annotation>
        	</xsd:element>
			<!-- TODO: sabri 
				settings that apply to a specific security question should go here, like this:
				<xsd:element name="something" type="xsd:string" minOccurs="0"/>
				What comes to my mind here is a key to localization file. That definitelly should be here.
				What else?
			 -->
			 <!-- In later versions we may want to add an expression here. The expression could product an expected answer
			 to the question. This can work well for questions such as "what is your employee number?". We already store
			 employee number in each user therefore there is no need for each user to manually fill-in the expected answer.
			 We can use expression instead. Something like "$user/employeeNumber" -->
		</xsd:sequence>
	</xsd:complexType>
	
	 <xsd:complexType name="NonceCredentialsPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Structure that specifies policy for nonce management.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:CredentialPolicyType">
				<xsd:sequence>
					<xsd:element name="name" type="xsd:string" maxOccurs="1">
		        	    <xsd:annotation>
		                    <xsd:documentation>
		                        TODO
		                    </xsd:documentation>
		                </xsd:annotation>
		        	</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

    <xsd:simpleType name="SystemObjectsType">
        <xsd:annotation>
            <xsd:documentation>
                OID constants for system objects
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="00000000-0000-0000-0000-000000000001">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SYSTEM_CONFIGURATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000002">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="USER_ADMINISTRATOR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000003">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PASSWORD_POLICY_DEFAULT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000004">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ROLE_SUPERUSER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000005">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TASK_CLEANUP"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000006">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TASK_VALIDITY_SCANNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000007">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TASK_TRIGGER_SCANNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000008">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ROLE_END_USER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000009">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_AUDIT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-00000000000a">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ROLE_APPROVER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-00000000000b">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ROLE_REVIEWER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-00000000000c">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ROLE_DELEGATOR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000100">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_RECONCILIATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000107">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_USER_ACCOUNTS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000108">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_USER_ORGS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000109">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_USER_ROLES"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000110">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_USERS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000111">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REPORT_SHADOW_OWNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000120">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SECURITY_POLICY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000200">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOOKUP_LANGUAGES"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000210">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOOKUP_LOCALES"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000220">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOOKUP_TIMEZONES"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="00000000-0000-0000-0000-000000000230">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LOOKUP_LIFECYCLE_STATES"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="FailedOperationTypeType">
        <xsd:annotation>
            <xsd:documentation>
                The enum describes the operation during the account was processed.
                But the operation failed and the account was not sucessfully treated
                so the account should have the information about the type of failed operation.
                E.g. the account should be deleted, but it fails. The account needs to be
                assigned with the tombstone to be deleted later.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="delete">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DELETE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="add">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ADD"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="get">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="GET"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="modify">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MODIFY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>


    <xsd:complexType name="CleanupPoliciesType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of cleanup intervals and policies for various midPoint subsystems.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="auditRecords" type="tns:CleanupPolicyType" minOccurs="0"/>
            <xsd:element name="closedTasks" type="tns:CleanupPolicyType" minOccurs="0" />
            <xsd:element name="closedCertificationCampaigns" type="tns:CleanupPolicyType" minOccurs="0" />
            <xsd:element name="outputReports" type="tns:CleanupPolicyType" minOccurs="0" />
			<xsd:element name="objectResults" type="tns:CleanupPolicyType" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="CleanupPolicyType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of cleanup intervals and policies for a specific subsystem or feature.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="maxAge" type="xsd:duration" minOccurs="0"/>
            <xsd:element name="maxRecords" type="xsd:int" minOccurs="0"/>
        </xsd:sequence>
    </xsd:complexType>

    <!-- Things relevant to model context serialization - more precisely, those parts that are publicly visible
(i.e. their java counterparts are - or could be - contained in model-api) -->

    <xsd:simpleType name="ModelStateType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="initial">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="INITIAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="primary">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PRIMARY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="secondary">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SECONDARY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="execution">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXECUTION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="postexecution">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="POSTEXECUTION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="final">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FINAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

	<xsd:complexType name="SelectorQualifiedGetOptionsType">
		<xsd:annotation>
			<xsd:documentation>
				Selector-qualified options for a get-like operation.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="option" type="tns:SelectorQualifiedGetOptionType" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="SelectorQualifiedGetOptionType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="selector" type="tns:OptionObjectSelectorType" minOccurs="0" maxOccurs="1"/>
			<xsd:element name="options" type="tns:GetOperationOptionsType" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="OptionObjectSelectorType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="path" type="t:ItemPathType" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="GetOperationOptionsType">
		<xsd:annotation>
			<xsd:documentation>
				See GetOperationOptions for a description.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="retrieve" type="tns:RetrieveOptionType" minOccurs="0"/>
			<xsd:element name="resolve" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="resolveNames" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="noFetch" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="raw" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="tolerateRawData" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="noDiscovery" type="xsd:boolean" minOccurs="0"/>		<!-- should be named 'doNotDiscovery' -->
			<xsd:element name="allowNotFound" type="xsd:boolean" minOccurs="0"/>
			<!-- readOnly is quite an internal flag, doesn't make sense to externalize it -->
			<xsd:element name="pointInTimeType" type="tns:PointInTimeTypeType" minOccurs="0"/>
			<xsd:element name="staleness" type="xsd:long" minOccurs="0"/>
			<xsd:element name="distinct" type="xsd:boolean" minOccurs="0"/>
			<xsd:element name="definitionProcessing" type="tns:DefinitionProcessingOptionType" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="RetrieveOptionType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="default">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="DEFAULT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="include">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="INCLUDE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="exclude">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="EXCLUDE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:simpleType name="PointInTimeTypeType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="cached">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="CACHED"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="current">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="CURRENT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="future">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="FUTURE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	
	<xsd:simpleType name="DefinitionProcessingOptionType">
		<xsd:annotation>
			<xsd:documentation>
				How should be definitions processed when object is to be retrieved. Currently applies at the model level;
				but in the future it might be used also elsewhere.
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
				<a:since>3.7.1</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="full">
				<xsd:annotation>
					<xsd:documentation>
						Full definition processing for the specified item(s) is to be done.
						This applies recursively also to sub-items.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="FULL"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="onlyIfExists">
				<xsd:annotation>
					<xsd:documentation>
						 Full definition processing for the specified item(s) is to be done, but only if the item(s) exist.
						 This applies recursively also to sub-items.
						 
						 Currently supported on root level only.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="ONLY_IF_EXISTS"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="none">
				<xsd:annotation>
					<xsd:documentation>
						Definition for the specified item(s) is to be excluded from the resulting object, even if the item(s) do exist.
						
						NOT IMPLEMENTED YET
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="NONE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	

	<xsd:simpleType name="IterationMethodType">
		<xsd:annotation>
			<xsd:documentation>
				How to iterate through entities in searchObjectsIterative method.
				Can be used to avoid long-running transactions in some cases.
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="default">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="DEFAULT"/>
						<xsd:documentation>
							Uses the default method configured for the particular database.
							For H2, MySQL/MariaDB the default is to emulate iteration via paging,
							for other databases it is traditional sequential read.
						</xsd:documentation>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="singleTransaction">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="SINGLE_TRANSACTION"/>
						<xsd:documentation>
							Fetches objects in single DB transaction. Not supported for all DBMSs.
						</xsd:documentation>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="simplePaging">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="SIMPLE_PAGING"/>
						<xsd:documentation>
							Uses the "simple paging" method: takes objects (e.g.) numbered 0 to 49, then 50 to 99,
							then 100 to 149, and so on. The disadvantage is that if the order of objects is changed
							during operation (e.g. by inserting/deleting some of them) then some objects can be
							processed multiple times, where others can be skipped.
						</xsd:documentation>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="strictlySequentialPaging">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="STRICTLY_SEQUENTIAL_PAGING"/>
						<xsd:documentation>
							Uses the "strictly sequential paging" method: sorting returned objects by OID. This
							is (almost) reliable in such a way that no object would be skipped. However, custom
							paging cannot be used in this mode.
						</xsd:documentation>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:complexType name="ModelExecuteOptionsType">
        <xsd:annotation>
            <xsd:documentation>
                Options for execution of Model operations. These options influence the way how the operations are executed.
                The options are not mandatory. All options have reasonable default values. They may not be specified at all.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="force" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Force the operation even if it would otherwise fail due to external failure. E.g. attempt to delete an account
                        that no longer exists on resource may fail without a FORCE option. If FORCE option is used then the operation is
                        finished even if the account does not exist (e.g. at least shadow is removed from midPoint repository).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="raw" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Avoid any smart processing of the data except for schema application. Do not synchronize the data, do not apply
                        any expressions, etc.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="noCrypt" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Avoid encryption of any cleartext data on write. Applies only to the encrypted
                        data formats (ProtectedString, ProtectedByteArray).
                        It is not recommended to use in production environment. This option is provided only for diagnostic
						purposes to be used in development environments.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="reconcile" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to reconcile focus and all projections while executing changes.
						(implies reconcileFocus)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="reconcileFocus" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to reconcile focus while executing changes.
						If this option is set and the reconcile option is not set then the projections
						reconciliation will not be forced (but it may still happen if other configuration
						loads full projection).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="reconcileAffected" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to reconcile affected objects after executing changes.
                        Typical use: after a role is changed, all users that have been assigned this role
                        would be reconciled.

                        Because it is difficult to determine all affected objects (e.g. users that have
                        indirectly assigned a role), midPoint does a reasonable attempt to determine
                        and reconcile them. E.g. it may be limited to a direct assignees.

                        Also, because of time complexity, the reconciliation may be executed in
                        a separate background task.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="executeImmediatelyAfterApproval" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to execute changes as soon as they are approved. (For the primary stage approvals, the default behavior
                        is to wait until all changes are approved/rejected and then execute the operation as a whole.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="overwrite" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to user overwrite flag. It can be used from web service, if we want to re-import some object
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="isImport" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to simulate import operation. E.g. search filters will be resolved.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="limitPropagation" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Option to limit change computation and execution only for the source resource.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="reevaluateSearchFilters" type="xsd:boolean" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Causes reevaluation of search filters.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="requestBusinessContext" type="tns:OperationBusinessContextType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Business context that describes this request.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="partialProcessing" type="tns:PartialProcessingOptionsType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Options that control selective execution of model logic.
                        Use with extreme care. Some combinations may be dangerous.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="focusConflictResolution" type="tns:ConflictResolutionType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						A method to resolve conflicts on focus objects. This specifies how will the 
						processors handle optimistic locking conflicts - and whether they even try
						to detect them. The default value is null, which means that there is no reaction
						to conflicts and that the conflicts are not even detected.
						Note that different default conflict resolution may be specified in system configuration.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6.1</a:since>
						<a:experimental>true</a:experimental>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="modelExecuteOptions" type="tns:ModelExecuteOptionsType"/>
    
    <xsd:complexType name="OperationBusinessContextType">
        <xsd:annotation>
            <xsd:documentation>
                The business context of an operation. This structure contains data about the operation that bind it to the
                business process or other non-information environment. It contains data such as free-form comment of the
                affected user (requester, approver) it may contain references to other business documents that are outside
                of the IDM scope (e.g. reference to the support contract or employee contact number), etc.
                It is designed for future extensibility.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element ref="tns:extension" minOccurs="0">
        		<xsd:annotation>
        			<xsd:documentation>
        				The extension for future dynamic extensibility.
        			</xsd:documentation>
        		</xsd:annotation>
        	</xsd:element>
            <xsd:element name="comment" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Free-form comment of the affected person. If this business context describe the request then
                        this is the requestor comment. If the context describes approval step then this is approver
                        comment. The comment is expected to be a short comment justifying the request, explaining
                        the decision and so on. It is supposed to be few lines of text at the most.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO: we may want to add more generic fields here in the future. E.g. contract reference (contract number) may be a good addition. -->
        </xsd:sequence>
   </xsd:complexType>

	<xsd:complexType name="PartialProcessingOptionsType">
        <xsd:annotation>
            <xsd:documentation>
                Options that allows to select only some of the projector/clockwork parts to process. 
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="load" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="focus" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="inbound" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="focusActivation" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="objectTemplateBeforeAssignments" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="assignments" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="assignmentsOrg" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="assignmentsMembershipAndDelegate" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="assignmentsConflicts" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="objectTemplateAfterAssignments" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="focusCredentials" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="focusPolicyRules" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="projection" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="outbound" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="projectionValues" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="projectionCredentials" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="projectionReconciliation" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="projectionLifecycle" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="approvals" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="execution" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>
            <xsd:element name="notification" type="tns:PartialProcessingTypeType" minOccurs="0" default="automatic"/>            
        </xsd:sequence>
   </xsd:complexType>
   <xsd:element name="partialProcessingOptions" type="tns:PartialProcessingOptionsType">
       <xsd:annotation>
           <xsd:documentation>
               Business context that describes this request.
               Global element - for use in task extension.
           </xsd:documentation>
       </xsd:annotation>
   </xsd:element>

    <xsd:simpleType name="PartialProcessingTypeType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies whether a particular part should be processed or not.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="automatic">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
                			Process the part if it would be processed normally.
							This is automatic behavior that leaves the decision
							to the code. This means that all usual parts of the
							code will be processed. 
							This is the default option.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="AUTOMATIC"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="skip">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
	                		Skip processing of a particular part.
							Do NOT process it. This setting can be
							used to skip particular parts that would
							be normally processed. However, using this
							option may cause errors and/or wrong results.
							Use with care.
                		</p>
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SKIP"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="process">
                <xsd:annotation>
                	<xsd:documentation>
                		<p>
							Process particular part. This setting can be used
							to turn on processing of optional parts of the code
							or to override the automatic behavior.
                		</p> 
                	</xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PROCESS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>


	<xsd:complexType name="ModelCompareOptionsType">
		<xsd:annotation>
			<xsd:documentation>
				EXPERIMENTAL.
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="computeCurrentToProvided" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Computes current-to-provided delta. ("Current" means the object that is currently available in the midPoint.)
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="computeProvidedToCurrent" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Computes provided-to-current delta.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="returnNormalized" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Returns the normalized version of provided object.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="returnCurrent" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Returns the current version of provided object.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ignoreOperationalItems" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Should the items marked as operational be ignored?
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="SynchronizationIntentType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="add">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ADD"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        New account that should be added (and linked).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="delete">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DELETE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that should be deleted (and unlinked)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="keep">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="KEEP"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that is kept as it is (remains linked).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unlink">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNLINK"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that should be unlinked (but NOT deleted).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="synchronize">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SYNCHRONIZE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that belongs to the user and needs to be synchronized.
                        This may include deleting, archiving or disabling the account.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="SynchronizationPolicyDecisionType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="add">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ADD"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        New account that is going to be added (and linked).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="delete">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DELETE"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that is going to be deleted (and unlinked).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="keep">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="KEEP"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that is kept as it is (remains linked).
                        Note: there still may be attribute or entitlement changes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unlink">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNLINK"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        Existing account that is going to be unlinked (but NOT deleted).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="broken">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="BROKEN"/>
                    </xsd:appinfo>
                    <xsd:documentation>
                        The account is not usable. E.g. because the associated shadow does
                        not exist any more, resource does not exists any more, etc.
                        Such account link will be removed.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ObjectDeltaOperationType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="objectDelta" type="t:ObjectDeltaType" minOccurs="0"/>
            <xsd:element name="executionResult" type="tns:OperationResultType" minOccurs="0"/>
            <xsd:element name="objectName" type="t:PolyStringType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Name of the object that was the target of this delta, if known.
                        As for other similar attributes, it may become obsolete.
                        Useful for informational purposes, typically in audit records.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="resourceOid" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        OID of the resource that is related to this operation - typically
                        if the object being processed is a shadow of a resource object.
                        Useful for informational purposes, typically in audit records.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="resourceName" type="t:PolyStringType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Name of the resource that is related to this operation - typically
                        if the object being processed is a shadow of a resource object.
                        As for other similar attributes, it may become obsolete.
                        Useful for informational purposes, typically in audit records.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <!-- TODO profiling Configuration -->
    <xsd:complexType name="ProfilingConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                A configuration for profiling features of midPoint.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="enabled" type="xsd:boolean" minOccurs="1" maxOccurs="1"/>
            <xsd:element name="requestFilter" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="performanceStatistics" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="dumpInterval" type="xsd:int" minOccurs="0" maxOccurs="1"/>
			<!-- Subsystems start -->
			<xsd:element name="model" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
			<xsd:element name="repository" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
			<xsd:element name="provisioning" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
			<xsd:element name="ucf" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        This profiling option is currently not supported.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
			<xsd:element name="synchronizationService" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
            <xsd:element name="resourceObjectChangeListener" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false">
                <xsd:annotation>
                    <xsd:documentation>
                        This profiling option is currently not supported. It was partially replaced by synchronizationService property.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="taskManager" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
            <xsd:element name="workflow" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
			<!-- Subsystems end -->
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="profilingConfiguration" type="tns:ProfilingConfigurationType"/>
	
    <!-- Report Types -->
    
    <xsd:simpleType name="ExportType">
        <xsd:annotation>
            <xsd:documentation>
                Report export type.
                pdf, csv, xml, xmlEmbed, html, rtf, xls, odt, ods, docx, xlsx, pptx, xhtml, jxl.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="pdf">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PDF"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="csv">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CSV"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="xml">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="XML"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="xmlEmbed">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="XML_EMBED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="html">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="HTML"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="rtf">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RTF"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="xls">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="XLS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="odt">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ODT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ods">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ODS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="docx">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DOCX"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="xlsx">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="XLSX"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="pptx">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PPTX"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="xhtml">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="XHTML"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="jxl">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="JXL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:simpleType name="OrientationType">
        <xsd:annotation>
            <xsd:documentation>
                Report orientation.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="landscape">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LANDSCAPE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="portrait">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PORTRAIT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>
    
    
    <xsd:complexType name="ReportFieldConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of report fields.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="nameReport" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="nameHeader" type="xsd:string" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="itemPath" type="t:ItemPathType" minOccurs="0"/>
            <xsd:element name="sortOrderNumber" type="xsd:int" minOccurs="0" maxOccurs="1"/>
            <xsd:element name="sortOrder" type="q:OrderDirectionType" minOccurs="0" maxOccurs="1"/>  
            <xsd:element name="width" type="xsd:int" minOccurs="0" maxOccurs="1" />
            <xsd:element name="classType" type="xsd:QName" minOccurs="0" maxOccurs="1"/>   
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="reportFieldConfiguration" type="tns:ReportFieldConfigurationType"/>
    
    <!--<xsd:complexType name="ReportTemplateType">-->
        <!--<xsd:sequence>-->
            <!--<xsd:any namespace="##other" processContents="lax">-->
                <!--<xsd:annotation>-->
                    <!--<xsd:documentation>-->
                        <!--&lt;!&ndash; TODO description &ndash;&gt;-->
                    <!--</xsd:documentation>-->
                <!--</xsd:annotation>-->
            <!--</xsd:any>-->
        <!--</xsd:sequence>-->
    <!--</xsd:complexType>-->

    <!--<xsd:complexType name="ReportTemplateStyleType">-->
        <!--<xsd:sequence>-->
            <!--<xsd:any namespace="##other" processContents="lax">-->
                <!--<xsd:annotation>-->
                    <!--<xsd:documentation>-->
                        <!--&lt;!&ndash; TODO description &ndash;&gt;-->
                    <!--</xsd:documentation>-->
                <!--</xsd:annotation>-->
            <!--</xsd:any>-->
        <!--</xsd:sequence>-->
    <!--</xsd:complexType>-->
    
    <xsd:complexType name="DataSourceType">
        <xsd:sequence>
            <xsd:element name="providerClass" type="xsd:string"/>
            <xsd:element name="springBean" type="xsd:boolean" default="false" minOccurs="0"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SubreportType">
        <xsd:sequence>
            <xsd:element name="name" type="xsd:string"/>
            <xsd:element name="reportRef" type="tns:ObjectReferenceType"/>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="ReportParameterType">
     <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
       <xsd:sequence>
            <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax">
            </xsd:any>
        </xsd:sequence>
    </xsd:complexType>
    
	<xsd:complexType name="ReportType">
	    <xsd:annotation>
            <xsd:documentation>
            	TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                    <xsd:element name="parent" type="xsd:boolean" default="true" minOccurs="0"/>
                    <xsd:element name="subreport" type="tns:SubreportType" minOccurs="0" maxOccurs="unbounded"/>
                    

                    <xsd:element name="template" type="xsd:base64Binary" minOccurs="0" maxOccurs="1" />
                    <xsd:element name="templateStyle" type="xsd:base64Binary" minOccurs="0" maxOccurs="1" />
                       
<!--                    	<xsd:element name="template" type="t:XmlAsStringType" minOccurs="0"/> -->
<!--                 	<xsd:element name="templateStyle" type="t:XmlAsStringType" minOccurs="0"/> -->
                    <xsd:element name="orientation" type="tns:OrientationType" minOccurs="0">
    				    <xsd:annotation>
                            <xsd:documentation>
                                Report page orientation.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="export" type="tns:ExportType" minOccurs="0">
    				<xsd:annotation>
                            <xsd:documentation>
                                File type which will be used during report export.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="useHibernateSession" type="xsd:boolean" default="false" minOccurs="0"/>
                    <xsd:element name="dataSource" type="tns:DataSourceType" minOccurs="0"/>
            		<xsd:element name="field" type="tns:ReportFieldConfigurationType" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Columns user definition. Name, type, report field, column name.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="configuration" type="tns:ReportConfigurationType" minOccurs="0"/>
                    <xsd:element name="configurationSchema" type="tns:XmlSchemaType" minOccurs="0"/>
                    <xsd:element name="virtualizer" type="xsd:string" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                <p>
                                    Optional name of Jasper virtualizer class.
                                </p>
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:operational/>
                            </xsd:appinfo>
                        </xsd:annotation>                
                    </xsd:element>
                    <xsd:element name="virtualizerKickOn" type="xsd:int" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Number of pages after Jasper virtualizer kicks on.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="maxPages" type="xsd:int" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Number of pages after Jasper cancels report execution.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="timeout" type="xsd:int" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Timeout in [ms] after Jasper cancels report execution.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
					<xsd:element name="postReportScript" type="tns:CommandLineScriptType" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Command-line script that will be executed after the report is complete
                                and the output file is completely produced. Output filename will
                                be passed to the script as the "file" argument.
                            </xsd:documentation>
                            <xsd:appinfo>
				            	<a:since>3.7</a:since>
				            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
            	</xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="report" type="tns:ReportType" substitutionGroup="c:object"/>

    <xsd:complexType name="ReportConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Report configuration based on report configuration schema.
                TODO

                This element belongs to ReportType and should
                not be used elsewhere. This is a top-level
                element to make the implementation (JAXB
                marshall/unmarshall) easier.
            </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:complexType>

	<xsd:complexType name="ReportOutputType">
    	<xsd:annotation>
            <xsd:documentation>
            	Reports outputs.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
            		<xsd:element name="filePath" type="xsd:string"/>
            		<xsd:element name="exportType" type="tns:ExportType"/>
            		<xsd:element name="report" type="tns:ReportType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Report which is assigned. 
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReference>tns:reportRef</a:objectReference>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>   
                    <xsd:element name="reportRef" type="c:ObjectReferenceType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Report which is assigned.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReferenceTargetType>tns:ReportType</a:objectReferenceTargetType>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="nodeRef" type="c:ObjectReferenceType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Node where the generated report is stored.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReferenceTargetType>tns:NodeType</a:objectReferenceTargetType>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
        		</xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="reportOutput" type="tns:ReportOutputType"/>
	


    <xsd:complexType name="EnvironmentalPerformanceInformationType">
        <xsd:annotation>
            <xsd:documentation>
                Statistics related to performance and state of external environment, namely provisioning via connectors,
                mappings (as these might contain code that invokes external systems), and notifications.

                These are meant to diagnose performance problems that could stem from factors that are outside midPoint.

                LastMessage can be used to diagnose seemingly "frozen" midPoint that waits e.g. for completion of an external operation.
                These messages contain information about start and end of external calls: ICF operations, mappings invocation, notification
                invocation.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="provisioningStatistics" type="tns:ProvisioningStatisticsType" minOccurs="0" />
            <xsd:element name="mappingsStatistics" type="tns:MappingsStatisticsType" minOccurs="0" />
            <xsd:element name="notificationsStatistics" type="tns:NotificationsStatisticsType" minOccurs="0" />
            <xsd:element name="lastMessageTimestamp" type="xsd:dateTime" minOccurs="0" />
            <xsd:element name="lastMessage" type="xsd:string" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ProvisioningStatisticsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="entry" type="tns:ProvisioningStatisticsEntryType" minOccurs="0" maxOccurs="unbounded" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ProvisioningStatisticsEntryType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="resource" type="xsd:string" minOccurs="0" />
            <xsd:element name="objectClass" type="xsd:QName" minOccurs="0" />
            <xsd:element name="getSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="getFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="searchSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="searchFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="createSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="createFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="updateSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="updateFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="deleteSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="deleteFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="syncSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="syncFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="scriptSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="scriptFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="otherSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="otherFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="averageTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="minTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="maxTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="totalTime" type="xsd:long" minOccurs="1" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="MappingsStatisticsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="entry" type="tns:MappingsStatisticsEntryType" minOccurs="0" maxOccurs="unbounded" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="MappingsStatisticsEntryType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="object" type="xsd:string" minOccurs="0" />
            <xsd:element name="count" type="xsd:int" minOccurs="1" />
            <xsd:element name="averageTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="minTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="maxTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="totalTime" type="xsd:long" minOccurs="1" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="NotificationsStatisticsType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="entry" type="tns:NotificationsStatisticsEntryType" minOccurs="0" maxOccurs="unbounded" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="NotificationsStatisticsEntryType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="transport" type="xsd:string" minOccurs="0" />
            <xsd:element name="countSuccess" type="xsd:int" minOccurs="1" />
            <xsd:element name="countFailure" type="xsd:int" minOccurs="1" />
            <xsd:element name="averageTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="minTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="maxTime" type="xsd:long" minOccurs="0" />
            <xsd:element name="totalTime" type="xsd:long" minOccurs="1" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="IterativeTaskInformationType">
        <xsd:annotation>
            <xsd:documentation>
                High-level information about execution of actions that are carried out iteratively on a set of objects.
                This may be any iterative task: live sync, reconciliation, focus recomputation, etc.
                Even bulk actions can be seen as iterative tasks, even though they can contain multiple nested or subsequent
                iterations.
                In future, GUI actions on a set of selected objects can be also described in this structure.

                This type describes processing of the objects as individual and atomic items: it says how many objects
                were processed successfully or not, how long did it take, and what was last object in each category.
                Also what is the currently processed object.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="lastSuccessObjectName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessObjectDisplayName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessObjectType" type="xsd:QName" minOccurs="0" />
            <xsd:element name="lastSuccessObjectOid" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessEndTimestamp" type="xsd:dateTime" minOccurs="0" />
            <xsd:element name="lastSuccessDuration" type="xsd:long" minOccurs="0" />
            <xsd:element name="totalSuccessDuration" type="xsd:long" minOccurs="1" />
            <xsd:element name="totalSuccessCount" type="xsd:int" minOccurs="1" />

            <xsd:element name="lastFailureObjectName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureObjectDisplayName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureObjectType" type="xsd:QName" minOccurs="0" />
            <xsd:element name="lastFailureObjectOid" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureEndTimestamp" type="xsd:dateTime" minOccurs="0" />
            <xsd:element name="lastFailureDuration" type="xsd:long" minOccurs="0" />
            <xsd:element name="totalFailureDuration" type="xsd:long" minOccurs="1" />
            <xsd:element name="totalFailureCount" type="xsd:int" minOccurs="1" />
            <xsd:element name="lastFailureExceptionMessage" type="xsd:string" minOccurs="0" />

            <xsd:element name="currentObjectName" type="xsd:string" minOccurs="0" />
            <xsd:element name="currentObjectDisplayName" type="xsd:string" minOccurs="0" />
            <xsd:element name="currentObjectType" type="xsd:QName" minOccurs="0" />
            <xsd:element name="currentObjectOid" type="xsd:string" minOccurs="0" />
            <xsd:element name="currentObjectStartTimestamp" type="xsd:dateTime" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SynchronizationInformationType">
        <xsd:annotation>
            <xsd:documentation>
                Information about synchronization situations of objects processed by synchronization-related tasks:
                live sync, import, reconciliation. Currently it shows just counters for possible sync situations.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="countProtected" type="xsd:int" minOccurs="1" />
            <xsd:element name="countNoSynchronizationPolicy" type="xsd:int" minOccurs="1" />
            <xsd:element name="countSynchronizationDisabled" type="xsd:int" minOccurs="1" />
            <xsd:element name="countNotApplicableForTask" type="xsd:int" minOccurs="1" />
            <xsd:element name="countDeleted" type="xsd:int" minOccurs="1" />
            <xsd:element name="countDisputed" type="xsd:int" minOccurs="1" />
            <xsd:element name="countLinked" type="xsd:int" minOccurs="1" />
            <xsd:element name="countUnlinked" type="xsd:int" minOccurs="1" />
            <xsd:element name="countUnmatched" type="xsd:int" minOccurs="1" />
            <xsd:element name="countProtectedAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countNoSynchronizationPolicyAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countSynchronizationDisabledAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countNotApplicableForTaskAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countDeletedAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countDisputedAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countLinkedAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countUnlinkedAfter" type="xsd:int" minOccurs="1" />
            <xsd:element name="countUnmatchedAfter" type="xsd:int" minOccurs="1" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ActionsExecutedInformationType">
        <xsd:annotation>
            <xsd:documentation>
                Shows what actions were executed. Currently there are only basic actions (ADD, MODIFY, DELETE) carried out on
                basic categories of objects (object types, e.g. UserType, RoleType, OrgType, ShadowType, ...).

                This gives a quick overview what e.g. import, livesync or reconciliation task is really doing.
                For example, if it really creates new users, or if it deletes anything, etc.

                Two categories of statistics are described: "all" and "resulting".
                The former describes all operations carried out, whereas the latter describes only the "high-level" or "externally visible" ones.
                An example: if a live sync task detects a new resource objects, creates appropriate user, and modifies it twice (because of
                outbound/inbound/template/etc interplay), the "all" category would contain 1xADD and 2xMODIFY for that user. However,
                the "resulting" category shows what the external observer would expect - that 1 user was added (so, 1xADD).
                Note that the behavior of "resulting" action determination is still experimental, and need to be specified more
                precisely, e.g. with regards to operation failures.

                In future it would be nice to distinguish e.g. between shadows on different resources.

                Also, the semantics of operations on ShadowType should be defined more precisely - namely,
                whether an operation means "operation on repository shadow" or "operation on resource object".
                Currently, it means both of them. And some of the shadow related operations are not counted,
                namely those that are carried out autonomously by the provisioning module - e.g. creating repo
                shadows when resource objects are discovered. Also, displaying the result of operations that
                are handled by consistency mechanism is defined quite well.

                Overall, while counters related to focal objects (users, roles, orgs) are relatively well defined,
                counters related to shadows need some clarification.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="objectActionsEntry" type="tns:ObjectActionsExecutedEntryType" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="resultingObjectActionsEntry" type="tns:ObjectActionsExecutedEntryType" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ObjectActionsExecutedEntryType">
        <xsd:annotation>
            <xsd:documentation>
                Actions executed on a given object type, with given operation (change type) and via given channel.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="objectType" type="xsd:QName" />
            <xsd:element name="operation" type="t:ChangeTypeType" />
            <xsd:element name="channel" type="xsd:string" minOccurs="0" />
            <xsd:element name="totalSuccessCount" type="xsd:int" />
            <xsd:element name="lastSuccessObjectName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessObjectDisplayName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessObjectOid" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastSuccessTimestamp" type="xsd:dateTime" minOccurs="0" />
            <xsd:element name="totalFailureCount" type="xsd:int"  />
            <xsd:element name="lastFailureObjectName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureObjectDisplayName" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureObjectOid" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureExceptionMessage" type="xsd:string" minOccurs="0" />
            <xsd:element name="lastFailureTimestamp" type="xsd:dateTime" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="SequenceType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                    Definition of a sequence object that produces unique values. The sequence state is
                    persistently stored in the repository, therefore it can efficiently produce unique
                    identifiers in a controlled and predictable manner.
                </p>
                <p>
                    The sequence is atomic. If two threads or even two nodes request a value from
                    the same sequence at the same time then different values will be returned. Therefore the
                    use of the sequence has some inherent cost (e.g. database locking overhead).
                </p>
                <p>
                    The sequence produces only values of type "long". If any other type or format is needed
                    then an expression must be used to transform the value.
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                    <xsd:element name="counter" type="xsd:long" minOccurs="0" maxOccurs="1">
                        <xsd:annotation>
                            <xsd:documentation>
                                Current state of the sequence. This is the next number that will be assigned
                                from the sequence when "advance" operation is invoked and there are no unused values
                                to re-use.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="unusedValues" type="xsd:long" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                List of values that were already assigned by the sequence but they were not used.
                                The client can return unused values to sequence so the sequence will not advance
                                too fast. If there are any unused values, these will be assigned from the sequence
                                before the regular value from the counter.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="maxCounter" type="xsd:long" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                Maximum value that the counter can produce. If not specified then
                                the highest value that the "long" datatype can produce is assumed.
                                (Please note that this may depend on the range of underlying database type)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="allowRewind" type="xsd:boolean" minOccurs="0" default="false">
                        <xsd:annotation>
                            <xsd:documentation>
                                Flag that affects the behaviour in case maxCounter is exceeded. If set to true then
                                the counter is reset to zero. If set to false then an error is produced.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="maxUnusedValues" type="xsd:int" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                The number of unused values that the sequence will maintain.
                                If set to zero then no values are maintained and therefore the
                                use of unused values is effectively prohibited. This will make
                                the sequence strictly monotonous. 
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="sequence" type="tns:SequenceType" />

    <xsd:complexType name="GuiObjectListsType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the set of pages that are used for displaying lists of objects
      			such as Users, Roles, Orgs, ...
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
           		<xsd:element name="objectList" type="tns:GuiObjectListType" minOccurs="0" maxOccurs="unbounded"/>
           		<xsd:element name="includeDefaultLists" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="true">
           			<xsd:annotation>
           				<xsd:documentation>
           					If set to true then all the default lists will be displayed (all users, all roles, ...)
           				</xsd:documentation>
           			</xsd:annotation>
           		</xsd:element>
           	</xsd:sequence>	
    </xsd:complexType>

	<!-- Note: ObjectListType already defined in API types -->
    <xsd:complexType name="GuiObjectListType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the page used to list specific object type or object collection.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<!-- TODO: now we support only default object lists (all user, all role). But later we will need to
       			           add name, label (display name) and menu label for this list.
       			           We will also need a reference to which menu section we want to display it. E.g. We would
       			           like to display role catalog under "roles", even though it is in fact org tree. -->
       			<xsd:element name="type" type="xsd:QName" minOccurs="1" maxOccurs="1"/>
       			<!-- TODO: refernce to object collection (MID-3517) -->
           		<xsd:element name="searchBoxConfiguration" type="tns:SearchBoxConfigurationType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="column" type="tns:GuiObjectColumnType" minOccurs="0" maxOccurs="unbounded"/>
           		<!-- TODO: number of results per page (MID-1931) -->
           		<!-- TODO: later: export settings (GuiExportSettingsType) -->
           	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="SearchBoxConfigurationType">
        <xsd:annotation>
        	<xsd:documentation>
        		Configuration of the search box (the set of input fields that control definition of search query).
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="defaultMode" type="tns:SearchBoxModeType" minOccurs="0" maxOccurs="1" default="basic"/>
       			<!-- TODO: default items to display for basic search -->
           	</xsd:sequence>
    </xsd:complexType>

	<xsd:simpleType name="SearchBoxModeType">
		<xsd:annotation>
			<xsd:documentation>
				The mode of the search box.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="basic">
				<xsd:annotation>
					<xsd:documentation>
						Basic search mode. Ability to select the items and specify values for them.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="BASIC"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="advanced">
				<xsd:annotation>
					<xsd:documentation>
						Advanced search mode. Ability to create complex query using a query language.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="ADVANCED"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="fulltext">
				<xsd:annotation>
					<xsd:documentation>
						Fulltext search mode. Single input field used to search over several fields.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="FULLTEXT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	
	<xsd:complexType name="GuiObjectColumnType">
        <xsd:annotation>
        	<xsd:documentation>
        		Configuration of the object list column.
        		This is supposed to be universal mergeable configuration. It may be specified
        		in global configuration, roles but also in user's preferences. Therefore it may
        		refer to the columns specified by the "higher" configuration and override some
        		parts of that (e.g. hide/show columns, change ordering, etc.).
        		When merging the configurations there is no way how to remove columns. New columns
        		may be added, setting of the existing columns may be changed, but the columns may not
        		be removed. If the columns should not be displayed then it may be hidden.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Column name (identifier). This element is not displayed to the user. It is used
       						for identification of the column and referencing (e.g. previous column). The column definitions
       						that have the same name in different layers (global, role, user) will be merged together.
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
       			<xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Free-form description. It is not displayed to the user. It is supposed to be used by system
       						administrators to explain the purpose of the configuration.
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
       			<xsd:element name="path" type="t:ItemPathType" minOccurs="0">
	           		<xsd:annotation>
	           			<xsd:documentation>
	           				Path of the item (property) that this form display or that is taken
	           				as an primary input for the expression (planned for future).
	           				Even if expression is used to display the column value, we need some reference
	           				field that will be used to sort the table when sorting by this column is selected.
	           				We cannot sorty by the output of the expression as that is not stored in the repo.
	           			</xsd:documentation>
	           		</xsd:annotation>
	           	</xsd:element>
       			<xsd:element name="display" type="tns:DisplayType" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Specification of column display properties. This can be used to override the default column
       						label or presentation style.
       						(Only label is implemented in midPoint 3.6)
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
       			<xsd:element name="visibility" type="tns:UserInterfaceElementVisibilityType" 
           		             minOccurs="0" maxOccurs="1" default="automatic">
           			<xsd:annotation>
           				<xsd:documentation>
           					Defines, whether this column will be visible or it will be hidden.
           					If not specified then it defaults to automatic visibility.
           				</xsd:documentation>
           			</xsd:annotation>
           		</xsd:element>
       			<xsd:element name="previousColumn" type="xsd:string" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Name of the column that has to be displayed before this column. This value
       						defines ordering in which the columns should be displayed. 
       						The first column has no value in this element.
       						If there are multiple columns that specify the same preceding columns then
       						the implementation may choose any ordering of such columns. However, the
       						algorithm should be deterministic: the same ordring should be used every
       						time (alphabeting ordering based on "path" or displayOrder from the schema
       						are good candidates for deterministic ordering).
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
       			<!-- TODO later: sorting, expression -->
           	</xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="GuiExportSettingsType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the settings for GUI object export.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.6.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="sizeLimit" type="xsd:long" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Maximum number of entries to include in the export.
       						This limit is used to limit the file size and memory consumption,
       						so the user attempting to export a large data set will not
       						bring down the system.
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
       			<!-- TODO: later: default data language, sync/async, whether to show detail dialog or just run the export, etc. -->
           	</xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="GuiObjectDetailsSetType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the set of default forms that are used for displaying and
      						editing of objects, such as User, Role, Org, ...
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
           		<xsd:element name="objectDetailsPage" type="tns:GuiObjectDetailsPageType" minOccurs="0" maxOccurs="unbounded"/>
           	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:complexType name="AbstractObjectTypeConfigurationType" abstract="true">
        <xsd:annotation>
        	<xsd:documentation>
        		Abstract supertype for all data types that specify configuration properties for
        		a specific object type (User, Role, Org, Resource, ...)
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="type" type="xsd:QName" minOccurs="1" maxOccurs="1"/>
           	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:complexType name="GuiObjectDetailsPageType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies form that are used for displaying and
        		editing of specific object type
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:AbstractObjectTypeConfigurationType">
	       		<xsd:sequence>
	           		<xsd:element name="summaryPanel" type="tns:SummaryPanelSpecificationType" minOccurs="0" maxOccurs="1"/>
	           		<xsd:element name="saveMethod" type="tns:DetailsPageSaveMethodType" minOccurs="0" maxOccurs="1" default="direct">
	           			<xsd:annotation>
	           				<xsd:documentation>
	           					Specifies the method how page save/preview buttons are shown and processed.
	           				</xsd:documentation>
	           			</xsd:annotation>
	           		</xsd:element>
	           	</xsd:sequence>	
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="SummaryPanelSpecificationType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the look and feel of the summary panel.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
           		<xsd:element name="displayName" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="identifier" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="title1" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="title2" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="title3" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           		<xsd:element name="organization" type="tns:GuiFlexibleLabelType" minOccurs="0" maxOccurs="1"/>
           	</xsd:sequence>	
    </xsd:complexType>
    
    <xsd:simpleType name="DetailsPageSaveMethodType">
        <xsd:annotation>
            <xsd:documentation>
                Specifies the method how page save/preview buttons are shown and processed.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="direct">
                <xsd:annotation>
                    <xsd:documentation>
                        Direct save. Both save and preview buttons are displayed. User can save directly using
                        save or go to preview and save there. If there are any errors on save (e.g. violated policy rules)
                        then the errors are displayed after save.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DIRECT"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="forcedPreview">
                <xsd:annotation>
                    <xsd:documentation>
                        There is no save button on the details page. Only preview button is there. User must go
                        to the preview page to save the results. The save button on the preview page will be dissabled
                        if there are any errors during preview (e.g. policy rule violations).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FORCED_PREVIEW"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <!-- TODO: maybe later: disable save altogether, leave only preview. -->
        </xsd:restriction>
    </xsd:simpleType>
    
    <xsd:complexType name="GuiFlexibleLabelType">
        <xsd:annotation>
        	<xsd:documentation>
        		Flexible configurable label. Used to specify behavior of summary panel fields, list table columns and so on.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.7</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
       			<xsd:element name="visibility" type="tns:UserInterfaceElementVisibilityType" 
           		             minOccurs="0" maxOccurs="1" default="automatic">
           			<xsd:annotation>
           				<xsd:documentation>
           					Defines, whether this field will be visible or it will be hidden.
           					Can be used to hide the default fields.
           				</xsd:documentation>
           			</xsd:annotation>
           		</xsd:element>
           		<xsd:element name="expression" type="tns:ExpressionType" minOccurs="0" maxOccurs="1"/>
           	</xsd:sequence>	
    </xsd:complexType>
    
  <!-- ============================================================== -->
  <!--  FORMS                                                         -->
  <!-- ============================================================== -->


    <xsd:complexType name="ObjectFormsType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies the set of forms that are used for displaying and
        		editing of objects, such as User, Role, Org, ...
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.4</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
           		<xsd:element name="objectForm" type="tns:ObjectFormType" minOccurs="0" maxOccurs="unbounded"/>
           	</xsd:sequence>	
    </xsd:complexType>

    <xsd:complexType name="ObjectFormType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies form that are used for displaying and
        		editing of specific object type
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.4</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
        	<xsd:extension base="tns:AbstractObjectTypeConfigurationType">
	       		<xsd:sequence>
	           		<xsd:element name="formSpecification" type="tns:FormSpecificationType" minOccurs="0" maxOccurs="1"/>
	           		<xsd:element name="includeDefaultForms" type="xsd:boolean" minOccurs="0" maxOccurs="1" default="false"/>
	           	</xsd:sequence>	
        	</xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    
    <xsd:complexType name="FormSpecificationType">
        <xsd:annotation>
        	<xsd:documentation>
        		Specifies a form using several different methods, e.g. by
        		specification of Java class, internal form OID, etc.
        	</xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>3.4</a:since>
            </xsd:appinfo>
        </xsd:annotation>
       		<xsd:sequence>
	       		<xsd:element name="title" type="xsd:string" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Form title that is shown at an appropriate place, such as browser title, heading,
       						tab name, etc.
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
           		<xsd:element name="formRef" type="tns:ObjectReferenceType"
                                 minOccurs="0" maxOccurs="1">
                    <xsd:annotation>
                        <xsd:documentation>
                            Reference to midPoint form object
                        </xsd:documentation>
                        <xsd:appinfo>
                            <a:objectReferenceTargetType>tns:FormType</a:objectReferenceTargetType>
                        </xsd:appinfo>
                    </xsd:annotation>
                    <!-- Later on the referenced form may also contain title, panelClass and panelUri.
                         Equivalent elements from this data type may be used to override those specified
                         in FormType object referenced from this formRef.
                         However, not all combination have to be supported. E.g. if the FormType object
                         specifies a declarative form and this FormSpecificationType specifies panelClass
                         then an error should be raised.
                          -->
                </xsd:element>
       			<xsd:element name="panelClass" type="xsd:string" minOccurs="0" maxOccurs="1">
       				<xsd:annotation>
       					<xsd:documentation>
       						Name of the Java class that will be used as the form implementation.
       					</xsd:documentation>
       				</xsd:annotation>
       			</xsd:element>
                <xsd:element name="panelUri" type="xsd:anyURI" minOccurs="0" maxOccurs="1">
                    <xsd:annotation>
                        <xsd:documentation>
                            URI identifier of Java component that will be used as the form implementation.
                        </xsd:documentation>
                    </xsd:annotation>
                </xsd:element>
           	</xsd:sequence>	
    </xsd:complexType>
    
    
    <xsd:complexType name="FormType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                    Form definition. Forms define how a certain user interface form or
                    dialog is presented.
                </p>
                <p>
                    Forms inherently define presentation logic. The forms may contain
                    expression or other
                    dynamic parts. However, these parts are provided only for the purpose of
                    improved
                    user experience. The data that the form computes should only help the
                    user to fill out
                    the form or provide a value preview. The data produced by form
                    expressions are NOT
                    authoritative.
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <!-- Originally (approx. midPoint 3.4) this datat type was meant ony for specificaiton of "declarative"
             forms that specify fields for items. But later (3.7.1) it was discovered that this should be
             reused to specify wider range of forms. E.g. parameteric built-in forms (such as "data protection" tab).
             Or even parametric declarative or custom forms. No schema changes were made in 3.7.1.
             Use case: specify "data protection" tab filter, layout and columns in just one place in the system
             (FormType object). And the reuse the specification at several places (e.g. adminGuiConfig in several roles).
             The schema change was just analysed, planned and clarified in those comments.
             -->
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                	<!-- includeRef and formDefinition are used to specify "declarative" custom form.
                	     Ideally, this should be insided its own container. But as this was not done
                	     originally (approx. midPoint 3.4) we cannot change it now. So we leave it as
                	     it is.
                	-->
                    <xsd:element name="includeRef" type="tns:ObjectReferenceType"
                                 minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation>
                                Included form.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:objectReferenceTargetType>tns:FormType</a:objectReferenceTargetType>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element name="formDefinition" type="tns:FormDefinitionType" minOccurs="1">
                        <!-- This is a prism limitation. This is a polymorphic and ordered type.
                        It has to be a prism property. -->
                    </xsd:element>
                </xsd:sequence>
                <!-- title, panelClass and panelUri from FormSpecificationType should be also present here. -->
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="form" type="tns:FormType" />

    <xsd:complexType name="FormDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                    This part defines the actual form presentation and layout.
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="display" type="tns:FormDisplayType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Display characteristics of the form.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="authorization" type="tns:FormAuthorizationType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Setting that influence how authorizations are used to display
		    			and evaluate the form. E.g. this can influence which form fields
		    			should be displayed as read-only or read-write or not displayed
		    			at all.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="formItems" type="tns:FormItemsType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        List of form items.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    
    <xsd:complexType name="FormAuthorizationType">
    	<xsd:annotation>
    		<xsd:documentation>
    			Setting that influence how authorizations are used to display
    			and evaluate the form. E.g. this can influence which form fields
    			should be displayed as read-only or read-write or not displayed
    			at all.
    		</xsd:documentation>
    	</xsd:annotation>
		<xsd:sequence>
		    <xsd:element name="phase" type="tns:AuthorizationPhaseType" minOccurs="0">
		    	<xsd:annotation>
		    		<xsd:documentation>
		    			Authorization phase for which the form should be evaluated.
		    			If not specified then the phase which is naturally appropriate
		    			for the place where the form is displayed is used. This
		    			usually means "request" phase.
		    		</xsd:documentation>
		    	</xsd:annotation>
		    </xsd:element>
		</xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="FormItemsType">
		<xsd:sequence>
			<xsd:element ref="tns:formItem" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						List of form items.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
		<xsd:attribute name="list" type="xsd:boolean" use="optional" />
	</xsd:complexType>
	<xsd:element name="formItems" type="tns:FormItemsType" />

    <xsd:complexType name="DisplayType">
        <xsd:sequence>
            <!-- basic properties -->
            <xsd:element name="label" type="xsd:string" minOccurs="0" />
            <xsd:element name="tooltip" type="xsd:string" minOccurs="0" />
            <xsd:element name="help" type="xsd:string" minOccurs="0" />
            <!-- style properties -->
            <xsd:element name="cssStyle" type="xsd:string" minOccurs="0" />
            <xsd:element name="cssClass" type="xsd:string" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="FormDisplayType">
        <xsd:complexContent>
            <xsd:extension base="tns:DisplayType">
                <xsd:sequence>
                    <xsd:element name="theme" type="xsd:string" minOccurs="0" />
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="FormItemDisplayType">
        <xsd:complexContent>
            <xsd:extension base="tns:DisplayType">
                <xsd:sequence>
                    <xsd:element name="minOccurs" type="xsd:string" minOccurs="0" />
                    <xsd:element name="maxOccurs" type="xsd:string" minOccurs="0" />
                    <xsd:element name="size" type="xsd:integer" minOccurs="0" />
                    <xsd:element name="maxSize" type="xsd:integer" minOccurs="0" />
                    <xsd:element name="newLine" type="xsd:boolean" minOccurs="0" default="true">
                        <xsd:annotation>
                            <xsd:documentation>
                                displayable form component position (if true, field/group/loop will be
                                placed on new line)
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="AbstractFormItemType" abstract="true">
        <xsd:annotation>
            <xsd:documentation>
                Abstract supertype for all form items.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
        	<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
        	<xsd:element ref="tns:description" minOccurs="0" maxOccurs="1"/>
        	<xsd:element name="binding" type="tns:VariableBindingDefinitionType" minOccurs="0" />
            <xsd:element name="display" type="tns:FormItemDisplayType" minOccurs="0" />
            <xsd:element name="widget" type="xsd:string" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        Name of the UI widget that should be used to display this item.
                        Normally, the widget will be chosen automatically based on the type
                        of the backing item (see "ref" element). The "widget" element can be
                        used to override this default behavior. It is used for default included
                        types like text, label, combo, password, checkbox, etc. or class name for
                        custom implementation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- Note: available values are defined by the "set" in the binding. -->
            <xsd:element name="validation" type="tns:FormItemValidationType" minOccurs="0" />
            <!-- TODO: condition -->
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="formItem" type="tns:AbstractFormItemType" abstract="true" />

    <xsd:complexType name="FormItemValidationType">
        <xsd:sequence>
            <xsd:element name="server" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        <!--TODO -->
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="client" type="tns:FormItemClientValidationType" minOccurs="0" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="FormItemClientValidationType">
        <xsd:annotation>
            <xsd:documentation>
                <!--TODO -->
                javascript stuff, we replace ${this} with proper input id, probably
                some jQuery black magic

                TODO: add event type attribute to client element for this validator
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="event" type="xsd:string" minOccurs="1" maxOccurs="unbounded" />
            <xsd:element name="script" type="xsd:string" minOccurs="1" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="FormFieldType">
        <xsd:annotation>
            <xsd:documentation>
                A single form field. This definition is expected to render a short,
                compact
                visual representation of a single item (property, reference or container).
                If a container is represented as a field, it has to be a very
                compact representation
                of the container, usually by using custom widget that creates a pop-up
                when clicked.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractFormItemType">
                <xsd:sequence>
                    <!-- Nothing to add now -->
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>

        <!-- TODO: some kind of renderer, probably something like IChoiceRenderer 
        in wicket to translate real value to display value and after edit to translate 
        displayed value to real value -->

    </xsd:complexType>
    <xsd:element name="formField" type="tns:FormFieldType" substitutionGroup="c:formItem">
		<xsd:annotation>
			<xsd:appinfo>
				<a:heterogeneousListItem/>
			</xsd:appinfo>
		</xsd:annotation>
	</xsd:element>

    <xsd:complexType name="FormFieldGroupType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                    A group of fields. The group is rendered in a such a way that it will be obvious
                    that the fields belong together and form a a logical group (e.g. by using box
                    with a border). This can be used to display value of complex containers.
                    But it may also be used to visually group together a set of
                    related properties that are not in the same container.
                </p>
                <p>
                    The group is NOT meant to automatically generate fields for every container item.
                    Individual fields must be defined as sub-items of this group.
                </p>
                <p>
                    If ref element is used it MUST point to PrismContainer. In that case subitems of this
                    group must point to the container value items.
                </p>
                <p>
                    The group may not have any ref element. In that case the subfields may
                    refer to any property.
                </p>
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractFormItemType">
                <xsd:sequence>
                    <xsd:element name="formItems" type="tns:FormItemsType" minOccurs="0">
                        <xsd:annotation>
                            <xsd:documentation>
                                List of group subitems.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
	<xsd:element name="formFieldGroup" type="tns:FormFieldGroupType" substitutionGroup="tns:formItem">
		<xsd:annotation>
			<xsd:appinfo>
				<a:heterogeneousListItem/>
			</xsd:appinfo>
		</xsd:annotation>
	</xsd:element>

    <xsd:complexType name="ObjectTreeDeltasType">
        <xsd:annotation>
            <xsd:documentation>
                Container for ChangesRequested (focus primary delta and/or projection primary deltas).
            </xsd:documentation>
            <xsd:appinfo>       <!-- switch to container after deltas will be moved out of task extension -->
                <!--<a:container/>-->
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="focusPrimaryDelta" type="t:ObjectDeltaType" minOccurs="0">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="projectionPrimaryDelta" type="tns:ProjectionObjectDeltaType" minOccurs="0" maxOccurs="unbounded">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="objectTreeDeltas" type="tns:ObjectTreeDeltasType"/>

    <xsd:complexType name="ProjectionObjectDeltaType">
        <xsd:annotation>

            <xsd:documentation>
                TODO
            </xsd:documentation>
            <!--<xsd:appinfo>-->
            <!--<a:container/>-->
            <!--</xsd:appinfo>-->
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="resourceShadowDiscriminator" type="c:ShadowDiscriminatorType">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element name="primaryDelta" type="t:ObjectDeltaType">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

	<xsd:complexType name="MappingEvaluationRequestType">
		<xsd:annotation>
			<xsd:documentation>
				TODO ... EXPERIMENTAL
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="sourceContext" type="c:MappingEvaluationSourceContextType" minOccurs="0" >
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="targetContext" type="xsd:QName" minOccurs="0" >
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="variable" type="c:MappingEvaluationVariableType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="options" type="c:MappingEvaluationOptionsType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="mapping" type="c:MappingType">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="MappingEvaluationRequest" type="tns:MappingEvaluationRequestType"/>

	<xsd:complexType name="MappingEvaluationSourceContextType">
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="0"/>
			<xsd:choice>
				<xsd:element name="objectRef" type="c:ObjectReferenceType" minOccurs="0"/>
				<xsd:element ref="c:object" />
			</xsd:choice>
			<xsd:element name="delta" type="t:ObjectDeltaType" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="MappingEvaluationVariableType">
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="0"/>
			<xsd:element ref="c:value" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="MappingEvaluationOptionsType">
		<xsd:sequence>
			<xsd:element name="now" type="xsd:dateTime" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="MappingEvaluationResponseType">
		<xsd:annotation>
			<xsd:documentation>
				TODO ... EXPERIMENTAL
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="response" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="MappingEvaluationResponse" type="tns:MappingEvaluationResponseType"/>

	<xsd:complexType name="LogFileContentType">
		<xsd:sequence>
			<xsd:element name="content" type="xsd:string"/>
			<xsd:element name="at" type="xsd:long">
				<xsd:annotation>
					<xsd:documentation>
						Position of this fragment in the log file.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="complete" type="xsd:boolean">
				<xsd:annotation>
					<xsd:documentation>
						Is the fragment we are returning the complete content of the log file (starting from the given position)?
						I.e. if false, there are some data after this fragment.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="logFileSize" type="xsd:long">
				<xsd:annotation>
					<xsd:documentation>
						Current log file size, in bytes.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="BuildInformationType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="version" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Version taken from POM file, e.g. 3.4.1 or 3.5-SNAPSHOT.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="revision" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Revision, i.e. output of git describe command. Example: git-v3.5devel-314-g02f4792.
						May not be known, depending on how midPoint was built.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="ValidationResultType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="issue" type="tns:ValidationIssueType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						TODO
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="validationResult" type="tns:ValidationResultType"/>

	<xsd:complexType name="ValidationIssueType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="severity" type="tns:ValidationIssueSeverityType" />
			<xsd:element name="category" type="xsd:string" />
			<xsd:element name="code" type="xsd:string" />
			<xsd:element name="text" type="xsd:string" />
			<xsd:element name="objectRef" type="tns:ObjectReferenceType" minOccurs="0" />
			<xsd:element name="itemPath" type="xsd:string" minOccurs="0" />					<!-- ItemPathType is problem within containers -->
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="ValidationIssueSeverityType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="error">
				<xsd:annotation>
					<xsd:documentation>
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="ERROR"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="warning">
				<xsd:annotation>
					<xsd:documentation>
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="WARNING"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="info">
				<xsd:annotation>
					<xsd:documentation>
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="INFO"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>
	
	<xsd:complexType name="MergeConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				Configuration that specifies automatic merging of two objects.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Short name of the merge cofiguration that also works as identifier for this configuration.
						It has to be unique among all the applicable merge configurations.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="displayName" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Free form-name that can be displayed in user interfaces.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
							<xsd:annotation>
					<xsd:documentation>
						Free form description that can be displayed in user interfaces. It may be
						longer text (more than few lines).
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="item" type="tns:ItemRefMergeConfigurationType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Item merge configuration. It will be applied to the specified (named) item.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="projection" type="tns:ProjectionMergeConfigurationType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Projection merge configuration. It will be applied to merge projections (linkRefs)
						of the objects.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="default" type="tns:ItemMergeConfigurationType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Default merge configuration. It will be applied to all the items that are not
						explicitly specified in the item merge configurations.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="ItemMergeConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="left" type="tns:MergeStategyType" minOccurs="0" maxOccurs="1" default="ignore">
				<xsd:annotation>
					<xsd:documentation>
						Strategy to process values from the left-hand-side object. 
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="right" type="tns:MergeStategyType" minOccurs="0" maxOccurs="1" default="ignore">
				<xsd:annotation>
					<xsd:documentation>
						Strategy to process values from the right-hand-side object.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="valueExpression" type="tns:ExpressionType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Expression to process every value (if specified by strategy). The value that the
						expression returns will be taken. If the expression returns null then the value will
						be skipped.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
	
	<xsd:complexType name="ItemRefMergeConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:ItemMergeConfigurationType">
				<xsd:sequence>
					<xsd:element name="ref" type="t:ItemPathType" minOccurs="1" maxOccurs="1"/>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:complexType name="ProjectionMergeConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:ItemMergeConfigurationType">
				<xsd:sequence>
					<xsd:element name="situation" type="tns:ProjectionMergeSituationType" minOccurs="0" maxOccurs="1"/>
					<xsd:element name="projectionDiscriminator" type="tns:ShadowDiscriminatorType" minOccurs="0" maxOccurs="1"/>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
	
	<xsd:simpleType name="MergeStategyType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ignore">
				<xsd:annotation>
					<xsd:documentation>
						Ignore all the values.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="IGNORE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="take">
				<xsd:annotation>
					<xsd:documentation>
						Take all the values.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="TAKE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="expression">
				<xsd:annotation>
					<xsd:documentation>
						Take only values that are selected and processed by the expression.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="EXPRESSION"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<!-- TODO: values for manual selection may come here in the future. -->
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:simpleType name="ProjectionMergeSituationType">
		<xsd:annotation>
			<xsd:documentation>
				TODO
			</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="existing">
				<xsd:annotation>
					<xsd:documentation>
						Projection exists on the left side. There is no conflicting
						projection on the right side.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="EXISTING"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="mergeable">
				<xsd:annotation>
					<xsd:documentation>
						Projection exists on the right side. There is no conflicting
						projection on the left side. The projection can be merged.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="MERGEABLE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="conflict">
				<xsd:annotation>
					<xsd:documentation>
						There are two conflicting projections, one on the left side
						other on the right side.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="CONFLICT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:complexType name="DeploymentInformationType">
		<xsd:annotation>
			<xsd:documentation>
				Information about midPoint deployment: subscription information, deployment name,
                description, color and so on.
                These information are not critical for midPoint operation. However they may influence
                the look and feel of this midPoint instance.
            </xsd:documentation>
            <xsd:appinfo>
            	<a:since>3.5.1</a:since>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Short name of this midPoint deployment. The name will be displayed
						on a prominent place in the user interface, most likely displayed as
						a part of the header (on every page). The name is usually used
						to distinguish between midPoint deployments in the same organization.
						Strings such as "DEVEL", "TEST", "UAT" are often used.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="description" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Free form description that specifies the details of this deployment.
						It may be significantly long (few paragraps). It has no special purpose	
						other then a form of "on-line" documentation for the deployment. It will
						NOT be displayed on every page. It will most likely be displayed on a system
						configuration pages or in configuration summaries.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="headerColor" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Specification of a color that will be used as a background for a page header.
						The color can be used as a form of easy look and feel customization to match the
						customer corporate identity. But perhaps more often the color will be used to
						distinguish different midPoint environments in the same organization, e.g.
						green color for devel environment, blue color for testing, etc.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
            <xsd:element name="skin" type="xsd:string" minOccurs="0" maxOccurs="1">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of the adminLTE skin that will be applied to the base template.
                        The base template contains 12 predefined skins including: skin-blue, skin-blue-light
                        skin-yellow, skin-yellow-light, skin-green, skin-green-light, skin-purple, skin-purple-light,
                        skin-red, skin-red-light, skin-black and skin-black-light.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.6.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
			<xsd:element name="logo" type="tns:IconType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Specification of a logo that will be used in the title bar on every screen.
						This can be used as an easy customization and point to a customer logo. Or
						it may be used as an icon to indicate the environment.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="customerName" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Short name of the organization that is end user of the midPoint deployment.
						It is supposed to be a company name, such as "ExAmPLE, Inc."
						It will be displayed together with subscription information.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="customerUrl" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						URL of the customer web site. It will be used as a link target in case
						that the customer name is displayed as hyperlink.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="partnerName" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Short name of the organization that deployed this midPoint instance.
						It is usually the name of Evolveum partner.
						It is supposed to be a company name, such as "ExAmPLE, Inc."
						It will be displayed together with subscription information.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="partnerUrl" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						URL of the partner web site. It will be used as a link target in case
						that the partner name is displayed as hyperlink.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="subscriptionIdentifier" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Identifier of Evolveum subscription contract that applies to this deployment.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="InfrastructureConfigurationType">
		<xsd:annotation>
			<xsd:documentation>
				Technical (infrastructure) configuration of midPoint deployment.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.6</a:since>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="defaultHostname" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Hostname that will be used as a public hostname for the midPoint deployment.
						E.g. it will be used in URLs that point to the midPoint in notification mails.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="intraClusterHttpUrlPattern" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Pattern for HTTP/HTTPS communication inside midPoint cluster.
						This is specifies the URLs that ure used by midPoint cluster nodes
						when they need to communicate with each other. The pattern is in fact
						an URL prefix pointing to root URL of the application. Specific paths
						will be appended to the URL. 
						Example: https://$host/midpoint
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="remoteHostAddressHeader" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Whether to try to determine client's IP address information from HTTP headers and if so,
						what header(s) to use. Note that the order of headers to try is indeterminate: they might be
						tried in any order.
					</xsd:documentation>
					<xsd:appinfo>
						<a:since>3.6</a:since>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="CachingPolicyType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of object attribute caching policies.
			</xsd:documentation>
			<xsd:appinfo>
				<a:container/>
				<a:since>3.5</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="cachingStategy" type="tns:CachingStategyType" minOccurs="0" maxOccurs="1" default="none"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="CachingStategyType">
		<xsd:annotation>
			<xsd:documentation>
				Definition of overall caching strategy.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="none">
				<xsd:annotation>
					<xsd:documentation>
						Do not cache information at all. Caches are not used and not maintained.
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="NONE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="passive">
				<xsd:annotation>
					<xsd:documentation>
						Caches are maintained with minimal impact on normal operations.
						Generally the data are cached only if they are retrieved for other
						reasons. There is no read-ahead. The writes are always going to the
						resource (synchronously): read-through, write-through.
						There is no cache eviction (but old information is overwritten if
						newer information is available).
					</xsd:documentation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="PASSIVE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

	<xsd:complexType name="OperationExecutionType">
		<xsd:annotation>
			<xsd:documentation>
				Information about an operation executed on an object.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.6</a:since>
				<a:container/>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="timestamp" type="xsd:dateTime" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						When was this information recorded. It is expected that it was when
						the operation finished (successfully or not).
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="operation" type="tns:ObjectDeltaOperationType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						The elementary operation(s) that were part of the execution and their results.
						However, the content would be reduced e.g. by deletion of modification items and operation
						result children. The level of reduction could be configurable in the future.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="status" type="tns:OperationResultStatusType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Overall result status of the whole operation.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="initiatorRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						User that initiated the operation. (TODO)
					</xsd:documentation>
					<xsd:appinfo>
						<a:objectReferenceTargetType>tns:UserType</a:objectReferenceTargetType>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="taskRef" type="tns:ObjectReferenceType" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						The task that was used to initiate the operation (if any). Only the latest result for a given
						non-zero task OID will be kept for any object.
					</xsd:documentation>
					<xsd:appinfo>
						<a:objectReferenceTargetType>tns:TaskType</a:objectReferenceTargetType>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="channel" type="xsd:string" minOccurs="0" maxOccurs="1">
				<xsd:annotation>
					<xsd:documentation>
						Channel through which the operation was initiated.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
		<xsd:attribute name="id" type="xsd:long" use="optional"/>
	</xsd:complexType>

	<xsd:complexType name="LocalizableMessageType" abstract="true">
		<xsd:annotation>
			<xsd:documentation>
				A message that is to be localized into specified language.
				Abstract superclass for both single-item message and a message list.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
	</xsd:complexType>

	<xsd:complexType name="SingleLocalizableMessageType">
		<xsd:annotation>
			<xsd:documentation>
				A message that is to be localized into specified language.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
				<!-- Make this class a 'default' instance of LocalizableMessageType,
				     to avoid the need of specifying xsi:type for empty messages (experimental) -->
				<a:instantiationOrder>1</a:instantiationOrder>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:LocalizableMessageType">
				<xsd:sequence>
					<xsd:element name="key" type="xsd:string" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Localization key.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="argument" type="tns:LocalizableMessageArgumentType" minOccurs="0" maxOccurs="unbounded">
						<xsd:annotation>
							<xsd:documentation>
								Arguments to be used as values for localized message parameters.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="fallbackLocalizableMessage" type="tns:LocalizableMessageType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Fallback localizable message to be used when key couldn't be resolved. Mutually exclusive with fallbackMessage.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="fallbackMessage" type="xsd:string" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Fallback message to be used when key couldn't be resolved. Mutually exclusive with fallbackLocalizableMessage.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="LocalizableMessageListType">
		<xsd:annotation>
			<xsd:documentation>
				List of localizable messages, to be presented as a single message.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:LocalizableMessageType">
				<xsd:sequence>
					<xsd:element name="message" type="tns:LocalizableMessageType" minOccurs="0" maxOccurs="unbounded">
						<xsd:annotation>
							<xsd:documentation>
								Messages.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="separator" type="tns:LocalizableMessageType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Separator to be put between the messages. Typically a comma.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="prefix" type="tns:LocalizableMessageType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Prefix of the sequence.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="postfix" type="tns:LocalizableMessageType" minOccurs="0">
						<xsd:annotation>
							<xsd:documentation>
								Postfix of the sequence.
							</xsd:documentation>
						</xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="LocalizableMessageArgumentType">
		<xsd:annotation>
			<xsd:documentation>
				Argument that is to be used for localized message parameter.
				Might be a LocalizableMessageType itself, allowing for messages like
				"Assignment exists for {0} {1} (OID {2}" where {0} has to be resolved
				to e.g. "role", localized for the target language.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:choice>
			<xsd:element name="value" type="xsd:string">
				<xsd:annotation>
					<xsd:documentation>
						Literal value.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="localizable" type="tns:LocalizableMessageType">
				<xsd:annotation>
					<xsd:documentation>
						Embedded localizable message.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:choice>
	</xsd:complexType>

	<xsd:complexType name="LocalizableMessageTemplateType">
		<xsd:annotation>
			<xsd:documentation>
				A template that produces a localizable message after argument expressions are evaluated into specific arguments.
			</xsd:documentation>
			<xsd:appinfo>
				<a:since>3.7</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="key" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Localization key. Mutually exclusive with keyExpression.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="keyExpression" type="tns:ExpressionType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Localization key expression. Mutually exclusive with the key.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="argument" type="tns:LocalizableMessageArgumentType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Values for arguments. Mutually exclusive with argumentExpression: if at least one argument is used,
						no argumentExpression can be used, and vice versa.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="argumentExpression" type="tns:ExpressionType" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
						Expressions to be evaluated to specific arguments, which are to be used as values for localized message parameters.
						Mutually exclusive with argument: if at least one argumentExpression is used, no argument can be used, and vice versa.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="fallbackMessage" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Fallback message to be used when key couldn't be resolved. Mutually exclusive with fallbackMessageExpression.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="fallbackMessageExpression" type="tns:ExpressionType" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
						Fallback message expression to be evaluated to specific fallback message. Mutually exclusive with fallbackMessage.
					</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="HttpMethodType">
		<xsd:annotation>
			<!-- This is meant as a general enumeration to be used at various places in midPoint.
			Not all places of use are obliged to support all HTTP methods listed here. -->
			<xsd:documentation>
				Individual HTTP methods. Not all of them are supported by midPoint components.
			</xsd:documentation>
			<xsd:appinfo>
				<jaxb:typesafeEnumClass/>
				<a:since>3.7.1</a:since>
			</xsd:appinfo>
		</xsd:annotation>
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="get">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="GET"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="post">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="POST"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="put">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="PUT"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="head">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="HEAD"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="patch">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="PATCH"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="delete">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="DELETE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="options">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="OPTIONS"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
			<xsd:enumeration value="trace">
				<xsd:annotation>
					<xsd:appinfo>
						<jaxb:typesafeEnumMember name="TRACE"/>
					</xsd:appinfo>
				</xsd:annotation>
			</xsd:enumeration>
		</xsd:restriction>
	</xsd:simpleType>

</xsd:schema>