<?xml version="1.0" encoding="UTF-8" standalone="no"?><!--
  ~ Copyright (C) 2010-2021 Evolveum and contributors
  ~
  ~ Licensed under the EUPL-1.2 or later.
  --><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:a="http://prism.evolveum.com/xml/ns/public/annotation-3" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3" xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3" xmlns:jaxb="https://jakarta.ee/xml/ns/jaxb" xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3" xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3" xmlns:tns="http://midpoint.evolveum.com/xml/ns/public/common/common-3" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" elementFormDefault="qualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="3.0" targetNamespace="http://midpoint.evolveum.com/xml/ns/public/common/common-3">

    <xsd:annotation>
        <xsd:documentation>
            Provisioning-related parts of the common schema. Deals with resources, connectors, shadows, and the like.
            (Its borders are not crystal-clear, though.)

            Note that correlation is factored out into separate file: common-correlation-3.xsd.
        </xsd:documentation>
    </xsd:annotation>

    <!-- Don't provide schemaLocation here, as it causes xjc to really contact the URIs (!) -->
    <xsd:import namespace="http://prism.evolveum.com/xml/ns/public/annotation-3" schemaLocation="../annotation-3.xsd"/>
    <xsd:import namespace="http://prism.evolveum.com/xml/ns/public/types-3" schemaLocation="../types-3.xsd"/>
    <xsd:import namespace="http://prism.evolveum.com/xml/ns/public/query-3" schemaLocation="../query-3.xsd"/>
    <xsd:import namespace="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3" schemaLocation="../resource/capabilities-3.xsd"/>

    <xsd:include schemaLocation="common-core-3.xsd"/>
    <xsd:include schemaLocation="common-correlation-3.xsd"/>

    <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:appinfo>
                <a:schemaMigration>
                    <a:element>tns:namespace</a:element>
                    <a:version>4.4</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:AssignmentHolderType">
                <xsd:sequence>
                    <xsd:element minOccurs="0" name="administrativeOperationalState" type="tns:AdministrativeOperationalStateType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Metadata about administrative operational state of the resource.
                                Experimental. Contributed by the community.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="operationalState" type="tns:OperationalStateType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Metadata about operational state of the resource.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:operational>true</a:operational>
                                <a:alwaysUseForEquals>true</a:alwaysUseForEquals>
                                <a:displayHint>regular</a:displayHint>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="operationalStateHistory" type="tns:OperationalStateType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Previous values of the operationalState item.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.1</a:since>
                                <a:diagram>
                                    <a:name>user-shadow-resource</a:name>
                                    <a:form>collapsed</a:form>
                                </a:diagram>
                                <a:operational>true</a:operational>
                                <a:alwaysUseForEquals>true</a:alwaysUseForEquals>
                                <a:displayHint>regular</a:displayHint>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="template" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Is this a resource template? By setting this flag to "true", this object will be presented
                                to users in Resource Wizard as a starting point for creation of new resources.

                                Note that in the future we may replace this flag with something more elaborate
                                (like more detailed information about the kind of resource template).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.6</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="abstract" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Is this an abstract resource, i.e. something that cannot be used directly (serving like
                                e.g. a template for creation of specific resources)?

                                The default is "false" for regular resources and "true" for resource templates (template=true).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.6</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="super" type="tns:SuperResourceDeclarationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Instruction to include a configuration from another resource.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="connectorRef" type="c:ObjectReferenceType">
                        <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 connector 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 minOccurs="0" name="connectorConfiguration" type="tns:ConnectorConfigurationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Resource configuration (hostname, port, ...). The structure of this section is specific
                                for each resource type i.e. connector (CSV, LDAP, and so on). There may be some parts
                                common to e.g. all ConnId-based resources.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="additionalConnector" type="tns:ConnectorInstanceSpecificationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Specification of additional connector(s). Additional connectors may add
                                capabilities to this resource, e.g. scripting capability or capability for
                                reading the exported resource content.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>3.6</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="schema" type="tns:XmlSchemaType">
                        <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 different 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 minOccurs="0" ref="tns:schemaHandling"/>
                    <xsd:element minOccurs="0" name="capabilities" type="tns:CapabilitiesType">
                        <xsd:annotation>
                            <xsd:documentation>
                                The capabilities supported by the resource, including both native capabilities of
                                the connector and configured capabilities. See the CapabilitiesType for the distinction
                                between these two.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="scripts" type="tns:OperationProvisioningScriptsType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Scripts to be executed for various provisioning operations.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="projection" type="tns:ProjectionPolicyType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Resource-wide account synchronization settings.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="consistency" type="tns:ResourceConsistencyType"/>
                    <xsd:element minOccurs="0" name="caching" type="tns:ShadowCachingPolicyType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Definition of shadow caching at the resource level.
                                Can be overridden at the level of object classes and types.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="cacheInvalidationTimestamp" type="xsd:dateTime">
                        <xsd:annotation>
                            <xsd:documentation>
                                If specified, all shadows cached on or before this time are considered expired.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.9</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="synchronization" type="tns:SynchronizationType"/>
                    <xsd:element minOccurs="0" name="business" type="tns:ResourceBusinessConfigurationType"/>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="resource" substitutionGroup="c:object" type="tns:ResourceType"/>

    <xsd:complexType name="AdministrativeOperationalStateType">
        <xsd:annotation>
            <xsd:documentation>
                Structure containing metadata about administrative operational state of the resource.
                Administrative operational state is set manually by midPoint users (e.g. administrator).
                This is in contrast with OperationalStateType setting, which is set automatically by the midPoint.
                It signalizes whether resource is up and OPERATIONAL to receive provisioning requests or is down in MAINTENANCE and midPoint should not contact it during the provisioning.
                This setting is useful when resource is e.g. undergoing planned maintenance to save computing time and error messages.

                EXPERIMENTAL FEATURE! Contributed by the community.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.2</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="administrativeAvailabilityStatus" type="tns:AdministrativeAvailabilityStatusType"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="OperationalStateType">
        <xsd:annotation>
            <xsd:documentation>
                Structure containing metadata about operational state of the resource.
                E.g. if resource is up or down, when it was last changed, etc.
                It should not contain configuration, just the operational state.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="lastAvailabilityStatus" type="tns:AvailabilityStatusType"/>
            <xsd:element minOccurs="0" name="message" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        The reason for the last change of availability status.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="timestamp" type="xsd:dateTime">
                <xsd:annotation>
                    <xsd:documentation>
                        The time of the last change of availability status.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="nodeId" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        The node that recorded the last change of availability status.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:simpleType name="AdministrativeAvailabilityStatusType">
        <xsd:annotation>
            <xsd:documentation>
                The enum describes the administrative availability of the resource, if it is operational or undergoing maintenance.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="maintenance">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAINTENANCE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="operational">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="OPERATIONAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <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>
                <a:naturalKey>tns:name</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="name" type="xsd:string"/>
            <xsd:element minOccurs="0" name="description" type="xsd:string"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" name="connectorRef" type="c:ObjectReferenceType">
                <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 minOccurs="0" name="capabilities" type="tns:CapabilitiesType">
                <xsd:annotation>
                    <xsd:documentation>
                        Capabilities provided by the connector.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="connectorInstanceSpecification" type="c:ConnectorInstanceSpecificationType"/>

    <xsd:complexType name="XmlSchemaType">
        <xsd:annotation>
            <xsd:documentation>
                This element contains the XSD-formatted definition of schema.

                The schema available in this definition is expected 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 minOccurs="0" ref="tns:cachingMetadata">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:operational>true</a:operational>
                        <a:alwaysUseForEquals>true</a:alwaysUseForEquals>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="generationConstraints" type="tns:SchemaGenerationConstraintsType"/>
            <xsd:element minOccurs="0" name="definition" type="t:SchemaDefinitionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:optionalCleanup>true</a:optionalCleanup>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="xmlSchema" 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 minOccurs="0" name="retrievalTimestamp" type="xsd:dateTime">
                <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 relatively 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:appinfo>
                <a:container>true</a:container>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="generateObjectClass" type="xsd:QName">
                <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 object classes
                        specified by the generateObjectClass elements will be generated and 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 marshal/unmarshal) easier.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectClass" type="tns:ResourceObjectTypeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Refinement (modification, extension) of definitions of object classes in the "native" resource schema.

                        This is to specify refinements that should be applied to _all_ objects and operations related
                        to given object class. For example, if we want to specify fetch strategy for specific attribute
                        of groupOfUniqueNames object class, and apply this consistently to all search operations over
                        this object class, we should specify the strategy here.

                        This is something that has been achieved by setting default=true for a selected object type definition.
                        However, the use of object class refinement is more focused and (in a sense) more clear way how to
                        achieve this.

                        Beware: Although the XSD type is formally ResourceObjectTypeDefinitionType (primarily because
                        of implementation reasons), not all elements of ResourceObjectTypeDefinitionType are supported here.
                        For example, it's not possible to specify kind, intent, nor super-type here. Because of a limitation
                        of XSD language we are not able to express these restrictions without changing the order of XML
                        elements in complying documents (because the typical solution: deriving both
                        ResourceObjectTypeDefinitionType and something like "ResourceObjectClassDefinitionType" from a common
                        ancestor would mean that the order of XML elements in resulting documents would be different from what
                        it is now).

                        We also advise avoid specification of pure object-type concepts (like mappings) in these definitions.
                        It is better to create a special (abstract) object type to do this.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.6</a:since>
                        <a:naturalKey>tns:objectClass</a:naturalKey>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectType" type="tns:ResourceObjectTypeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of types of objects this resource supports: account types, entitlement types,
                        and so on. Each type has its delineation (specification what resource objects belong to it),
                        focus specification (what focal objects correspond to it), attribute definitions (mappings and other
                        options), association definitions, protected objects specification, capabilities, and so on.

                        Resource object types are used when resource objects are addressed: for example when they are assigned
                        (to roles, orgs, users), targeted by synchronization tasks, searched for using Query API, and so on.

                        Type definitions can form hierarchies, with subtypes inheriting definitions from their supertypes.
                        (And all inheriting definitions from refined object class definitions.)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:naturalKey>tns:kind</a:naturalKey>
                        <a:naturalKey>tns:intent</a:naturalKey>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="associationType" type="tns:ShadowAssociationTypeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of types of associations between resource objects.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="schemaHandling" type="tns:SchemaHandlingType"/>

    <xsd:complexType name="ResourceObjectTypeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Defines a type of resource objects. By pointing to this kind of definition (by specifying kind
                and intent), resource objects can be created and searched for.

                Note that this XSD type is - maybe temporarily - used also for specification of resource object class
                refinements. See SchemaHandlingType.objectClass item description.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:schemaMigration>
                    <a:element>tns:assignmentPolicyEnforcement</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:pagedSearches</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:merger>ResourceObjectTypeDefinitionType</a:merger>
                <a:schemaContext>
                    <a:algorithm>ResourceObjectContextResolver</a:algorithm>
                </a:schemaContext>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="account" minOccurs="0" name="kind" type="tns:ShadowKindType">
                <xsd:annotation>
                    <xsd:documentation>
                        Kind of objects covered by this type.

                        For object class refinements, it must not be specified
                        (and the default does not apply there as well).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourceObjectTypeDefinitionType.kind</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="default" minOccurs="0" name="intent" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Intent of objects covered by this type.

                        For object class refinements, it must not be specified
                        (and the default does not apply there as well).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourceObjectTypeDefinitionType.intent</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:displayName">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ResourceObjectTypeDefinitionType.displayName</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:description">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ResourceObjectTypeDefinitionType.description</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" ref="tns:lifecycleState">
                <xsd:annotation>
                    <xsd:documentation>
                        Lifecycle state of the object class or object type. First, it drives the visibility of the configuration
                        for production-like or simulation tasks. Second, it influences the behavior of specific provisioning
                        operations (like shadow classification).

                        The lifecycle state is propagated downwards, from the level of a resource, down to the level
                        of an object class, and finally to the level of an object type. If the state is evaluated
                        as "non-matching" at a given level, all lower levels are ignored. For example, if an object class
                        has a "proposed" lifecycle state, all its object types are considered to be in non-production
                        development state, regardless of their own lifecycle state values.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ObjectType.lifecycleState</a:displayName>
                        <a:since>4.7</a:since>
                        <a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000230" type="tns:LookupTableType"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="false" minOccurs="0" name="abstract" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Is this an abstract object type? Such a type cannot be referenced from a construction,
                        nor it can be used as a categorization result. It is also not referencable from e.g. search queries.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="super" type="tns:ResourceObjectTypeIdentificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Super type of this resource object type.

                        For object class refinements, it must not be specified.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="default" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies whether this resource object type is the default one that is used when:

                        1. Kind without intent is specified (e.g. in assigned construction or in synchronization task).
                        2. Object class without kind/intent is specified (e.g. in synchronization task).

                        Technically, setting a value for this property is propagated to both "defaultForKind"
                        and "defaultForObjectClass" ones. See their documentation for more information.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourceObjectTypeDefinitionType.default</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="defaultForKind" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies whether this resource object type is the default one for given kind of objects, i.e.
                        for accounts, entitlements or "generic objects".

                        This means that if e.g. object type T is specified with kind=account and defaultForKind=true,
                        and a resource object construction is assigned with kind=account (without providing an intent),
                        then this object type (T) is being assigned as a result.

                        In a similar way, if a synchronization activity (like import or reconciliation)
                        is specified with kind=account (without providing an intent), then the synchronization proceeds against
                        objects of this type T. (I.e. NOT against all objects with kind=account!)

                        Only one type can be the default one for given kind. Setting this flag to true for more than one type
                        is an error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="defaultForObjectClass" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies whether this resource object type is the default one for the given object class,
                        e.g. for ri:AccountObjectClass or ri:inetOrgPerson.

                        This means that if e.g. given object type T is specified with objectClass=ri:inetOrgPerson and
                        defaultForObjectClass=true, and a synchronization task is started for object class of ri:inetOrgPerson
                        (without providing kind/intent), the definition to be used when issuing the query - e.g. attributes
                        to return, base context, and so on - is derived from the definition of this object type T. (Note that
                        midPoint still attempts to synchronize all members of the said object class, if only the object class
                        is specified in the synchronization task.)

                        Since 4.6, the preferred way to provide such object-class-level definitions is to use so-called
                        refined object class definitions, i.e. to provide schemaHandling/objectClass refinement
                        for ri:inetOrgPerson. Therefore, it's no longer necessary to specify default object type
                        for object class just for this purpose.

                        Another use of this flag is to specify the default type for classification of resource objects of given
                        object class. But this functionality can be achieved also using "classificationOrder" property
                        of object type delineation.

                        Only one type can be the default one for given object class. Setting this flag to true for more
                        than one type is an error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="objectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        For object type definition:

                        Object class (like ri:inetOrgPerson) for this resource object type.
                        MOVED TO "delineation".

                        For refined object class definition:

                        Name of object class (like ri:inetOrgPerson) that is refined by this definition.
                        In this case, this property should be used here, not in "delineation" definition.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="auxiliaryObjectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        For object type definition:

                        The reference to additional object classes 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.

                        DEPRECATED. MOVED TO "delineation".

                        For object class definition: Should not be used at all.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.6</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="auxiliaryObjectClassMappings" type="tns:ResourceBidirectionalMappingAndDefinitionType">
                <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 minOccurs="0" name="multiplicity" type="tns:ResourceObjectMultiplicityType">
                <xsd:annotation>
                    <xsd:documentation>
                        Describes how "multi-accounts" are treated for this object type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="delineation" type="tns:ResourceObjectTypeDelineationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Delineates (defines) the set of objects corresponding to this object type, e.g.
                        by providing object class(es), a base context and/or a search filter.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="baseContext" type="tns:ResourceObjectReferenceType">
                <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.

                        DEPRECATED: set the value in "delineation" instead
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.6</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="searchHierarchyScope" type="tns:SearchHierarchyScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of search hierarchy scope. It specifies how "deep" the search should go
                        into the object hierarchy. It is only applicable to resources that support hierarchical
                        organization of objects (e.g. LDAP resources).

                        DEPRECATED: set the value in delineation instead
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.0</a:since>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.6</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="focus" type="tns:ResourceObjectFocusSpecificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Type and archetype (optional) of the focus objects that correspond to this resource object type.
                        If not specified (neither here nor in legacy synchronization configuration), the UserType is assumed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <!-- Data protection "basis" may be specified here. -->
            <xsd:element minOccurs="0" name="provenance" type="tns:ProvenanceFeedDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies provenance properties that should be associated with data that originate here.
                        Resource objects of the type that is defined here will be assumed to have the provenance specified
                        in this data structure.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.2</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:ResourceAttributeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of handling of resource object attributes.
                        This overrides annotations in the resource schema.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="dependency" type="tns:ResourceObjectTypeDependencyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of dependencies of this object type on other type or types.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="association" type="tns:ResourceObjectAssociationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of associations for this object types. Associations do not always have the same physical
                        manifestation as attributes, i.e. they are not always directly visible on the raw resource object.
                        They may be represented implicitly e.g. in the form of group membership.

                        DEPRECATED. Use association types (in schemaHandling) instead.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.9</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="volatility" type="tns:ResourceObjectVolatilityType">
                <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 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 minOccurs="0" name="iteration" type="tns:IterationSpecificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of an iteration process where the unique identifier (e.g. a name) of the resource object
                        is determined iteratively: taking the first "available" value. Like trying smith1, smith2, and so on;
                        until the unused one is found.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="protected" type="tns:ResourceObjectPatternType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specification of a protected resource object: one that cannot be affected by IDM. It will be
                        ignored by operations, will not appear in lists, etc. A typical example is the administrator's account.

                        DEPRECATED: Use "marking" instead.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.9</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="marking" type="tns:ShadowMarkingConfigurationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Drives automatic marking of shadows, e.g., as protected objects.
                        Each mark should have at most one entry in this object, in order to avoid conflicting information.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="defaultOperationPolicy" type="tns:DefaultOperationPolicyConfigurationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Default operation policy for those operations that do not have their behavior specified explicitly
                        via object marks.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="activation" type="tns:ResourceActivationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of activation handling for this account type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="credentials" type="tns:ResourceCredentialsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of credentials handling for this account type.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="behavior" type="tns:ResourceBehaviorDefinitionType"/>
            <xsd:element minOccurs="0" name="securityPolicyRef" type="c:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                            Reference to the object type security policy settings.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:SecurityPolicyType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="lifecycle" 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 minOccurs="0" name="configuredCapabilities" type="cap:CapabilityCollectionType">
                <xsd:annotation>
                    <xsd:documentation>
                        The configured capabilities of the resource specific to this object type.

                        This part contains "tweaks" of the native capabilities.
                        Some 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.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="caching" type="tns:ShadowCachingPolicyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of shadow caching at the object class or object type level.
                        It is merged with resource-level definition using standard merging algorithm.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="projection" type="tns:ProjectionPolicyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Object type related account synchronization settings.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="mappingsEvaluation" type="tns:ResourceMappingsEvaluationConfigurationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Settings related to evaluation of mappings for this object type.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="correlation" type="tns:CorrelationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        How objects of this type are correlated to focus objects?
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="synchronization" type="tns:SynchronizationReactionsType">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines reactions to specific synchronization-related situations (like "unmatched resource object",
                        or "disputed" (owner), and so on.

                        Before 4.6, this information was part of the "synchronization" section of the resource definition.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ShadowMarkingConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                How is given shadow mark automatically applied to shadows.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
                <a:naturalKey>tns:markRef</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="markRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to the mark to which this configuration applies.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:MarkType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="always" minOccurs="0" name="applicationTime" type="tns:ShadowMarkApplicationTimeType">
                <xsd:annotation>
                    <xsd:documentation>
                        On what occasion(s) is the marking done? E.g., always or for newly discovered shadows only.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="pattern" type="tns:ResourceObjectPatternType">
                <xsd:annotation>
                    <xsd:documentation>
                        The pattern(s) used to describe the matching objects.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="DefaultOperationPolicyConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Default operation policy for those operations that do not have their behavior specified explicitly
                via object marks. I.e., if there is no mark for specific shadow, or if the mark(s) do not specify
                the policy explicitly, the policy is determined by the mark referenced here.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="policyRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        The mark carrying the policy. It should have the archetype of "Shadow policy mark".
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:MarkType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:lifecycleState"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:simpleType name="ShadowMarkApplicationTimeType">
        <xsd:annotation>
            <xsd:documentation>
                On what occasion(s) is the marking done?
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="always">
                <xsd:annotation>
                    <xsd:documentation>
                        Marking is done always when the shadow is seen. This includes also when it's being added by midPoint.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALWAYS"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="classification">
                <xsd:annotation>
                    <xsd:documentation>
                        Marking is done when the shadow is being classified (this implies that it's being discovered by midPoint).
                        Either at the first classification time, or when its classification changes.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CLASSIFICATION"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="AssociatedResourceObjectTypeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of an associated object.

                Experimental, temporary, unsupported.

                TODO reconsider if really needed
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:experimental>true</a:experimental>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ResourceObjectTypeDefinitionType">
                <xsd:sequence>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ResourceObjectTypeIdentificationType">
        <xsd:annotation>
            <xsd:documentation>
                References an object type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:sequence>
                <xsd:element minOccurs="0" name="kind" type="tns:ShadowKindType">
                    <xsd:annotation>
                        <xsd:documentation>
                            Kind of the parent type. Must be specified.
                        </xsd:documentation>
                    </xsd:annotation>
                </xsd:element>
                <xsd:element minOccurs="0" name="intent" type="xsd:string">
                    <xsd:annotation>
                        <xsd:documentation>
                            Intent of the parent type. Must be specified.
                        </xsd:documentation>
                    </xsd:annotation>
                </xsd:element>
            </xsd:sequence>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="resourceObjectTypeIdentification" type="tns:ResourceObjectTypeIdentificationType"/>

    <xsd:complexType name="ResourceObjectFocusSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                Specification of focus objects corresponding to given resource object type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="type" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        Type of the focus objects. The default is derived from associated object type, or UserType (otherwise).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="archetypeRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        Focus archetype corresponding to this resource object type. If specified, the value is enforced upon
                        focus objects that have a projection of this object type linked. It is also used during correlation,
                        i.e. when correlating a resource object of this type, midPoint looks for focus objects having
                        specified archetype.

                        Notes:

                        1. The archetype must be a structural one (currently). In the future, we may consider allowing
                        multiple (i.e. structural and/or auxiliary) archetypes here.

                        2. The enforcement means that if the focus has no archetype, the archetype is added to the focus.
                        If it has a different archetype, a policy violation exception is raised. This behavior may change in the
                        future, e.g. this behavior may become configurable.

                        3. The enforcement is done for _all_ projections, i.e. also the ones that are created by the clockwork.
                        But beware of the timing: if a projection is added during the clockwork run, and that projection enforces
                        an archetype, the effects of this enforcement may be limited during the current clockwork run.
                        For example, if the archetype induces some projections, they might not be created because of the
                        processing in waves. Generally speaking, it is safer to set the focus archetype explicitly (e.g. by
                        primary delta or in the object template) in these cases.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <xsd:appinfo>
                            <a:objectReferenceTargetType>tns:ArchetypeType</a:objectReferenceTargetType>
                        </xsd:appinfo>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="assignmentSubtype" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Subtype of the assignment to which this resource object is mapped (if applicable).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <!--<xsd:complexType name="AssignmentTargetSpecificationType">-->
    <!--    <xsd:annotation>-->
    <!--        <xsd:documentation>-->
    <!--            TODO-->
    <!--        </xsd:documentation>-->
    <!--        <xsd:appinfo>-->
    <!--            <a:container/>-->
    <!--            <a:since>4.9</a:since>-->
    <!--        </xsd:appinfo>-->
    <!--    </xsd:annotation>-->
    <!--    <xsd:sequence>-->
    <!--        <xsd:element name="type" type="xsd:QName" minOccurs="0">-->
    <!--            <xsd:annotation>-->
    <!--                <xsd:documentation>-->
    <!--                    Type of the focus objects.-->
    <!--                </xsd:documentation>-->
    <!--            </xsd:annotation>-->
    <!--        </xsd:element>-->
    <!--        &lt;!&ndash;<xsd:element name="archetypeRef" type="tns:ObjectReferenceType" minOccurs="0">&ndash;&gt;-->
    <!--        &lt;!&ndash;    <xsd:annotation>&ndash;&gt;-->
    <!--        &lt;!&ndash;        <xsd:documentation>&ndash;&gt;-->
    <!--        &lt;!&ndash;            TODO&ndash;&gt;-->
    <!--        &lt;!&ndash;        </xsd:documentation>&ndash;&gt;-->
    <!--        &lt;!&ndash;        <xsd:appinfo>&ndash;&gt;-->
    <!--        &lt;!&ndash;            <xsd:appinfo>&ndash;&gt;-->
    <!--        &lt;!&ndash;                <a:objectReferenceTargetType>tns:ArchetypeType</a:objectReferenceTargetType>&ndash;&gt;-->
    <!--        &lt;!&ndash;            </xsd:appinfo>&ndash;&gt;-->
    <!--        &lt;!&ndash;        </xsd:appinfo>&ndash;&gt;-->
    <!--        &lt;!&ndash;    </xsd:annotation>&ndash;&gt;-->
    <!--        &lt;!&ndash;</xsd:element>&ndash;&gt;-->
    <!--    </xsd:sequence>-->
    <!--    <xsd:attribute name="id" type="xsd:long"/>-->
    <!--</xsd:complexType>-->

    <xsd:complexType name="ResourceMappingsEvaluationConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of inbound/outbound resource mappings evaluation.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.5</a:since>
                <a:experimental>true</a:experimental>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="inbound" type="tns:InboundMappingsEvaluationConfigurationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Evaluation of inbound mappings.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="InboundMappingsEvaluationConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Configuration of inbound mappings evaluation.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.5</a:since>
                <a:experimental>true</a:experimental>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="defaultEvaluationPhases" type="tns:DefaultInboundMappingEvaluationPhasesType">
                <xsd:annotation>
                    <xsd:documentation>
                        Default phases in which mappings are evaluated.
                        If not specified, clockwork phase is assumed.
                        (The default may change in the future.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:simpleType name="SearchHierarchyScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of search hierarchy scope. It specifies how "deep" the search should go
                into the object hierarchy. It is only applicable to resources that support hierarchical
                organization of objects (e.g. LDAP resources).
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.0</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="sub">
                <xsd:annotation>
                    <xsd:documentation>
                        Subtree search. The search go deep down the hierarchy, as deep as possible.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SUB"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="one">
                <xsd:annotation>
                    <xsd:documentation>
                        One-level search. The search is reaching just one level below the base context object.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <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/>
                <a:schemaMigration>
                    <a:element>tns:postpone</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:reshreshOnRead</a:element>
                    <a:version>4.6</a:version>
                    <a:operation>moved</a:operation>
                    <a:replacement>tns:refreshOnRead</a:replacement>
                </a:schemaMigration>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="false" minOccurs="0" name="avoidDuplicateValues" type="xsd:boolean">
                <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 default="none" minOccurs="0" name="shadowConstraintsCheck" type="tns: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:annotation>
            </xsd:element>
            <xsd:element default="false" minOccurs="0" name="useProposedShadows" type="xsd:boolean">
                <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 default="asynchronous" minOccurs="0" name="recordPendingOperations" type="tns:RecordPendingOperationsType">
                <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 default="false" minOccurs="0" name="avoidDuplicateOperations" type="xsd:boolean">
                <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 minOccurs="0" name="operationGroupingInterval" type="xsd:duration">
                <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 delayed 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 costly (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 default="false" minOccurs="0" name="validateSchema" type="xsd:boolean">
                <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 data types 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 default="false" minOccurs="0" name="caseIgnoreAttributeNames" type="xsd:boolean">
                <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 default="true" minOccurs="0" name="discovery" type="xsd:boolean"/>
            <xsd:element minOccurs="0" name="connectorErrorCriticality" type="tns:ErrorSelectorType">
                <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 error 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 unpredictable.
                        If you use this setting then you are on your own. Hic sunt leones.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="pendingOperationGracePeriod" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Duration for which the completed asynchronous operations that are kept in the
                        shadow objects are considered during computation. This may be needed to avoid
                        repeating operations in semi-manual resources.
                        By default there is no grace period and completed operations are not considered
                        during computations.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="P1D" minOccurs="0" name="pendingOperationRetentionPeriod" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Duration for which the completed asynchronous operations will be kept in the
                        shadow objects. This may be desirable for visibility, e.g. if the administrator
                        wants to inspect result of an asynchronous operation.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.6</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="PT30M" minOccurs="0" name="operationRetryPeriod" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Duration for which the system will wait before re-trying failed operation.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="3" minOccurs="0" name="operationRetryMaxAttempts" type="xsd:int">
                <xsd:annotation>
                    <xsd:documentation>
                        Maximum number of attempts to re-try a failed operation.
                        If set to 0 then operation re-tries are disabled.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="P7D" minOccurs="0" name="deadShadowRetentionPeriod" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Duration for which the system will keep dead shadows. After this interval has
                        passed the dead shadows are deleted.
                        Note: this may also be influenced by pendingOperationGracePeriod. Dead shadow
                        may be kept for longer than the interval specified in deadShadowRetentionPeriod
                        if that is needed to for evaluation of grace period.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="false" minOccurs="0" name="refreshOnRead" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        If set to true then midPoint will always refresh shadow when it is retrieved.
                        Refreshing a shadow means that the status of asynchronous (e.g. manual) operations
                        is checked, unfinished operations may be retried and so on. In this case shadow
                        will always be as fresh as it can be. But read may be slower and there may be
                        strange errors (e.g. reading a shadow may cause "already exists" error because
                        pending ADD operation in the shadow was executed during that read).
                        If set to false (which is the default) then refresh will not be executed during
                        read operations - unless the refresh is explicitly requested by midPoint code
                        (e.g. during reconciliation).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.3</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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 recorded 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="AbstractShadowAssociationTypeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of a shadow association type: parts that are common for native and simulated association types.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ShadowAssociationTypeDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                <p>
                    Definition of a high-level (logical) association type. Such an association binds together a subject
                    and 0, 1, or more objects. Some examples:
                </p>
                <ul>
                    <li>Simple group membership: This is an association between objects (users, printers, computers, groups,
                        org units, and so on) and groups. Each object can belong to 0-N groups, and each group can have 0-N
                        members. There are no additional attributes related to the membership itself.</li>
                    <li>Complex group membership: Likewise, this is an association between objects and groups, but each
                        association value can have some attributes, like the time validity.</li>
                    <li>Access rights: This is an association between principals (e.g., users) and objects (e.g., documents),
                        where each association value has an attribute describing the access level (reader, writer, admin, ...).</li>
                    <li>Employment contracts: An association connecting physical persons and organizational units; optionally
                        it can also embrace other entities, like cost centers, job positions, and so on, if they are represented
                        as separate objects on the resource. In its most extreme form, a contract can have no objects, just
                        a subject (person).</li>
                </ul>
                <p>
                    An association type can be defined over either native or simulated (physical) shadow reference.
                    Legacy simulated associations are not supported by association types.
                </p>
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
                <a:naturalKey>tns:name</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="name" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation> <!-- TODO what about using xsd:string here? -->
                        The name of the association type. It must be either unqualified, or in the "ri" namespace.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:displayName"/>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" ref="tns:lifecycleState"/>
            <xsd:element name="subject" type="tns:ShadowAssociationTypeSubjectDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of the "subject" participant of the association. Typically, but not necessarily, here we
                        have resource objects corresponding to persons or user accounts.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="object" type="tns:ShadowAssociationTypeObjectDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of the "object" participant of participants of the association.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="associationObject" type="tns:AssociatedResourceObjectTypeDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        If the association contains its own data (as a separate resource object), they can be defined
                        here. Although formally an object type definition, please use only the type identifier
                        and delineation here.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowAssociationTypeDefinition" type="tns:ShadowAssociationTypeDefinitionType"/>

    <xsd:complexType name="ShadowAssociationTypeSubjectDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of the "subject" participant of the association type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ShadowAssociationTypeParticipantDefinitionType">
                <!-- nothing here for now -->
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="ShadowAssociationTypeSubjectDefinition" type="tns:ShadowAssociationTypeSubjectDefinitionType"/>

    <xsd:complexType name="ShadowAssociationTypeObjectDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of the "object" participant of the association type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ShadowAssociationTypeParticipantDefinitionType">
                <!-- nothing here for now -->
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="ShadowAssociationTypeObjectDefinition" type="tns:ShadowAssociationTypeObjectDefinitionType"/>

    <xsd:complexType name="ShadowAssociationTypeParticipantDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of a participant (subject or object) of an association type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="ref" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        If the association has more than one object, this property points to the one which we define here.

                        Unnecessary for simple associations.
                        Please leave undefined for subject definitions.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectType" type="tns:ResourceObjectTypeIdentificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                            Resource object type or types that are allowed to participate in this association.
                            (Abstract types are not supported here for now.)
                        </p>
                        <p>
                            For subjects: selects object types onto which this association type definition should be applied.
                            (The behavior for types not covered is to be decided - TODO.)
                        </p>
                        <p>
                            If not specified: it is applied to all subjects.
                        </p>
                        <p>
                            For objects: hides non-matching reference values.
                        </p>
                        <p>
                            If not specified: no reference values are hidden, beyond what is provided by the reference
                            type definition (native or simulated).
                        </p>
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="association" type="tns:ShadowAssociationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        The definition of the association as seen by this participant.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <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 minOccurs="0" name="administrativeState" type="tns:ResourceAdministrativeStateType"/>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="approverRef" type="c:ObjectReferenceType">
                <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 maxOccurs="unbounded" minOccurs="0" name="ownerRef" type="c:ObjectReferenceType">
                <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:element maxOccurs="unbounded" minOccurs="0" name="operatorRef" type="c:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to users that should execute operations on manual resources.
                        It may point to user, role (only role members) or organization (only direct org. members).
                        If more than one operator is specified they are considered equivalent.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.8</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="operatorActionMaxDuration" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Maximal duration of the operator action. It is used to derive deadline for the corresponding work item(s).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.0</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="correlatorRef" type="c:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to users that should execute manual correlation operations.
                        It may point to user, role (only role members) or organization (only direct org. members).
                        If more than one user is specified they are considered equivalent.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="correlatorActionMaxDuration" type="xsd:duration">
                <xsd:annotation>
                    <xsd:documentation>
                        Maximal duration of the correlator action. It is used to derive deadline for the corresponding
                        work item(s).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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 state.
            </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="ResourceObjectTypeDependencyType">
        <xsd:annotation>
            <xsd:documentation>
                Describes a dependency of an object type on another object type.
                For example, a role may have two Active Directory projections: an OU and a group residing in that OU.
                We say that the group depends on the OU: the OU has to be provisioned first; and only after that, the group
                can be created. When de-provisioning, the group has to be deleted first, and the OU only after that.

                We call the group the "dependent object" or "depender". The OU is a "dependee".

                This data structure has to reside within the dependent object (depender).
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="resourceRef" type="c:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        A resource this object type depends on.
                        If not specified, the current resource is assumed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:ResourceType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="kind" type="tns:ShadowKindType">
                <xsd:annotation>
                    <xsd:documentation>
                        The "kind" part of the target object type identification.
                        If not specified, the kind of the current object type (i.e. the dependent one) is assumed.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="intent" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        The "intent" part of the target object type identification.
                        If not specified, the default type for given kind is assumed. (See "defaultForKind" flag.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="strictness" type="tns:ResourceObjectTypeDependencyStrictnessType"/>
            <xsd:element default="0" minOccurs="0" name="order" type="xsd:int">
                <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 default="false" minOccurs="0" name="forceLoad" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies if the shadow on which we depend has to be loaded. By default, we do
                        not force loading full dependent shadow.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="none" minOccurs="0" name="dataBinding" type="tns:ResourceObjectTypeDependencyDataBindingKindType">
                <xsd:annotation>
                    <xsd:documentation>
                        Are the attributes of the dependent object bound to the dependee attributes in any way?
                        For example, in AD, if the distinguished name of an OU (dependee) changes, the DNs of all dependent
                        objects (e.g. groups within that OU) change as well.

                        EXPERIMENTAL. Mainly to implement MID-8929. Maybe it will not be needed in the future.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.8</a:since>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </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:simpleType name="ResourceObjectTypeDependencyDataBindingKindType">
        <xsd:annotation>
            <xsd:documentation>
                Level of binding between dependent resource objects.
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.8</a:since>
                <a:experimental>true</a:experimental>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        Attributes of the dependent resource objects are not bound in any way.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="some">
                <xsd:annotation>
                    <xsd:documentation>
                        There is some binding between attributes of the dependent resource objects, but the exact character
                        of this binding is not known or specified. We must assume that anything can happen when the dependee
                        object changes.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SOME"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <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/>
                <a:naturalKey>tns:ref</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ItemRefinedDefinitionType">
                <xsd:sequence>
                    <xsd:element default="false" minOccurs="0" name="exclusiveStrong" type="xsd:boolean">
                        <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:appinfo>
                                <a:displayName>ResourceItemDefinitionType.exclusiveStrong</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="modificationPriority" type="xsd:int">
                        <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:appinfo>
                                <a:displayName>ResourceItemDefinitionType.modificationPriority</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="readReplaceMode" type="xsd:boolean">
                        <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:appinfo>
                                <a:displayName>ResourceItemDefinitionType.readReplaceMode</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="secondaryIdentifier" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Indicated if the attribute should be considered as secondary identifier. If set to true,
                                this attribute is stored in repository and used for example by synchronization (correlation
                                rule), consistency mechanism, etc.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceItemDefinitionType.secondaryIdentifier</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="volatilityTrigger" type="xsd:boolean">
                        <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.

                                DEPRECATED. Use "volatility" instead.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>3.4</a:since>
                                <a:since>3.3.1</a:since>
                                <a:displayName>ResourceItemDefinitionType.volatilityTrigger</a:displayName>
                                <a:deprecated>true</a:deprecated>
                                <a:deprecatedSince>4.9.1</a:deprecatedSince>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="volatility" type="tns:ShadowItemVolatilityType">
                        <xsd:annotation>
                            <xsd:documentation>
                                The behavior of this attribute that differs from the "pure data store" expectations.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="displayNameAttribute" type="xsd:boolean">
                        <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:appinfo>
                                <a:displayName>ResourceItemDefinitionType.displayNameAttribute</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>

                    <xsd:element minOccurs="0" name="fetchStrategy" type="tns:AttributeFetchStrategyType">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <a:displayName>ResourceItemDefinitionType.fetchStrategy</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="storageStrategy" type="tns:AttributeStorageStrategyType">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <a:displayName>ResourceItemDefinitionType.storageStrategy</a:displayName>
                                <a:since>4.0</a:since>
                                <a:experimental>true</a:experimental>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="cached" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Overrides the default inclusion/exclusion of this item into shadow caching.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceItemDefinitionType.caching</a:displayName>
                                <a:since>4.9</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="outbound" type="tns:MappingType">
                        <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 elsewhere 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:appinfo>
                                <a:displayName>ResourceItemDefinitionType.outbound</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:InboundMappingType">
                        <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 assignment is needed here, especially a simple way how
                                to express assignment target. Some rules may use that information and we definitely need that
                                to
                                generate correct relative change descriptions.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceItemDefinitionType.inbound</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ShadowItemVolatilityType">
        <xsd:annotation>
            <xsd:documentation>
                The behavior of a shadow item that differs from the "pure data store" expectations.
                Describes how the item can change without explicit request by midPoint, optionally in relation to other
                items in this or other resource objects.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="incoming" type="tns:ShadowItemDependencyType"> <!-- temporarily single-valued -->
                <xsd:annotation>
                    <xsd:documentation>
                        Items on which this item may depend on - i.e., whose values or changes may affect the values
                        of the item being considered.

                        Note: Currently no specific items can be provided here, only the operation(s) relevant for this dependency.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="outgoing" type="tns:ShadowItemDependencyType"> <!-- temporarily single-valued -->
                <xsd:annotation>
                    <xsd:documentation>
                        Items that may depend on this item - i.e., whose that may be affected by values or changes of this item.
                        Currently, only "modify" operation is supported here.

                        Note: Currently no specific items can be provided here, only the operation(s) relevant for this dependency.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowItemVolatility" type="tns:ShadowItemVolatilityType"/>

    <xsd:complexType name="ShadowItemDependencyType">
        <xsd:annotation>
            <xsd:documentation>
                Describes a dependency between shadow items.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <!-- Here will come specific items that are source or target of this dependency -->
            <!-- Also, an expression that provides the expected outcome of this dependency may come here -->
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="operation" type="t:ChangeTypeType">
                <xsd:annotation>
                    <xsd:documentation>
                        During which operation(s) does this dependency manifests itself. (DELETE is not relevant for now.)
                        When unspecified, all operations are expected.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowItemDependency" type="tns:ShadowItemDependencyType"/>

    <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="ResourceLastLoginTimestampDefinitionType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9.1</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="fetchStrategy" type="tns:AttributeFetchStrategyType"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ResourcePasswordDefinitionType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
                <a:schemaMigration>
                    <a:element>tns:passwordPolicyRef</a:element>
                    <a:version>4.4</a:version>
                    <a:operation>removed</a:operation>
                    <a:comment>Use securityPolicyRef in objectType element (ResourceObjectTypeDefinitionType) instead.</a:comment>
                </a:schemaMigration>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="fetchStrategy" type="tns:AttributeFetchStrategyType"/>
            <xsd:element default="auto" minOccurs="0" name="compareStrategy" type="tns:PasswordCompareStrategyType">
                <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 password. 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 maxOccurs="unbounded" minOccurs="0" name="outbound" type="tns:MappingType">
                <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:appinfo>
                        <a:displayName>ResourcePasswordDefinitionType.outbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:MappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines how user password is constructed if the user is created or updated from this account.
                        The "target" part of the assignment is implicitly set to user's password, therefore it may be
                        omitted.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourcePasswordDefinitionType.inbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="caching" type="tns:CachingPolicyType">
                <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:attribute name="id" type="xsd:long"/>
    </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 minOccurs="0" name="existence" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Mapping for resource object existence. This mapping decides whether the resource object
                        should exist at all.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayOrder>80</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="administrativeStatus" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Mapping for activation administrative status.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayOrder>10</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="validFrom" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Mapping for activation start of validity.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayOrder>50</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="validTo" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Mapping for activation end of validity.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayOrder>60</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="lockoutStatus" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Mapping for activation lockout status.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayOrder>70</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="disableInsteadOfDelete" type="tns:AbstractPredefinedActivationMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        If an account is unassigned and there is no other existing assignment for an account midPoint
                        will de-provisioning that account. Which means that the account will be deleted.
                        This is the default behavior. But it can be changed. This configuration change default behavior
                        and account will be disabled instead delete.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.8</a:since>
                        <a:displayOrder>20</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="delayedDelete" type="tns:DelayedDeleteActivationMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        If an account is unassigned and there is no other existing assignment for an account midPoint
                        will de-provisioning that account. Which means that the account will be deleted.
                        This is the default behavior. But it can be changed. This configuration change default behavior
                        and account will delete with delay and meanwhile account will be disabled.

                        We use activation/disableTimestamp from shadow object
                        as reference attribute. As disable reason we use de-provision or mapped.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.8</a:since>
                        <a:displayOrder>30</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="preProvision" type="tns:PreProvisionActivationMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        This configuration will pre-provision a disabled account defined time
                        before focus’s activation/validFrom date.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.8</a:since>
                        <a:displayOrder>40</a:displayOrder>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="AbstractPredefinedActivationMappingType">
        <xsd:annotation>
            <xsd:documentation>
                Basic super type for predefined configuration of account activation.
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.8</a:since>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" ref="tns:lifecycleState">
                <xsd:annotation>
                    <xsd:documentation>
                        Lifecycle state of predefined configuration of account activation.
                        Production configuration consists (by default) of `active` and `deprecated` ones.
                        Development configuration consists (by default) of `active` and `proposed` ones.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ObjectType.lifecycleState</a:displayName>
                        <a:valueEnumerationRef oid="00000000-0000-0000-0000-000000000230" type="tns:LookupTableType"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="DelayedDeleteActivationMappingType">
        <xsd:annotation>
            <xsd:documentation>
                If an account is unassigned and there is no other existing assignment for an account midPoint
                will de-provisioning that account. Which means that the account will be deleted. This is the default behavior.
                But it can be changed. This configuration change default behavior and account will delete with delay
                and meanwhile account will be disabled.
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.8</a:since>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractPredefinedActivationMappingType">
                <xsd:sequence>
                    <xsd:element name="deleteAfter" type="xsd:duration">
                        <xsd:annotation>
                            <xsd:documentation>
                                The time after which the account will be deleted.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="PreProvisionActivationMappingType">
        <xsd:annotation>
            <xsd:documentation>
                This configuration will pre-provision a disabled account defined time before focus's activation/validFrom date.
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.8</a:since>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractPredefinedActivationMappingType">
                <xsd:sequence>
                    <xsd:element name="createBefore" type="xsd:duration">
                        <xsd:annotation>
                            <xsd:documentation>
                                Time determines how long before date, from activation/validFrom attribute,
                                disabled account will be created.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </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 minOccurs="0" name="lifecycleState" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Lifecycle state mapping. This mapping influences how shadow lifecycle state and focus
                        lifecycle state are mapped. Reserved for future use.

                        Note that the original outbound mapping for shadow lifecycle (from 3.6 up to 4.7) was
                        transformed into the "purpose" mapping in 4.8. To avoid confusion, it is considered
                        a configuration error if the outbound mappings are here in 4.8.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="purpose" type="tns:ResourceBidirectionalMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        The outbound mapping for shadow purpose.
                        The default mapping is somehow smart algorithm that will consider presence of the focus password,
                        resource password capability, operation and so on, in order to determine whether the purpose
                        of the resource object is "regular" or "incomplete".
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.8</a:since>
                    </xsd:appinfo>
                </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:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ResourceBidirectionalMappingType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="fetchStrategy" type="tns:AttributeFetchStrategyType"/>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="outbound" type="tns:MappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Maps information outbound from midpoint to the resource.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourceBidirectionalMappingType.outbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:MappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Maps information inbound to midpoint from the resource.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ResourceBidirectionalMappingType.inbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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 minOccurs="0" name="tolerant" type="xsd:boolean">
                        <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="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:appinfo>
                <a:schemaMigration>
                    <a:element>icfs:name</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>icfs:uid</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:container/>
                <a:naturalKey>tns:filter</a:naturalKey>
                <!-- Inherits schema context from ResourceObjectTypeDefinitionType-->
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="filter" type="q:SearchFilterType">
                <xsd:annotation>
                    <xsd:documentation>
                        The filter used to match the object. If the object matches then it is regarded to be
                        protected.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ResourceObjectMultiplicityType">
        <xsd:annotation>
            <xsd:documentation>
                Describes how "multi-accounts" are treated for given object type.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.0</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="1" minOccurs="0" name="maxOccurs" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Maximum number of instances of that particular projections that can be linked to the same focus.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="tag" type="tns:ShadowTagSpecificationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Specifies how shadow tags should be generated.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ShadowTagSpecificationType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.0</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <!-- TODO? Some default algorithm? -->
            <xsd:element minOccurs="0" name="expression" type="tns:ExpressionType">
                <xsd:annotation>
                    <xsd:documentation>
                        An expression providing tag value for given shadow (found on a resource).
                        Expects $shadow ($projection) variable containing the shadowed resource object.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="outbound" type="tns:MappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        An outbound mapping that provides a value (or values) for the shadow tag when assigned resource
                        object construction is evaluated. Expects $focus variable as well as assignment path-related ones.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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/>
                <a:schemaContext>
                    <a:type>tns:ShadowType</a:type> <!-- probably new resolver/algorithm will be needed-->
                </a:schemaContext>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="objectClass" type="xsd:QName">
                <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 minOccurs="0" name="filter" type="q:SearchFilterType">
                <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 minOccurs="0" name="shadowRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reference to shadow that represents the resource object. If present, then it will be
                        used directly. (Unless resolutionFrequency is ALWAYS.)

                        If not present then the search filter will be used to locate the shadow. (Unless resolutionFrequency
                        is NONE.)

                        In the future, midPoint will store the resolved shadow OID into this field. But this is not yet
                        implemented.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:ShadowType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="repository" minOccurs="0" name="resolutionStrategy" type="tns:ResourceObjectReferenceResolutionStrategyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Not implemented yet. Search on resource is always executed.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="once" minOccurs="0" name="resolutionFrequency" type="tns:ResourceObjectReferenceResolutionFrequencyType">
                <xsd:annotation>
                    <xsd:documentation>
                        The strategy used to resolve resource object references. However, only ALWAYS and NEVER ones
                        are fully implemented. The default ONCE strategy works like ALWAYS: the filter is evaluated
                        but the result is not stored in the definition.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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 resolve 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 minOccurs="0" name="auxiliaryObjectClass" type="xsd:QName">
                        <xsd:annotation>
                            <xsd:documentation>
                                This association is considered valid only if the resource object (subject)
                                has the specified auxiliary object class.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceObjectAssociationType.auxiliaryObjectClass</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="entitlement" minOccurs="0" name="kind" type="tns:ShadowKindType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Kind of objects associated through this association type.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceObjectAssociationType.kind</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="intent" type="xsd:string">
                        <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.

                                If no intents are specified, then object type definition of given kind, and
                                defaultForKind = true (or default = true) is used.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ResourceObjectAssociationType.intent</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="direction" type="tns:ResourceObjectAssociationDirectionType">
                        <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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.direction</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="associationAttribute" type="xsd:QName">
                        <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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.associationAttribute</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="valueAttribute" type="xsd:QName">
                        <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 modified 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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.valueAttribute</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="shortcutAssociationAttribute" type="xsd:QName">
                        <xsd:annotation>
                            <xsd:documentation>
                                Association attribute short-cut. There are cases when an 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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.shortcutAssociationAttribute</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="shortcutValueAttribute" type="xsd:QName">
                        <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 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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.shortcutValueAttribute</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="true" minOccurs="0" name="explicitReferentialIntegrity" type="xsd:boolean">
                        <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:appinfo>
                                <a:displayName>ResourceObjectAssociationType.explicitReferentialIntegrity</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ShadowAssociationDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of an association (for specific participant).
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="ref" type="t:ItemPathType">
                <xsd:annotation>
                    <xsd:documentation>
                        Path of the association that this definition describes.
                        It may be the name of an existing reference attribute, or (in the future) it may be a separate one.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="sourceAttributeRef" type="t:ItemPathType">
                <xsd:annotation>
                    <xsd:documentation>
                        The name of the reference attribute this association is based on.
                        The default is the name of the association.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="outbound" type="tns:MappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound mapping(s) for the association.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ShadowAssociationDefinitionType.outbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:InboundMappingType">
                <xsd:annotation>
                    <xsd:documentation>
                        Inbound mapping(s) for the association.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ShadowAssociationDefinitionType.inbound</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <!-- The following elements are probably useful, but they are not used in 4.9. Especially for activation, we have to
                    think out how the mappings should be realized. -->

            <!--<xsd:element name="attribute" type="tns:ResourceAttributeDefinitionType" minOccurs="0" maxOccurs="unbounded">-->
            <!--    <xsd:annotation>-->
            <!--        <xsd:documentation>-->
            <!--            NO INBOUND/OUTBOUND MAPPINGS HERE! Only e.g. displayName and such. -->
            <!--        </xsd:documentation>-->
            <!--    </xsd:annotation>-->
            <!--</xsd:element>-->
            <!--<xsd:element name="objectRef" type="tns:ResourceAttributeDefinitionType" minOccurs="0" maxOccurs="unbounded">-->
            <!--    <xsd:annotation>-->
            <!--        <xsd:documentation>-->
            <!--            NO INBOUND/OUTBOUND MAPPINGS HERE! Only e.g. displayName and such. -->
            <!--        </xsd:documentation>-->
            <!--    </xsd:annotation>-->
            <!--</xsd:element>-->
            <!--<xsd:element name="activation" minOccurs="0" type="tns:ResourceActivationDefinitionType">-->
            <!--    <xsd:annotation>-->
            <!--        <xsd:documentation>-->
            <!--            NO INBOUND/OUTBOUND MAPPINGS HERE!-->
            <!--        </xsd:documentation>-->
            <!--    </xsd:annotation>-->
            <!--</xsd:element>-->
            <xsd:element default="true" minOccurs="0" name="tolerant" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        When set to true, allows association values that are set outside midPoint.
                        When true, midPoint will only remove values that are computed as being deleted by the 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.

                        May be overridden by shadow marks.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AbstractAttributeMappingsDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Defines mapping(s) for an attribute.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="ref" type="t:ItemPathType">
                <xsd:annotation>
                    <xsd:documentation>
                        Path of the attribute that this definition describes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AttributeOutboundMappingsDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Defines outbound mapping(s) for an attribute.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractAttributeMappingsDefinitionType">
            <xsd:sequence>
                <xsd:element maxOccurs="unbounded" minOccurs="0" name="mapping" type="tns:MappingType">
                    <xsd:annotation>
                        <xsd:documentation>
                            The mappings for the attribute.
                        </xsd:documentation>
                    </xsd:annotation>
                </xsd:element>
            </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="attributeOutboundMappingsDefinition" type="tns:AttributeOutboundMappingsDefinitionType"/>

    <xsd:complexType name="AttributeInboundMappingsDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                Defines inbound mapping(s) for an attribute.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractAttributeMappingsDefinitionType">
                <xsd:sequence>
                    <xsd:element minOccurs="0" name="correlator" type="tns:ItemCorrelatorDefinitionType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Creates a single-item correlator for this attribute.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>AttributeInboundMappingsDefinitionType.correlator</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="mapping" type="tns:InboundMappingType">
                        <xsd:annotation>
                            <xsd:documentation>
                                The mappings for the attribute.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>AttributeInboundMappingsDefinitionType.mapping</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="attributeInboundMappingsDefinition" type="tns:AttributeInboundMappingsDefinitionType"/>

    <xsd:complexType name="AssociationInboundMappingTargetDefinitionType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <!-- Maybe path -->
            <xsd:element minOccurs="0" name="assignmentSubtype" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        If specified, only assignments with this subtype are considered for the processing.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="assignmentTargetType" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        TEMPORARY!
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="set" type="tns:ValueSetDefinitionType">
                <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:sequence>
    </xsd:complexType>

    <xsd:simpleType name="ResourceObjectAssociationDirectionType">
        <xsd:annotation>
            <xsd:documentation>
                Direction of a resource object reference or 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.

                Each capability should have boolean property "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 minOccurs="0" ref="tns:cachingMetadata">
                <xsd:annotation>
                    <xsd:documentation>
                        Metadata defining the "freshness" of the cached copy of native capabilities.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:operational>true</a:operational>
                        <a:alwaysUseForEquals>true</a:alwaysUseForEquals>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="native" type="cap:CapabilityCollectionType">
                <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:appinfo>
                        <a:operational>true</a:operational>
                        <a:alwaysUseForEquals>true</a:alwaysUseForEquals>
                        <a:displayHint>regular</a:displayHint>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="configured" type="cap:CapabilityCollectionType">
                <xsd:annotation>
                    <xsd:documentation>
                        The configured capabilities of the resource. This part contains "tweaks" of the native capabilities.
                        Some 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:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="capabilities" type="tns:CapabilitiesType"/>

    <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 maxOccurs="unbounded" minOccurs="0" name="script" type="tns:OperationProvisioningScriptType">
                <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 maxOccurs="unbounded" minOccurs="0" name="operation" type="tns:ProvisioningOperationTypeType">
                        <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 maxOccurs="unbounded" minOccurs="0" name="kind" type="tns:ShadowKindType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Constraints script execution only to resource objects of a specified kind.
                                If not present then the script will be executed for objects of all kinds.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="intent" type="xsd:string">
                        <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 minOccurs="0" name="condition" type="tns:ExpressionType">
                        <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 default="resource" minOccurs="0" name="host" type="tns:ProvisioningScriptHostType">
                <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 maxOccurs="unbounded" minOccurs="0" name="argument" type="tns:ProvisioningScriptArgumentType">
                <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 default="fatal" minOccurs="0" name="criticality" type="tns:CriticalityType">
                <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 strictly 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 system. 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="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
                marshal/unmarshal) easier.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax">
            </xsd:any>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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, ...)

                DEPRECATED. Use definitions in schemaHandling/objectType (ResourceObjectTypeDefinitionType) instead.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:deprecated>true</a:deprecated>
                <a:deprecatedSince>4.6</a:deprecatedSince>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Free-form name. Used for diagnostics purposes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" name="objectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        Object class that will be processed by this definition.
                        Should be the same as object class in the object type referenced (by kind/intent).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="account" minOccurs="0" name="kind" type="tns:ShadowKindType">
                <xsd:annotation>
                    <xsd:documentation>
                        Shadow kind assumed by this definition. Should be present. If it's not, ACCOUNT is used.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="default" minOccurs="0" name="intent" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        Shadow intent assumed by this definition. Should be present. If it's not, "default" is used.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="focusType" type="xsd:QName">
                <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 default="true" minOccurs="0" name="enabled" type="xsd:boolean">
                <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 losing the
                            configuration and state or for forcing the synchronization engine to "skip" some changes.
                        </p>

                        <p>Note that this is different from 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 minOccurs="0" name="condition" type="c:ExpressionType">
                <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 maxOccurs="unbounded" minOccurs="0" name="correlation" type="tns:ConditionalSearchFilterType">
                <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:appinfo>
                        <a:schemaContext>
                            <a:type>tns:FocusType</a:type>
                        </a:schemaContext>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="confirmation" type="c:ExpressionType">
                <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 relatively 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 minOccurs="0" name="correlationDefinition" type="tns:LegacyCorrelationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of the correlation process.

                        Normally, this would be called "correlation", but that name has been historically used
                        to specify correlation filters. Hence this one.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.5</a:since>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="objectTemplateRef" type="tns:ObjectReferenceType">
                <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 minOccurs="0" name="reconcile" type="xsd:boolean">
                <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 default="false" minOccurs="0" name="limitPropagation" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        If set to true, applicable synchronization reactions will propagate changes only form/to source
                        resource. In the case focus contains 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 default="true" minOccurs="0" name="opportunistic" type="xsd:boolean">
                <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 maxOccurs="unbounded" minOccurs="0" name="reaction" type="tns:LegacySynchronizationReactionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of a synchronization reaction. This is a legacy way how to define synchronization
                        reactions. It is still supported for backward compatibility.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.8</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <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:appinfo>
                <a:container>true</a:container>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="objectSynchronizationSorter" type="tns:ObjectSynchronizationSorterType"/>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectSynchronization" type="tns:ObjectSynchronizationType">
                <xsd:annotation>
                    <xsd:documentation>
                        DEPRECATED. Use object type definitions in schemaHandling instead.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:container>true</a:container>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.6</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ObjectSynchronizationSorterType">
        <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:appinfo>
                <a:container/>
                <a:since>3.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="expression" type="tns:ExpressionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Expression used to divide resource objects to the appropriate kind/intent, objectClass.
                        Can contain also focus and synchronization situation. It should be used in the cases that
                        the resource supports more intents for the same kind and there is a need to have
                        a synchronization for each one. Instead of writing condition to each objectSynchronization
                        part this can simplify configuration.
                        Another usage is for re-classification, e.g. in the first reconciliation run, there were bad
                        conditions for some kind/intents and as s result, the shadow was classified to bad kind/intent,
                        but there is a need to repair it.
                        The expected result is of type ObjectSynchronizationDiscriminatorType
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:element name="objectSynchronizationSorter" type="tns:ObjectSynchronizationSorterType"/>

    <xsd:complexType name="ObjectSynchronizationDiscriminatorType">
        <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:appinfo>
                <!--                   <a:container/> --> <!-- it's not container because of the owner property. -->
                <a:since>3.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="kind" type="tns:ShadowKindType">
                <xsd:annotation>
                    <xsd:documentation>
                        The resulting kind of the resource object. According to this kind specification
                        appropriate objectSynchronization is chosen.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="intent" type="xsd:string">
                <xsd:annotation>
                    <xsd:documentation>
                        The resulting intent of the resource object. According to this intent specification
                        appropriate objectSynchronization is chosen.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="synchronizationSituation" type="tns:SynchronizationSituationType">
                <xsd:annotation>
                    <xsd:documentation>
                        The synchronization situation for the resource object. If set, reaction for the situation is find
                        and the actions are run,
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="owner" type="tns:FocusType">
                <xsd:annotation>
                    <xsd:documentation>
                        The owner of the resource object if known.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="skip" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Overriding synchronization settings if the synchronization of concrete object should be skipped.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="objectSynchronizationDiscriminator" type="tns:ObjectSynchronizationDiscriminatorType"/>

    <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:simpleType name="ItemSynchronizationSituationType">
        <xsd:annotation>
            <xsd:documentation>
                Synchronization situation of an association (or similar) item value.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="matched">
                <xsd:annotation>
                    <xsd:documentation>
                        The corresponding value exists in the focus item.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MATCHED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="matchedIndirectly">
                <xsd:annotation>
                    <xsd:documentation>
                        The target reference exists among references to indirectly assigned abstract roles.
                        (I.e., it is present in current roleMembershipRef values.)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MATCHED_INDIRECTLY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="unmatched">
                <xsd:annotation>
                    <xsd:documentation>
                        The corresponding value does not exist in the focus item.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNMATCHED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="notApplicable">
                <xsd:annotation>
                    <xsd:documentation>
                        The correlation is not applicable or ended with an error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NOT_APPLICABLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="CorrelationSituationType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="uncertain">
                <xsd:annotation>
                    <xsd:documentation>
                        The owner is unclear. Corresponds to DISPUTED synchronization situation.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="UNCERTAIN"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="existingOwner">
                <xsd:annotation>
                    <xsd:documentation>
                        The (single) owner was found. Corresponds to UNLINKED synchronization situation.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXISTING_OWNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="noOwner">
                <xsd:annotation>
                    <xsd:documentation>
                        It was decided that there is no owner. Corresponds to UNMATCHED synchronization situation.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NO_OWNER"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="error">
                <xsd:annotation>
                    <xsd:documentation>
                        The correlation ended in error.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ERROR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="SynchronizationExclusionReasonType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:experimental>true</a:experimental>
                <a:since>4.3</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="synchronized">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object was synchronized - either successfully or not.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SYNCHRONIZED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="protected">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object was excluded from synchronization because it is protected.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PROTECTED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="noSynchronizationPolicy">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object was excluded from synchronization because no synchronization policy was found.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NO_SYNCHRONIZATION_POLICY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="synchronizationDisabled">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object was excluded from synchronization because synchronization is disabled for it.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SYNCHRONIZATION_DISABLED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="synchronizationNotNeeded">
                <xsd:annotation>
                    <xsd:documentation>
                        Synchronization was not expected for the shadow in the particular situation.
                        (E.g. a shadow exists in "remaining shadows" reconciliation activity.)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="SYNCHRONIZATION_NOT_NEEDED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="notApplicableForTask">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object was excluded form synchronization because it is not applicable for the task.
                        (So it is skipped.)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NOT_APPLICABLE_FOR_TASK"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="expired">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object (presumably obtained from shadow cache) is not considered fresh enough, i.e., its
                        time to live in the cache already passed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="EXPIRED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="LegacySynchronizationReactionType">
        <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.

                DEPRECATED. Use new synchronization definitions right in the object type definition.
            </xsd:documentation>
            <xsd:appinfo>
                <a:deprecated>true</a:deprecated>
                <a:deprecatedSince>4.6</a:deprecatedSince>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:string"/>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element name="situation" type="tns:SynchronizationSituationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Defines a particular synchronization situation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="channel" type="xsd:anyURI"/>
            <xsd:element minOccurs="0" name="synchronize" type="xsd:boolean"/>
            <xsd:element minOccurs="0" name="reconcile" type="xsd:boolean"/>
            <xsd:element default="false" minOccurs="0" name="reconcileAll" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        If set to true, applicable synchronization reactions will attempt to reconcile the real attributes
                        from all 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 set to true, the full user reconciliation will be done.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="limitPropagation" type="xsd:boolean"/>
            <xsd:element minOccurs="0" name="objectTemplateRef" type="tns:ObjectReferenceType">
                <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 minOccurs="0" name="executeOptions" type="c:ModelExecuteOptionsType">
                <xsd:annotation>
                    <xsd:documentation>
                        Model execute options that will be used when invoking this reaction.
                        Options explicitly specified here take precedence over any options derived
                        from the context or other parameters (like "recompute"). So please use with care.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.2</a:since>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="condition" type="c:ExpressionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Expression that is evaluated to check whether this reaction is applicable in a particular
                        context. It is assumed to return a boolean value. If it returns 'true' then this reaction
                        will be applied. If it returns 'false' it will be ignored.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.1</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="action" type="tns:SynchronizationActionType"/>
        </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:appinfo>
                <a:schemaMigration>
                    <a:element>tns:userTemplateRef</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:objectTemplateRef</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:ref</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:string"/>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" name="handlerUri" type="xsd:anyURI"/>
            <xsd:element default="before" minOccurs="0" name="order" type="tns:BeforeAfterType"/>
            <!-- TODO: ordering? -->
            <xsd:element minOccurs="0" name="parameters">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax">
                            <xsd:annotation>
                                <xsd:documentation>
                                    Action parameters.
                                    TODO
                                </xsd:documentation>
                            </xsd:annotation>
                        </xsd:any>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
        </xsd:sequence>
    </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 minOccurs="0" name="oldShadowOid" type="xsd:string">
                <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 situation or when the shadow is specified by attributes
                        using "oldShadow".
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="oldShadow" type="tns:ShadowType">
                <xsd:annotation>
                    <xsd:documentation>
                        An alternative to "oldShadowOid" when the shadow is specified by its attributes, not by its OID.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.10.3</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="currentShadow" type="tns:ShadowType">
                <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 minOccurs="0" name="objectDelta" type="t:ObjectDeltaType">
                <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 minOccurs="0" name="channel" type="xsd:string">
                <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="UcfChangeType">
        <xsd:annotation>
            <xsd:documentation>
                Description of the change in the external resource at the UCF level i.e. corresponding to Change object.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="objectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        Object class. Should be provided.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="identifiers" type="tns:ShadowAttributesType">
                <xsd:annotation>
                    <xsd:documentation>
                        Identifiers of the object being changed. Should be provided if not present in object or object delta.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="objectDelta" type="t:ObjectDeltaType">
                <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 object has to be specified.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="object" type="tns:ShadowType">
                <xsd:annotation>
                    <xsd:documentation>
                        Current state of the object. Either it or the delta has to be specified.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="ucfChange" type="tns:UcfChangeType"/>

    <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:AssignmentHolderType">
                <xsd:sequence>
                    <xsd:element minOccurs="0" name="displayName" type="t:PolyStringType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Human-readable name of the connector. It may be quite long, container national characters
                                and there is no uniqueness requirement.
                                This properly will be deprecated soon. Use of display/label is recommended instead of displayName.
                            </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 minOccurs="0" name="connectorVersion" type="xsd:string">
                        <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 minOccurs="0" name="connectorBundle" type="xsd:string">
                        <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 maxOccurs="unbounded" minOccurs="0" name="targetSystemType" type="xsd:anyURI">
                        <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 minOccurs="0" name="namespace" type="xsd:anyURI">
                        <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 minOccurs="0" name="connectorHostRef" type="c:ObjectReferenceType">
                        <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 minOccurs="0" name="schema" type="tns:XmlSchemaType">
                        <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:element minOccurs="0" name="available" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Connector availability status

                                True if local connector is active and loaded in MidPoint. False if connector
                                is not present.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

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

    <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:AssignmentHolderType">
                <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 minOccurs="0" name="port" type="xsd:string">
                        <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 minOccurs="0" name="sharedSecret" type="t:ProtectedStringType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Shared secret used to authenticate client to the host.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="protectConnection" type="xsd:boolean">
                        <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 minOccurs="0" name="timeout" type="xsd:int">
                        <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" substitutionGroup="c:object" type="tns:ConnectorHostType"/>

    <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 represent 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:appinfo>
                <a:schemaMigration>
                    <a:element>tns:result</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:objectChange</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:attemptNumber</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:schemaMigration>
                    <a:element>tns:failedOperationType</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>removed</a:operation>
                </a:schemaMigration>
                <a:diagram>
                    <a:name>user-shadow-resource</a:name>
                    <a:form>expanded</a:form>
                </a:diagram>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="c:ObjectType">
                <xsd:sequence>
                    <xsd:element minOccurs="0" name="resourceRef" type="c:ObjectReferenceType">
                        <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>
                                <a:displayName>ShadowType.resource</a:displayName>
                                <a:diagram>
                                    <a:name>user-shadow-resource</a:name>
                                    <!-- default is to include this item, therefore no "inclusion" specification is needed here -->
                                </a:diagram>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="shadowLifecycleState" type="tns:ShadowLifecycleStateType">
                        <xsd:annotation>
                            <xsd:documentation>
                                The state in the shadow lifecycle. Always related to the current point of time, regardless
                                of the point-in-time setting in get/search operation options. (E.g. an account retrieved with
                                the point-in-time = future that has a pending DELETE operation will be returned with dead=true,
                                but shadowLifecycleState will be reaping.)

                                Currently TRANSIENT, i.e. it is not stored in the repository.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.shadowLifecycleState</a:displayName>
                                <a:experimental>true</a:experimental>
                                <a:operational>true</a:operational>
                                <a:since>4.4</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="purpose" type="tns:ShadowPurposeType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Purpose for existence (or non-existence) of a resource object referenced by the shadow.
                                E.g. it specifies whether the resource object is fully operational, whether it is not completely prepared yet,
                                it may indicate why we are keeping the resource object instead of deleting it, and so on.
                                It can be thought of as a "business lifecycle", specifying the reason for this object or shadow.

                                This information is maintained by midPoint, it is not directly projected to the resource.
                                This information supplements the resource object data, it keeps additional information that the resource does not have.
                                It is different from shadowLifecycleState, as shadowLifecycleState specifies the technical state in which resource object is
                                (e.g. not created yet, not deleted yet).
                                On the other hand, purpose represents the business information, the reason or intention that we have with the object.
                                For example, "incomplete" purpose describes an account that is technically in a perfect shape, technically fully operation,
                                yet user is not able to use that account yet.

                                This is also different from the regular lifecycleState.
                                The lifecycleState of a shadow is meant to be reflected directly to resource object.
                                E.g. lifecycleState of a shadow should be taken from lifecycle state of account, from one of its attributes
                                (similarly to administrativeStatus).
                                On the other hand, "purpose" is an information kept only by midPoint, not directly synchronized to the resource.
                                The "purpose" will work for all resources, regardless of whether they support lifecycle state (and its fidelity),
                                activation or any other details.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.purpose</a:displayName>
                                <a:since>4.8</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="dead" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Description of operation during the processing of account failed.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.dead</a:displayName>
                                <a:displayHint>emphasized</a:displayHint>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="deathTimestamp" type="xsd:dateTime">
                        <xsd:annotation>
                            <xsd:documentation>
                                When we learned about the fact that the shadow is dead?

                                The reason behind this property is to be able to distinguish "freshly dead" shadows so that
                                full synchronization may be invoked if this timestamp is after fullSynchronizationTimestamp.

                                (In the future, though, we should make synchronization reactions more "declarative" so that
                                all dead shadows could be synchronized. But that is a longer-term plan.)
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.deathTimestamp</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="pendingOperation" type="tns:PendingOperationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Description of an operation 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 minOccurs="0" name="synchronizationSituation" type="tns:SynchronizationSituationType">
                        <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:displayHint>emphasized</a:displayHint>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="synchronizationTimestamp" type="xsd:dateTime">
                        <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:appinfo>
                                <a:displayName>ShadowType.synchronizationTimestamp</a:displayName>
                                <!-- Actually, almost all data in shadow can be marked as operational.
                                     But this one is somehow "more operational" than the others.
                                     Among other reasons, we do not want to display it as a change in the simulation results.
                                     See MID-9737. -->
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="fullSynchronizationTimestamp" type="xsd:dateTime">
                        <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:appinfo>
                                <!-- Actually, almost all data in shadow can be marked as operational.
                                     But this one is somehow "more operational" than the others.
                                     Among other reasons, we do not want to display it as a change in the simulation results.
                                     See MID-9737. -->
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="synchronizationSituationDescription" type="tns:SynchronizationSituationDescriptionType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Complex description of synchronization situations. This is multi-valued property and it should
                                store only a single value for each channel (the most recent one). All the older values should be
                                removed on each update.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <!-- Actually, almost all data in shadow can be marked as operational.
                                     But this one is somehow "more operational" than the others.
                                     Among other reasons, we do not want to display it as a change in the simulation results.
                                     See MID-9737. -->
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="correlation" type="tns:ShadowCorrelationStateType">
                        <xsd:annotation>
                            <xsd:documentation>
                                State of the shadow correlation process. It contains statistical data (e.g. start/end timestamps),
                                result of the (last) correlation - determined situation, candidate owner(s), performer OIDs
                                and their comments - as well as correlator-specific data, like ID Match request and reference IDs.

                                Relevance of the data: The data are deleted when the new correlation process starts after the
                                previous one ended. This fact is determined by checking that the correlationEndTimestamp (set
                                by the previous correlation process) has a non-null value. However, until that time,
                                we must keep the data intact. For example, ID Match correlation typically uses
                                correlatorState/referenceId property as a kind of unique user identifier that is
                                to be used in an inbound mapping.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.5</a:since>
                                <a:container>true</a:container>
                                <a:experimental>true</a:experimental>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" 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).

                                Formally, minOccurs is 0 here but unless a reasonable default is provided, the value
                                must be present.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.objectClass</a:displayName>
                                <a:displayHint>emphasized</a:displayHint>
                                <a:diagram>
                                    <a:name>user-shadow-resource</a:name>
                                </a:diagram>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="primaryIdentifierValue" type="xsd:string">
                        <xsd:annotation>
                            <xsd:documentation>
                                Value of the primary (unique) identifier; converted to a string if it's of a different type.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.primaryIdentifierValue</a:displayName>
                                <a:since>4.0</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="auxiliaryObjectClass" type="xsd:QName">
                        <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 minOccurs="0" name="kind" type="tns:ShadowKindType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Kind of a shadow. This means the type of shadow use.
                                E.g. an account, entitlement, etc.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.kind</a:displayName>
                                <a:diagram>
                                    <a:name>user-shadow-resource</a:name>
                                </a:diagram>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="intent" type="xsd:string">
                        <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:displayHint>emphasized</a:displayHint>
                                <a:diagram>
                                    <a:name>user-shadow-resource</a:name>
                                </a:diagram>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="tag" type="xsd:string">
                        <xsd:annotation>
                            <xsd:documentation>
                                Tag value used to discriminate multiple accounts that have the same resource+kind+intent combination.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.tag</a:displayName>
                                <a:since>4.0</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="protectedObject" type="xsd:boolean">
                        <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 overridden.

                                This is "virtual" property. It is not stored in the repository.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="ignored" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Ignored shadows will not be processed during synchronization.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="assigned" type="xsd:boolean">
                        <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 default="true" minOccurs="0" name="exists" type="xsd:boolean">
                        <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 know nothing about yet.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="iteration" type="xsd:int">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <!-- Actually, almost all data in shadow can be marked as operational.
                                     But this one is somehow "more operational" than the others.
                                     Among other reasons, we do not want to display it as a change in the simulation results.
                                     See MID-9986. Note that the iteration in AssignmentHolderType is also operational. -->
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="iterationToken" type="xsd:string">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <!-- Actually, almost all data in shadow can be marked as operational.
                                     But this one is somehow "more operational" than the others.
                                     Among other reasons, we do not want to display it as a change in the simulation results.
                                     See MID-9986. Note that the iterationToken in AssignmentHolderType is also operational. -->
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="attributes" type="tns:ShadowAttributesType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Attributes of this shadow. The exact form depends on the context:

                                1. For resource-level shadows, both simple and reference attributes are here.

                                2. For model-level shadows, the simple attributes are here, and MAYBE the reference ones as well.
                                (After they were converted into associations.)

                                3. For repository-level shadows, only the simple attributes are here. The reference ones
                                are moved (at least for now) into "referenceAttributes" container.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.attributes</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="referenceAttributes" type="tns:ShadowReferenceAttributesType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Reference attributes. Present only in the repository-level shadows.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.referenceAttributes</a:displayName>
                                <a:since>4.9</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="associations" type="tns:ShadowAssociationsType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Associations of this shadow. Present only in model-level shadows.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.association</a:displayName>
                                <a:since>4.9</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="association" type="tns:ShadowAssociationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Legacy associations of this shadow. Not used anymore.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.association</a:displayName>
                                <a:deprecated>true</a:deprecated>
                                <a:deprecatedSince>4.9</a:deprecatedSince>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="activation" type="tns:ActivationType">
                        <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 minOccurs="0" name="credentials" type="tns:CredentialsType">
                        <!-- See also https://docs.evolveum.com/midpoint/devel/design/password-caching-4.9.1/ -->
                        <xsd:annotation>
                            <xsd:documentation>
                                The set of account credentials (such as passwords).
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" ref="tns:cachingMetadata">
                        <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.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="contentDescription" type="tns:ShadowContentDescriptionType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Describes the content of the shadow, mainly regarding the source (repository / resource),
                                plus other limitations. Transient property, not to be stored in the repository.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.9</a:since>
                                <a:operational>true</a:operational>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="behavior" type="tns:ShadowBehaviorType">
                        <xsd:annotation>
                            <xsd:appinfo>
                                <a:displayName>ShadowType.behavior</a:displayName>
                                <a:since>4.9</a:since>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="shadow" substitutionGroup="c:object" type="tns:ShadowType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:schemaMigration>
                    <a:element>tns:account</a:element>
                    <a:version>4.0</a:version>
                    <a:operation>renamedParent</a:operation>
                    <a:replacement>tns:shadow</a:replacement>
                </a:schemaMigration>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:simpleType name="ShadowKindType">
        <xsd:annotation>
            <xsd:documentation>
                Defines the kind of 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:enumeration value="association">
                <xsd:annotation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASSOCIATION"/>
                    </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:simpleType name="ShadowLifecycleStateType">
        <xsd:annotation>
            <xsd:documentation>
                The lifecycle state of a shadow and the corresponding resource object.
                See https://docs.evolveum.com/midpoint/reference/resources/shadow/dead/.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="proposed">
                <xsd:annotation>
                    <xsd:documentation>
                        "Add" operation is requested. But it was not started yet. We are processing the request.
                        This is used mostly to detect uniqueness conflicts (to "reserve" identifiers).
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="PROPOSED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="conceived">
                <xsd:annotation>
                    <xsd:documentation>
                        Signal to create the resource object was sent. It is being executed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CONCEIVED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="gestating">
                <xsd:annotation>
                    <xsd:documentation>
                        This is a "quantum" state: shadow is alive, but not yet alive at the same time. It probably already
                        exists on the resource (hence exists=true). But it does not exist in the snapshot yet. Gestating shadows
                        will not appear in resource searches. This should not be a problem for reconciliation, because they
                        should be linked and they will be processed by reconciliation anyway.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="GESTATING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="live">
                <xsd:annotation>
                    <xsd:documentation>
                        Normal state. Shadow exists. Everything works as expected. No quantum effects. No controversies.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="LIVE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="reaping">
                <xsd:annotation>
                    <xsd:documentation>
                        Signal to delete the resource object was sent. It is being executed.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REAPING"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="corpse">
                <xsd:annotation>
                    <xsd:documentation>
                        A.k.a. Schrodinger's shadow. This is a "quantum" state: shadow is dead, but is also alive
                        at the same time. It is probably already deleted in the resource (hence exists=false). But it
                        still exists in the snapshot. Corpse shadows will appear in resource searches - even though
                        is it marked as dead=true.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="CORPSE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="tombstone">
                <xsd:annotation>
                    <xsd:documentation>
                        Shadow is dead. Nothing remains. No resource object, no object in the snapshot. Just this stone
                        on a grave remains. And it will also expire eventually. Tombstone shadows will not appear in resource
                        searches - because they do not exist on the resource. But they will work with get operations. And
                        they can be searched with noFetch.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="TOMBSTONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="ShadowPurposeType">
        <xsd:annotation>
            <xsd:documentation>
                Purpose for existence (or non-existence) of a resource object referenced by the shadow.
                E.g. it specifies whether the resource object is fully operational, whether it is not completely prepared yet,
                it may indicate why we are keeping the resource object instead of deleting it, and so on.
                It can be thought of as a "business lifecycle", specifying the reason for this object or shadow.

                Purposes considered to the future:

                * reserved: Resource object exists for the sole purpose of reserving identifiers or other resources.
                E.g. account that exists only to make sure the username is not taken by any other account, or that a username is not re-used.
                It can be used both for existing and non-existing resource objects.
                I.e. it may be only a shadow, reserving identifier at midPoint level,
                or it may be an account (probably inactive), reserving identifier at resource level.
                May also be used for (non-existent or disabled) accounts that are yet to be "claimed" by the user.
                (Question: do we need separate "tombstone" state for accounts that were deleted?)

                * suspended: Resource object is inactivated (disabled) for a longer period of time.
                E.g. used for maternal leave or sabbatical.
                This purpose may be used to avoid deleting such accounts, e.g. in delayed delete scenarios.

                * lingering: Resource object is still there, even though it should be gone already.
                E.g. account exists (although it is disabled), even though it should be deleted.
                This can be used to mark shadows that are kept due to disable-instead-of-delete scenarios.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="regular">
                <xsd:annotation>
                    <xsd:documentation>
                        Regular, completely ordinary resource object.
                        It is in full working condition, everything works normally.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REGULAR"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="incomplete">
                <xsd:annotation>
                    <xsd:documentation>
                        Resource object is not complete, it is not yet fully usable.
                        Some kind of action is necessary to complete the process.

                        May be used for shadows that are technically in perfect working conditions, however user is not able to fully use them.
                        For example, an account that was created with random password, the password was not delivered to the user.
                        The user is expected to "activate" the account by resetting the password.
                        However, technically, the account is in perfect working condition, enabled, password is set and so on.
                        This "purpose" value is stored by midPoint to remember that additional action is needed to make this account fully operation on user level.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="INCOMPLETE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="ShadowContentDescriptionType">
        <xsd:annotation>
            <xsd:documentation>
                Describes what exactly is in the shadow, mainly regarding the origin of the data.

                Currently it is a simple enumeration. Later on we can add more detailed information here,
                like exactly what attributes are to be expected in the shadow.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="fromResourceComplete">
                <xsd:annotation>
                    <xsd:documentation>
                        The shadow comes from the resource.

                        It should be relatively complete, meaning that at least the attributes provided by default
                        (including associations) are present.

                        This means that e.g. it is safe to cache it, run mappings against it, and so on.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FROM_RESOURCE_COMPLETE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="fromResourceIncomplete">
                <xsd:annotation>
                    <xsd:documentation>
                        The shadow comes from the resource but we cannot assure it's complete.

                        We should not cache it. It is questionable whether we should run mappings against it.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FROM_RESOURCE_INCOMPLETE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="fromRepository">
                <xsd:annotation>
                    <xsd:documentation>
                        The shadow comes from the cache, i.e., from the repository.

                        Its expiration should be determined by examining cachingMetadata item.

                        Note that the shadow may or may not really exist on the resource.
                        The shadow lifecycle state must be examined to learn this.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="FROM_REPOSITORY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="new">
                <xsd:annotation>
                    <xsd:documentation>
                        This is a shadow that is going to be created on the resource.
                        Resource-provided attributes (like icfs:uid, or LDAP uid) should or may be missing.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NEW"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="identificationOnly">
                <xsd:annotation>
                    <xsd:documentation>
                        This shadow serves just as a holder of identifiers pointing to a real shadow.
                        Used for shadow references.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IDENTIFICATION_ONLY"/>
                    </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 maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax">
            </xsd:any>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ShadowReferenceAttributesType">
        <xsd:annotation>
            <xsd:documentation>
                As ShadowAttributesType, but constrained to contain only reference attributes.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:defaultItemTypeName>tns:ObjectReferenceType</a:defaultItemTypeName>
                <a:defaultReferenceTargetTypeName>tns:ShadowType</a:defaultReferenceTargetTypeName>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:ShadowAttributesType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="attributes" type="tns:ShadowAttributesType">
        <!--  Necessary to find item definition for attributes -->
        <xsd:annotation>
            <xsd:appinfo>
                <a:displayName>ShadowType.attributes</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:complexType name="ShadowAssociationsType">
        <xsd:annotation>
            <xsd:documentation>
                Association values from the resource.
                Their caching works in a way similar to the caching of attributes.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
                <a:defaultItemTypeName>tns:ShadowAssociationValueType</a:defaultItemTypeName>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:element name="associations" type="tns:ShadowAssociationsType">
        <!--  Necessary to find item definition for associations -->
        <xsd:annotation>
            <xsd:appinfo>
                <a:displayName>ShadowType.associations</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:complexType name="ShadowAssociationType">
        <xsd:annotation>
            <xsd:documentation>
                The value of an association. Not used since 4.9.
                ShadowAssociationValueType is used instead.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:QName"/>
            <xsd:element minOccurs="0" name="shadowRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:ShadowType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="identifiers" type="tns:ShadowIdentifiersType"/>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowAssociation" type="tns:ShadowAssociationType"/>

    <xsd:complexType name="ShadowAssociationValueType">
        <xsd:annotation>
            <xsd:documentation>
                The value of an association. Present only in model-level shadows.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="attributes" type="tns:ShadowAttributesType">
                <xsd:annotation>
                    <xsd:documentation>
                        Container for attributes belonging to the association object itself. It may be empty
                        for simple associations.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="activation" type="tns:ActivationType">
                <xsd:annotation>
                    <xsd:documentation>
                        Activation state of this association value. It may be empty for simple associations.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="objects" type="tns:ShadowReferenceAttributesType">
                <xsd:annotation>
                    <xsd:documentation>
                        Container for reference attributes to the shadows that represent the association targets
                        (e.g., an LDAP group). There should be at most one value for each of the attributes in this
                        container.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowAssociationValue" type="tns:ShadowAssociationValueType"/>

    <xsd:complexType name="ShadowIdentifiersType">
        <xsd:annotation>
            <xsd:documentation>
                TODO
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax">
            </xsd:any>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </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 minOccurs="0" name="type" type="tns:PendingOperationTypeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Type of pending operation. It tells whether this is asynchronous
                        resource operation, manual operation, retried operation and so on.
                        It is used mostly for diagnostic purposes. But it also has some
                        meaning in the logic for some special cases.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="delta" type="t:ObjectDeltaType">
                <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 minOccurs="0" name="requestTimestamp" type="xsd:dateTime">
                <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 minOccurs="0" name="operationStartTimestamp" type="xsd:dateTime">
                <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 minOccurs="0" name="lastAttemptTimestamp" type="xsd:dateTime">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                            The timestamp of last operation attempt (star of operation).
                            During normal (positive) flow it is the same as operationStartTimestamp.
                            But this timestamp will change if the operation fails and
                            it is re-tried.
                        </p>
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="completionTimestamp" type="xsd:dateTime">
                <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 minOccurs="0" name="executionStatus" type="tns:PendingOperationExecutionStatusType">
                <xsd:annotation>
                    <xsd:documentation>
                        <p>
                            Execution status. This property indicates in which execution stage
                            the operation is, e.g. whether it is requested, 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 minOccurs="0" name="resultStatus" type="tns:OperationResultStatusType">
                <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. If result status is present in "executing" state
                            then it means that execution was already attempted but it was not completed
                            yet (e.g. there was an error and we will be retrying the operation).
                        </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 minOccurs="0" name="asynchronousOperationReference" type="xsd:string">
                <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>
            <xsd:element default="1" minOccurs="0" name="attemptNumber" type="xsd:int">
                <xsd:annotation>
                    <xsd:documentation>
                        Number of a current attempt at operation execution. Starts at 1.
                        Null (in repository) means the operation is not retryable.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>3.9</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"/>
    </xsd:complexType>

    <xsd:simpleType name="PendingOperationTypeType">
        <xsd:annotation>
            <xsd:documentation>
                Type of pending operation. It tells whether this is asynchronous
                resource operation, manual operation, retried operation and so on.
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
                <a:since>3.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="manual">
                <xsd:annotation>
                    <xsd:documentation>
                        Operation using manual action (e.g. "manual" resources)
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MANUAL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="retry">
                <xsd:annotation>
                    <xsd:documentation>
                        Regular operation that has failed and it will be retried.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="RETRY"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="asynchronous">
                <xsd:annotation>
                    <xsd:documentation>
                        Operation executed asynchronously.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ASYNCHRONOUS"/>
                        <a:since>4.3</a:since>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <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 requested, 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 execution 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 information 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 minOccurs="0" name="channel" type="xsd:anyURI"/>
            <xsd:element minOccurs="0" name="full" type="xsd:boolean"/>
        </xsd:sequence>
    </xsd:complexType>

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

    <xsd:complexType name="ConnectorFrameworkConfigurationType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:container/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" ref="tns:extension">
                <xsd:annotation>
                    <xsd:documentation>
                        This element may contain any framework-specific global
                        configuration.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="connectorPath" type="xsd:string">
                <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:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ResourceObjectTypeDelineationType">
        <xsd:annotation>
            <xsd:documentation>
                Delineates the boundary of a resource object type (i.e. objects that belong to that type).
                Contains also supporting ("imperative") instructions regarding classification of objects
                into types.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.6</a:since>
                <!-- Inherits schema context from ResourceObjectTypeDefinitionType-->
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="objectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        Object class (like ri:inetOrgPerson) for this resource object type.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayHint>emphasized</a:displayHint>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="auxiliaryObjectClass" type="xsd:QName">
                <xsd:annotation>
                    <xsd:documentation>
                        The reference to additional object classes 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.

                        Definitions of attributes from these classes are "imported" to the object type.
                        However, currently this auxiliary object classes are not used for classification; i.e. the classification
                        decision is not based on their presence in the specific resource object.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayHint>emphasized</a:displayHint>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO The OCs mentioned in "auxiliaryObjectClass" are applied automatically to objects of this type.
                  However, sometimes we need to be able to understand some attributes from aux OCs without enforcing these OCs
                  on all objects of given type. So we'd need something like "optionalAuxiliaryObjectClass" property.
                  (Discussed on December 16th, 2022.) -->
            <xsd:element minOccurs="0" name="baseContext" type="tns:ResourceObjectReferenceType">
                <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.

                        This information is used for object classification as well. See also "baseContextClassificationUse"
                        property.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="searchHierarchyScope" type="tns:SearchHierarchyScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Definition of search hierarchy scope. It specifies how "deep" the search should go
                        into the object hierarchy. It is only applicable to resources that support hierarchical
                        organization of objects (e.g. LDAP resources).

                        This information is used for object classification (along with baseContext) as well.
                        See also "baseContextClassificationUse" property.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="filter" type="q:SearchFilterType">
                <xsd:annotation>
                    <xsd:documentation>
                        A filter that defines the object set. Appended to any filter(s) defined in the supertype(s).
                        Used also for classification.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayHint>emphasized</a:displayHint>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="classificationCondition" type="c:ExpressionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Expression that is evaluated to check whether a resource object is of given type.
                        It is assumed to return a boolean value. (If no condition is present then it is assumed
                        to be always true, i.e. the classification is done using the other means.)

                        It is preferable to use declarative means for classification, i.e. baseContext and filter(s).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="classificationOrder" type="xsd:int">
                <xsd:annotation>
                    <xsd:documentation>
                        In what order should this delineation specification be used for classification? No value means
                        it should be used at the end.

                        So, the overall classification algorithm is the following:

                        1. First, candidate object types with classification order specified are tried - in their respective
                        order. The first matching one is used.

                        2. Then, candidate object types without order are tried. Matching ones are collected.

                        - If there is a default object type ("default for object class") among matching ones, it is used.
                        - If there is exactly one matching type, it is used.
                        - If there is no matching type, the classification is unsuccessful.
                        - If there are multiple (non-default) matching types, a special heuristic is executed: the first
                        one with the legacy synchronization section present is returned. Otherwise, arbitrary one is used.
                        (This may be changed in the future.)
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="ifApplicable" minOccurs="0" name="baseContextClassificationUse" type="tns:BaseContextClassificationUseType">
                <xsd:annotation>
                    <xsd:documentation>
                        How should be the base context used for the classification?
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:simpleType name="BaseContextClassificationUseType">
        <xsd:annotation>
            <xsd:documentation>
                How should be the base context in the delineation used for the classification?
            </xsd:documentation>
            <xsd:appinfo>
                <jaxb:typesafeEnumClass/>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="required">
                <xsd:annotation>
                    <xsd:documentation>
                        The base context must be used (if it's present in the delineation). If it cannot be applied,
                        the delineation is considered as non-matching.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="REQUIRED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ifApplicable">
                <xsd:annotation>
                    <xsd:documentation>
                        If the base context is not applicable, it is used. Otherwise, it is ignored.
                        This is the default setting.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IF_APPLICABLE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="ignored">
                <xsd:annotation>
                    <xsd:documentation>
                        The base context is not used for classification.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="IGNORED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="SynchronizationReactionsType">
        <xsd:annotation>
            <xsd:documentation>
                Defines reaction(s) to synchronization-related situations, plus other synchronization settings.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="true" minOccurs="0" name="opportunistic" type="xsd:boolean">
                <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 minOccurs="0" name="defaultSettings" type="tns:SynchronizationReactionsDefaultSettingsType">
                <xsd:annotation>
                    <xsd:documentation>
                        Settings that are applied to all clockwork-based actions defined here.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="reaction" type="tns:SynchronizationReactionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reaction(s) to individual synchronization situation(s).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="SynchronizationReactionsDefaultSettingsType">
        <xsd:annotation>
            <xsd:documentation>
                Default settings for synchronization reactions.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="reconcile" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Default value for AbstractClockworkBasedSynchronizationActionType#reconcile.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="false" minOccurs="0" name="reconcileAll" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Default value for AbstractClockworkBasedSynchronizationActionType#reconcileAll.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="limitPropagation" type="xsd:boolean">
                <xsd:annotation>
                    <xsd:documentation>
                        Default value for AbstractClockworkBasedSynchronizationActionType#limitPropagation.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="objectTemplateRef" type="tns:ObjectReferenceType">
                <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 minOccurs="0" name="executeOptions" type="c:ModelExecuteOptionsType">
                <xsd:annotation>
                    <xsd:documentation>
                        Model execute options that will be used when invoking this reaction.
                        Options explicitly specified here take precedence over any options derived
                        from the context or other parameters (like "recompute"). So please use with care.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.2</a:since>
                        <a:experimental>true</a:experimental>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType abstract="true" name="AbstractSynchronizationReactionType">
        <xsd:annotation>
            <xsd:documentation>
                Reaction to synchronization situation or situations: a common supertype for object and item-level structures.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
                <a:naturalKey>tns:name</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:string">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationReactionType.name</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" ref="tns:lifecycleState"/>
            <xsd:element minOccurs="0" name="order" type="xsd:int">
                <xsd:annotation>
                    <xsd:documentation>
                        Order in which this reaction is to be evaluated. (Related to other reactions.) Smaller numbers
                        go first. Entries with no order go last.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <!-- TODO consider moving channel and condition here (from SynchronizationReactionType) -->
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SynchronizationReactionType">
        <xsd:annotation>
            <xsd:documentation>
                Reaction to synchronization situation or situations.

                There is a list of situations to which this entry pertains.
                The list is further optionally qualified by channel(s) and a condition.

                Only if a situation (any of), a channel (any of), and the condition all match, then the action(s) are applied.

                The list of reactions is evaluated in the (optional) order given.
                Entries without explicit order are evaluated last.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationReactionType">
                <xsd:sequence>
                    <xsd:element maxOccurs="unbounded" name="situation" type="tns:SynchronizationSituationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Defines a particular synchronization situation or situations.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>SynchronizationReactionType.situation</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element maxOccurs="unbounded" minOccurs="0" name="channel" type="xsd:anyURI">
                        <xsd:annotation>
                            <xsd:documentation>
                                If present, limits the applicability of this reaction to given synchronization channel or channels.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="condition" type="tns:ExpressionType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Expression that is evaluated to check whether this reaction is applicable in a particular
                                context. It is assumed to return a boolean value. If it returns 'true' then this reaction
                                will be applied. If it returns 'false' it will be ignored.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="actions" type="tns:SynchronizationActionsType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Action or actions to be executed in the given situation.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>SynchronizationReactionType.actions</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="SynchronizationActionsType">
        <xsd:annotation>
            <xsd:documentation>
                Action(s) that have to be executed in specified synchronization situation.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="synchronize" type="tns:SynchronizeSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.synchronize</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="link" type="tns:LinkSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.link</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="unlink" type="tns:UnlinkSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.unlink</a:displayName>
                        <a:deprecated>true</a:deprecated>
                        <a:deprecatedSince>4.9</a:deprecatedSince>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="addFocus" type="tns:AddFocusSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.addFocus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="deleteFocus" type="tns:DeleteFocusSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.deleteFocus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inactivateFocus" type="tns:InactivateFocusSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.inactivateFocus</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="deleteResourceObject" type="tns:DeleteResourceObjectSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.deleteResourceObject</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inactivateResourceObject" type="tns:InactivateResourceObjectSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.inactivateResourceObject</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="createCorrelationCase" type="tns:CreateCorrelationCaseSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>SynchronizationActionsType.createCorrelationCase</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="AbstractSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Abstract synchronization action - either clockwork-based or arbitrary one.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
                <a:naturalKey>tns:name</a:naturalKey>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="name" type="xsd:string"/>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element minOccurs="0" name="order" type="xsd:int">
                <xsd:annotation>
                    <xsd:documentation>
                        Order in which this action is to be executed, if there are more of them. (Related to other actions.)
                        Smaller numbers go first. Entries with no order go last.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="AbstractClockworkBasedSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Abstract clockwork-based synchronization action.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType">
                <xsd:sequence>
                    <xsd:element default="true" minOccurs="0" name="synchronize" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Designed to be like this:

                                If set to false, the clockwork will not run. So e.g. linking and unlinking will be done
                                in "fast" way.

                                But currently not implemented. See MID-10338.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="reconcile" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                If true, the focus and the projection being synchronized will be reconciled while executing
                                changes. (The default value is "true" for situations when there is no known object delta
                                - i.e. change information - coming from the resource.)

                                See also ModelExecuteOptionsType#reconcile.
                                See also SynchronizationReactionsDefaultSettingsType#reconcile.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="false" minOccurs="0" name="reconcileAll" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                If set to true, applicable synchronization reactions will attempt to reconcile the real attributes
                                from all resources with the state of the midPoint repository. This may require additional read and
                                recompute, therefore may be slightly less efficient.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="limitPropagation" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Option to limit change computation and execution only for the source resource.

                                See ModelExecuteOptionsType#limitPropagation.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="objectTemplateRef" type="tns:ObjectReferenceType">
                        <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 minOccurs="0" name="executeOptions" type="c:ModelExecuteOptionsType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Model execute options that will be used when invoking this reaction.
                                Options explicitly specified here take precedence over any options derived
                                from the context or other parameters (like "recompute"). So please use with care.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:since>4.2</a:since>
                                <a:experimental>true</a:experimental>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="SynchronizeSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Plain "synchronize" (clockwork-based) action.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="LinkSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Links resource object to its owning focus. TODO what if there's none?
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="UnlinkSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Unlinks resource object from its owning focus.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="AddFocusSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Creates an owning focus for the resource object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="DeleteFocusSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Deletes the owning focus for the resource object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="InactivateFocusSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Inactivates the owning focus for the resource object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="DeleteResourceObjectSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Deletes the resource object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="InactivateResourceObjectSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Inactivates the resource object.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractClockworkBasedSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="CreateCorrelationCaseSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Creates (or updates) a correlation case for resource object in "disputed"
                synchronization state, i.e. one whose owner cannot be reliably determined.

                TODO Is it OK that correlation case is updated only when this action is configured?
                Shouldn't that be automatic (if the situation is DISPUTED, and a case already exists)?
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ItemSynchronizationReactionsType">
        <xsd:annotation>
            <xsd:documentation>
                Defines reaction(s) to synchronization-related situations, plus other synchronization settings,
                at the level of focus item.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="reaction" type="tns:ItemSynchronizationReactionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Reaction(s) to individual synchronization situation(s).
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:complexType name="ItemSynchronizationReactionType">
        <xsd:annotation>
            <xsd:documentation>
                Reaction to synchronization situation or situations at the level of focus item.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationReactionType">
                <xsd:sequence>
                    <xsd:element maxOccurs="unbounded" name="situation" type="tns:ItemSynchronizationSituationType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Defines a particular synchronization situation or situations.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>SynchronizationReactionType.situation</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="actions" type="tns:ItemSynchronizationActionsType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Action or actions to be executed in the given situation.
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:displayName>SynchronizationReactionType.actions</a:displayName>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ItemSynchronizationActionsType">
        <xsd:annotation>
            <xsd:documentation>
                Action(s) that have to be executed in specified synchronization situation.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="synchronize" type="tns:SynchronizeItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.synchronize</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="addFocusValue" type="tns:AddFocusValueItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.addFocusValue</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="deleteFocusValue" type="tns:DeleteFocusValueItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.deleteFocusValue</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inactivateFocusValue" type="tns:InactivateFocusValueItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.inactivateFocusValue</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="deleteResourceObjectValue" type="tns:DeleteResourceObjectValueItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.deleteResourceObjectValue</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="inactivateResourceObjectValue" type="tns:InactivateResourceObjectValueItemSynchronizationActionType">
                <xsd:annotation>
                    <xsd:appinfo>
                        <a:displayName>ItemSynchronizationActionsType.inactivateResourceObjectValue</a:displayName>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="SynchronizeItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Plain "synchronize" action.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="AddFocusValueItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Creates an owning focus value for the resource object value.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="DeleteFocusValueItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Deletes the owning focus value for the resource object value.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="InactivateFocusValueItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Inactivates the owning focus value.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="DeleteResourceObjectValueItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Deletes the resource object value.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="InactivateResourceObjectValueItemSynchronizationActionType">
        <xsd:annotation>
            <xsd:documentation>
                Inactivates the resource object value.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:AbstractSynchronizationActionType"/>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="SuperResourceDeclarationType">
        <xsd:annotation>
            <xsd:documentation>
                Declares a "super-resource".
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
                <a:since>4.6</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element name="resourceRef" type="tns:ObjectReferenceType">
                <xsd:annotation>
                    <xsd:documentation>
                        The reference to the "super-resource".
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:objectReferenceTargetType>tns:ResourceType</a:objectReferenceTargetType>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
            <!-- inheritance options may be included later -->
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="ShadowCachingConfigurationType">
        <xsd:annotation>
            <xsd:documentation>
                Global settings for the "shadow caching" feature.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="defaultPolicy" type="tns:ShadowCachingPolicyType">
                <xsd:annotation>
                    <xsd:documentation>
                        Default policy for the shadow caching.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>
    <xsd:element name="shadowCachingConfiguration" type="tns:ShadowCachingConfigurationType"/>

    <xsd:complexType name="ShadowCachingPolicyType">
        <xsd:annotation>
            <xsd:documentation>
                Definition of a shadow caching policy.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="tns:CachingPolicyType">
                <xsd:sequence>
                    <xsd:element minOccurs="0" name="scope" type="tns:ShadowCachingScopeType">
                        <xsd:annotation>
                            <xsd:documentation>
                                Scope of the caching. The default is to cache mapped items, activation, and "protected" flag.
                                Any exceptions can be marked by "cached" property of individual attributes and associations.
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="timeToLive" type="xsd:duration">
                        <xsd:annotation>
                            <xsd:documentation>
                                For how long do we consider cached data as usable?
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element minOccurs="0" name="defaultCacheUse" type="tns:CachedShadowsUseType">
                        <xsd:annotation>
                            <xsd:documentation>
                                How should be the cache used by default, e.g., if no caching behavior
                                is specified in model execution options?
                            </xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                    <xsd:element default="true" minOccurs="0" name="retrievalTimestampMaintenance" type="xsd:boolean">
                        <xsd:annotation>
                            <xsd:documentation>
                                Should we maintain retrieval timestamp in shadows when the shadow is retrieved from the resource?
                                Can be turned off to improve the performance in cases when we need the cached data but don't need
                                the timestamp (e.g., when using data only for reporting purposes).
                            </xsd:documentation>
                            <xsd:appinfo>
                                <a:experimental>true</a:experimental>
                            </xsd:appinfo>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="ShadowCachingScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Scope of the shadow caching.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="defined" minOccurs="0" name="attributes" type="tns:ShadowSimpleAttributesCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for simple attributes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="all" minOccurs="0" name="associations" type="tns:ShadowItemsCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for associations i.e. reference attributes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="all" minOccurs="0" name="activation" type="tns:ShadowItemsCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for the activation information.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element default="all" minOccurs="0" name="auxiliaryObjectClasses" type="tns:ShadowItemsCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for the auxiliary object classes.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="credentials" type="tns:ShadowCredentialsCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for credentials, i.e., the password for now.
                        Note that we currently store only the hashed value (or "incomplete" flag) in the shadow.

                        See https://docs.evolveum.com/midpoint/devel/design/password-caching-4.9.1/.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:since>4.9.1</a:since>
                        <a:since>4.10</a:since>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:simpleType name="ShadowSimpleAttributesCachingScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Scope of the shadow caching for simple attributes.
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        No items of given kind will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="defined">
                <xsd:annotation>
                    <xsd:documentation>
                        Only attributes defined (refined) in schemaHandling section will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="DEFINED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="mapped">
                <xsd:annotation>
                    <xsd:documentation>
                        Only mapped items of given kind, i.e., those that have any mapping defined right in the object type,
                        either inbound or outbound, will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="MAPPED"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="all">
                <xsd:annotation>
                    <xsd:documentation>
                        All items of given kind will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="ShadowCredentialsCachingScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Scope of the shadow credentials caching.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9.1</a:since>
                <a:since>4.10</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element default="all" minOccurs="0" name="password" type="tns:ShadowItemsCachingScopeType">
                <xsd:annotation>
                    <xsd:documentation>
                        Scope of the caching for the shadow password.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

    <xsd:simpleType name="ShadowItemsCachingScopeType">
        <xsd:annotation>
            <xsd:documentation>
                Scope of the shadow caching for a category of items other than simple attributes (e.g., associations).
            </xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="none">
                <xsd:annotation>
                    <xsd:documentation>
                        No items of given kind will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="NONE"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
            <xsd:enumeration value="all">
                <xsd:annotation>
                    <xsd:documentation>
                        All items of given kind will be cached.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <jaxb:typesafeEnumMember name="ALL"/>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:enumeration>
        </xsd:restriction>
    </xsd:simpleType>

    <xsd:complexType name="AssociationConstructionExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Creates association values by constructing it via mappings for individual attributes and object references.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:AttributeOutboundMappingsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of given association attribute.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectRef" type="tns:AttributeOutboundMappingsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of given object-side of this association.
                        The object can be specified exactly (via "ref" property), or kept implicit, if there's only one object.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="activation" type="tns:ResourceActivationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of the activation of this association.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="associationConstruction" substitutionGroup="tns:expressionEvaluator" type="tns:AssociationConstructionExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:displayName>ExpressionType.associationConstruction</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:complexType name="AssociationSynchronizationExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:documentation>
                Synchronizes association values by correlating and mapping them to values of respective focus item
                (typically, an assignment).
            </xsd:documentation>
            <xsd:appinfo>
                <a:container>true</a:container>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" ref="tns:description"/>
            <xsd:element minOccurs="0" ref="tns:documentation"/>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:AttributeInboundMappingsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of given association attribute.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element maxOccurs="unbounded" minOccurs="0" name="objectRef" type="tns:AttributeInboundMappingsDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of given object-side of this association.
                        The object can be specified exactly (via "ref" property), or kept implicit, if there's only one object.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="activation" type="tns:ResourceActivationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        Outbound processing of the activation of this association.
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="correlation" type="tns:CorrelationDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        How objects of this type are correlated to focus objects?
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="synchronization" type="tns:ItemSynchronizationReactionsType">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
            <xsd:element minOccurs="0" name="target" type="tns:AssociationInboundMappingTargetDefinitionType">
                <xsd:annotation>
                    <xsd:documentation>
                        TODO
                    </xsd:documentation>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="associationSynchronization" substitutionGroup="tns:expressionEvaluator" type="tns:AssociationSynchronizationExpressionEvaluatorType">
        <xsd:annotation>
            <xsd:appinfo>
                <a:displayName>ExpressionType.associationSynchronization</a:displayName>
            </xsd:appinfo>
        </xsd:annotation>
    </xsd:element>

    <xsd:complexType name="ShadowBehaviorType">
        <xsd:annotation>
            <xsd:documentation>
                Shadow behavioral data.
                In a more specific meaning: behavioral data of an agent (user or system), usually represented in midPoint by shadow.
                This data structure records informational data about the agent's behavior, such as authentications, interaction with external systems and so on.
                Such data are inherently _observed_, e.g. they are not configured by the user.
            </xsd:documentation>
            <xsd:appinfo>
                <a:container/>
                <a:since>4.9</a:since>
            </xsd:appinfo>
        </xsd:annotation>
        <xsd:sequence>
            <xsd:element minOccurs="0" name="lastLoginTimestamp" type="xsd:dateTime">
                <xsd:annotation>
                    <xsd:documentation>
                        The date and time of last successful login attempt.
                    </xsd:documentation>
                    <xsd:appinfo>
                        <a:displayName>ShadowBehaviorType.lastLoginTimestamp</a:displayName>
                        <a:displayHint>regular</a:displayHint>
                        <a:operational>true</a:operational>
                    </xsd:appinfo>
                </xsd:annotation>
            </xsd:element>
        </xsd:sequence>
        <xsd:attribute name="id" type="xsd:long"/>
    </xsd:complexType>

</xsd:schema>