Schema "common-1.xsd"
Target Namespace:
http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd
Defined Components:
49 global elements, 214 local elements, 86 complexTypes, 15 simpleTypes
Default Namespace-Qualified Form:
Local Elements: qualified; Local Attributes: unqualified
Schema Location:
C:\workspace\tags\midpoint-1.9\infra\schema\src\main\resources\xml\ns\public\common\common-1.xsd; see XML source
Imports Schemas (3):
annotation-1.xsd [src], xenc-schema.xsd [src], XMLSchema.xsd [src]
Imported by Schemas (2):
capabilities-1.xsd [src], resource-schema-1.xsd [src]
Annotation
Annotation 1 [src]:
This is a common schema for midPoint project. It contains all the data types that the stock midPoint is using. This file contains more that a common schema in fact. It contains all the objects, even parts of what is known as identity schema and model schema in midPoint. See https://wiki.evolveum.com/display/midPoint/Data+Model for more details.
Annotation 2 [src]:
IDM Model schema defines the structure of roles, rules, access policies, method of assignment of accounts and other resource objects and all the properties of access control model. It is based on the identity schema, using concepts of User, Account Shadow and so on. IDM Model schema is static, it is available in compile-time. Current IDM model schema defines very minimal RBAC model. It is defined as temporary model to allow midPoint to be usable while we take the time to design a full-featured complex IDM model. Expect that the model will be replaced and do not depend on this schema in low-level components (except perhaps repository).
All Element Summary
tns:access
Type:
Content:
simple
Defined:
globally; see XML source
Used:
tns:account
Type:
Content:
complex, 2 attributes, 9 elements, elem. wildcard
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:account (type tns:AccountShadowType) Set of user's accounts.
Type:
Content:
complex, 2 attributes, 9 elements, elem. wildcard
Defined:
locally witnin tns:UserType complexType; see XML source
tns:accountConstruction (type tns:AccountConstructionType)
Type:
Content:
complex, 9 elements
Defined:
locally at 2 locations
tns:accountRef (type tns:ObjectReferenceType) Set of user's accounts.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:UserType complexType; see XML source
tns:accountType (in tns:schemaHandling) Defiens a type from the resource schema (object class) that can be used for creating accounts.
Type:
anonymous complexType
Content:
complex, 2 attributes, 5 elements
Defined:
locally witnin tns:SchemaHandlingType complexType; see XML source
Includes:
definitions of 2 attributes, 5 elements
tns:action (in tns:reaction) Defines an action to take when a situation is encountered.
Type:
anonymous complexType
Content:
complex, 1 attribute, elem. wildcard
Defined:
locally witnin tns:reaction element; see XML source
Includes:
definitions of 1 attribute, elem. wildcard
tns:activation (type tns:ActivationType)
Type:
Content:
complex, 3 elements
Defined:
locally at 3 locations
tns:additionalNames (type xsd:string) Middle name, nick name or any other names of a person.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:advanced (in tns:logging)
Type:
Content:
mixed (allows character data), elem. wildcard
Defined:
tns:allowedIdmGuiAccess (type xsd:boolean) If true, the user will have access to the IDM GUI.
Type:
Content:
simple
Defined:
locally witnin tns:CredentialsType complexType; see XML source
tns:and
Type:
Content:
complex, 1 element
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:append (type xsd:boolean)
Type:
Content:
simple
Defined:
tns:appender (in tns:logging)
Type:
Content:
complex, 1 attribute, 1 element
Defined:
tns:appender (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:argument (in tns:localizedMessage)
Type:
xsd:anySimpleType
Content:
simple
Defined:
tns:argument (in tns:script) Script aguments.
Type:
Content:
complex, 4 attributes, 9 elements
Defined:
locally witnin tns:ScriptType complexType; see XML source
tns:assignment (type tns:AssignmentType)
Type:
Content:
complex, 4 elements
Defined:
locally at 2 locations
tns:assignmentProperty (in tns:entitlementType) TODO
Type:
anonymous complexType
Content:
empty, 3 attributes
Defined:
Includes:
definitions of 3 attributes
tns:attribute (in tns:accountConstruction) Account attribute values implied by this role.
Type:
Content:
complex, 4 attributes, 8 elements
Defined:
tns:attribute (in tns:accountType) Specification of handling of an account attribute.
Type:
Content:
complex, 1 attribute, 6 elements
Defined:
locally witnin tns:accountType element; see XML source
tns:attributes (defined in tns:ResourceObjectShadowType complexType) Attribute values from the resource.
Type:
anonymous complexType
Content:
complex, elem. wildcard
Defined:
Includes:
definition of elem. wildcard
tns:availableValues (type tns:PropertyAvailableValuesType)
Type:
Content:
complex, 1 attribute, 1 element, elem. wildcard
Defined:
tns:binding (in tns:task) TODO loose - tight If not present the nodes may decide independently.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:cachingMetadata
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
tns:capabilities (type tns:CapabilitiesType) The capabilities supported by the resource, including both native capabilities of the connector and simulated capabilities.
Type:
Content:
complex, elem. wildcard
Defined:
locally witnin tns:ResourceType complexType; see XML source
tns:characterClass (type tns:CharacterClassType)
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally at 3 locations
tns:checkAgainstDictionary (in tns:limitations)
Type:
Content:
simple
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:checkPattern (in tns:limitations)
Type:
Content:
simple
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:claimExpirationTimestamp (in tns:task) Expiration of the claim.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:class (in tns:unknownJavaObject)
Type:
Content:
simple
Defined:
tns:classLogger (in tns:logging)
Type:
Content:
complex, 3 elements
Defined:
tns:clearValue (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:code (in tns:script) Script code represented as string.
Type:
Content:
simple
Defined:
locally witnin tns:ScriptType complexType; see XML source
tns:code (type tns:ExpressionCodeType) TODO
Type:
Content:
mixed (allows character data)
Defined:
locally witnin tns:ExpressionType complexType; see XML source
tns:component (in tns:subSystemLogger) TODO: components are OR-ed TODO: string, but there should be a way how to determine list of valid categories.
Type:
Content:
simple
Defined:
tns:condition Boolean condition.
Type:
Content:
complex, 4 elements
Defined:
globally; see XML source
Used:
tns:configuration Resource configuration (hostname, port, ...).
Type:
anonymous complexType
Content:
complex, elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
tns:configuration (in tns:connectorFramework) Global configuration properties of a connector framework.
Type:
anonymous complexType
Content:
complex, 2 elements
Defined:
Includes:
definitions of 2 elements
tns:confirmation (in tns:synchronization) Confirmation expression.
Type:
Content:
complex, 4 elements
Defined:
tns:connector
Type:
Content:
complex, 2 attributes, 12 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:connector (type tns:ConnectorType) "Composite" version of the ConnectorType reference.
Type:
Content:
complex, 2 attributes, 12 elements
Defined:
locally witnin tns:ResourceType complexType; see XML source
tns:connectorBundle (type xsd:string) Name of a package that the connector comes in.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:connectorFramework (in tns:systemConfiguration) Global configuration of connectors and connector frameworks.
Type:
anonymous complexType
Content:
complex, 1 element
Defined:
Includes:
definition of 1 element
tns:connectorHost
Type:
Content:
complex, 2 attributes, 7 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:connectorHost (type tns:ConnectorHostType) Connector host that hosts this connector.
Type:
Content:
complex, 2 attributes, 7 elements
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:connectorHostRef (type tns:ObjectReferenceType) Reference to the connector host that hosts this connector.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:connectorPath (in tns:configuration in tns:connectorFramework) The path to the connector artifacts such as JAR files or directories containing the connector code.
Type:
Content:
simple
Defined:
tns:connectorRef (type tns:ObjectReferenceType) Reference to the connector that implements specified resource.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:ResourceType complexType; see XML source
tns:connectorType (type xsd:string) Type of the connector, as seen by the framework.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:connectorVersion (type xsd:string) Version of the connector.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:containedObject (type tns:ObjectType) Contained object.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:ProtoStructureType complexType; see XML source
tns:containedObjectRef (type tns:ObjectReferenceType) Reference to the contained object.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:ProtoStructureType complexType; see XML source
tns:correlation (in tns:synchronization) Correlation expression.
Type:
Content:
complex, 2 elements
Defined:
tns:credentials
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
never
tns:credentials (in tns:accountType) Definition of credentials handling for this account type.
Type:
anonymous complexType
Content:
complex, 2 elements
Defined:
locally witnin tns:accountType element; see XML source
Includes:
definitions of 2 elements
tns:credentials (type tns:CredentialsType)
Type:
Content:
complex, 2 elements
Defined:
locally at 2 locations
tns:defaultUserTemplate (in tns:systemConfiguration) User template that will be used "universtally" in all situations regarding user internal consistency.
Type:
Content:
complex, 2 attributes, 5 elements
Defined:
tns:defaultUserTemplateRef (in tns:systemConfiguration) Reference to the default user template that will be used "universtally" in all situations regarding user internal consistency.
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
tns:dependency (type tns:XPathType) Defines the XPath of a property on which the expression depends.
Type:
Content:
mixed (allows character data)
Defined:
tns:description Free-form textual description of the object.
Type:
Content:
simple
Defined:
globally; see XML source
Used:
at 12 locations
tns:description (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:details (type xsd:string)
Type:
Content:
simple
Defined:
tns:eMailAddress (type xsd:string) E-Mail address of the user.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:employeeNumber (type xsd:string) Unique, business-oriented identifier of the employee.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:employeeType (type xsd:string) Employee type specification such as internal employee, external or partner.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:enabled (type xsd:boolean)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:encryptProtectedValues (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:entitlement (in tns:accountConstruction) Assignments implied by this role.
Type:
Content:
complex, 4 attributes, 10 elements
Defined:
tns:entitlementType (in tns:schemaHandling) Type of entitlements such as groups, roles entitlements, organizatrions, etc.
Type:
anonymous complexType
Content:
complex, 1 attribute, 3 elements
Defined:
locally witnin tns:SchemaHandlingType complexType; see XML source
Includes:
definitions of 1 attribute, 3 elements
tns:entry (in tns:params)
Type:
Content:
complex, 1 attribute, elem. wildcard
Defined:
locally witnin tns:ParamsType complexType; see XML source
tns:equal
Type:
Content:
complex, 3 elements
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:exclusivityStatus (in tns:task) Exclusivity status tells about task "locking" to a particular node.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:executionStatus (in tns:task) Execution status provides information about the task overall high-level execution state.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:expiration (in tns:lifetime) Number of days before password expires -1 : means password doesn't expire 0 : means password is expired
Type:
Content:
simple
Defined:
tns:expression
Type:
Content:
complex, 4 elements
Defined:
globally; see XML source
Used:
never
tns:extension Place for non-standard object properties.
Type:
anonymous complexType
Content:
complex, elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
tns:failedLogins (in tns:password) The number of failed logins.
Type:
Content:
simple
Defined:
locally witnin tns:password element; see XML source
tns:familyName (type xsd:string) Family name of the user.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:fetchResourceSchema (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:fileName (type xsd:string)
Type:
Content:
simple
Defined:
tns:filePattern (type xsd:string)
Type:
Content:
simple
Defined:
tns:filter
Type:
Content:
empty
Subst.Gr:
may be substituted with 10 elements
Defined:
globally; see XML source
Used:
at 14 locations
tns:framework (type xsd:anyURI) Identification of the framework or mechanism that implements this connector.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:fullName (type xsd:string) Full name of the user with all the decorations, middle name initials, honorific title and any other structure that is usual in the cultural environment that the system operates in.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:genericObject
Type:
Content:
complex, 2 attributes, 4 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:givenName (type xsd:string) Given name of the user.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:greaterOrEqual
Type:
Content:
complex, 3 elements
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:handlerUri (in tns:task) Handler URI indirectly specifies which class is responsible to handle the task.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:honorificPrefix (type xsd:string) Honorific titles that go before the name.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:honorificSuffix (type xsd:string) Honorific titles that go after the name.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:host (in tns:script) Defines where the script should be executed (connector or resource).
Type:
Content:
simple
Defined:
locally witnin tns:ScriptType complexType; see XML source
tns:hostname (type xsd:string) Hostname of a remote host.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorHostType complexType; see XML source
tns:ignore Presence of this element signifies that the strcture that it contains should be ignored.
Type:
Content:
simple
Defined:
globally; see XML source
Used:
tns:inbound (in tns:attribute in tns:accountType) 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.
Type:
Content:
complex, 4 elements
Defined:
tns:interval (in tns:schedule) Interval in seconds between task invocations.
Type:
Content:
simple
Defined:
locally witnin tns:ScheduleType complexType; see XML source
tns:keepOid (type xsd:boolean) If set to a true value it will cause that objects that overwritten objects will reuse the same OID as previous objects.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:key (in tns:localizedMessage)
Type:
Content:
simple
Defined:
tns:language (type xsd:anyURI)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:lastFailedLoginTimestamp (in tns:password) The date and time of last failed login attempt.
Type:
Content:
simple
Defined:
locally witnin tns:password element; see XML source
tns:lastRunFinishTimestamp (in tns:task) TODO
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:lastRunStartTimestamp (in tns:task) TODO
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:lessOrEqual
Type:
Content:
complex, 3 elements
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:level (type tns:LoggingLevelType)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:lifetime (in tns:passwordPolicy)
Type:
Content:
complex, 5 elements
Defined:
locally witnin tns:PasswordPolicyType complexType; see XML source
tns:limit (in tns:limitations)
Type:
Content:
complex, 5 elements
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:limitations (in tns:stringPolicy)
Type:
Content:
complex, 6 elements
Defined:
locally witnin tns:StringPolicyType complexType; see XML source
tns:locality (type xsd:string) Primary locality of the user, the place where the user usually works, the contry, city or building that he belongs to.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:localizedMessage (type tns:LocalizedMessageType)
Type:
Content:
complex, 2 elements
Defined:
tns:lockAfterExpiration (in tns:lifetime) Number of days after password after password expiration the account will be locked (0 means never will be locked)
Type:
anonymous simpleType (restriction of xsd:int)
Content:
simple
Defined:
tns:logging (in tns:systemConfiguration) Persistent configuration of logging levels, categories, etc.
Type:
Content:
complex, 6 elements
Defined:
tns:maxFileSize (type xsd:string)
Type:
Content:
simple
Defined:
tns:maxHistory (type xsd:int)
Type:
Content:
simple
Defined:
tns:maxLength (in tns:limitations)
Type:
Content:
simple
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:maxOccurs (in tns:limit)
Type:
Content:
simple
Defined:
locally witnin tns:StringLimitType complexType; see XML source
tns:maxSize (type xsd:int) The maximum number of entries returned.
Type:
Content:
simple
Defined:
locally witnin tns:PagingType complexType; see XML source
tns:message (type xsd:string) Error or warning message.
Type:
Content:
simple
Defined:
tns:messageCode (type xsd:string)
Type:
Content:
simple
Defined:
tns:minLength (in tns:limitations)
Type:
Content:
simple
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:minOccurs (in tns:limit)
Type:
Content:
simple
Defined:
locally witnin tns:StringLimitType complexType; see XML source
tns:minPasswordAge (in tns:lifetime) Number of days before password may be changed (0 means password can be changed immediately)
Type:
Content:
simple
Defined:
tns:minUniqueChars (in tns:limitations)
Type:
Content:
simple
Defined:
locally witnin tns:limitationsType complexType; see XML source
tns:modification
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
never
tns:mustBeFirst (in tns:limit)
Type:
Content:
simple
Defined:
locally witnin tns:StringLimitType complexType; see XML source
tns:name Human-readable name for object, property, attribute or whatever.
Type:
Content:
simple
Defined:
globally; see XML source
Used:
tns:name (in tns:argument in tns:script) Argument name.
Type:
Content:
simple
Defined:
locally witnin tns:ScriptArgumentType complexType; see XML source
tns:namespace (type xsd:anyURI)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:nativeCapabilities (type tns:CapabilitiesType) The capabilities nativelly supported by the connector without any simulation or any other workaround.
Type:
Content:
complex, elem. wildcard
Defined:
locally witnin tns:ResourceType complexType; see XML source
tns:node (in tns:task) Identifier of the node that has claimed this task.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:not
Type:
Content:
complex, 1 element
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:object
Type:
Content:
complex, 2 attributes, 2 elements
Subst.Gr:
may be substituted with 10 elements
Defined:
globally; see XML source
Used:
at 11 locations
tns:object (type tns:ObjectType)
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally at 2 locations
tns:object (type tns:ResourceObjectShadowType)
Type:
Content:
complex, 2 attributes, 7 elements, elem. wildcard
Defined:
tns:objectChange (type tns:ObjectChangeType) Description of changes that happened to an resource object shadow.
Type:
Content:
empty
Defined:
tns:objectClass (type xsd:QName)
Type:
Content:
simple
Defined:
locally at 3 locations
tns:objectModification
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
never
tns:objectModification (type tns:ObjectModificationType)
Type:
Content:
complex, 2 elements
Defined:
tns:objectRef
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
globally; see XML source
Used:
never
tns:objectRef (type tns:ObjectReferenceType)
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally at 2 locations
tns:objects
Type:
anonymous complexType
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
tns:objectType (in tns:genericObject) Type of the stored object.
Type:
Content:
simple
Defined:
locally witnin tns:GenericObjectType complexType; see XML source
tns:offset (type xsd:int) The index of the first returned entry, starting with zero.
Type:
Content:
simple
Defined:
locally witnin tns:PagingType complexType; see XML source
tns:oid (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:operation (in tns:script) Defines a set of operations for which the script should be executed.
Type:
Content:
simple
Defined:
locally witnin tns:ScriptType complexType; see XML source
tns:operation (type xsd:string)
Type:
Content:
simple
Defined:
tns:operationResult
Type:
Content:
complex, 9 elements
Defined:
globally; see XML source
Used:
never
tns:or
Type:
Content:
complex, 1 element
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:order (in tns:script) Defines the order in which a script is executed.
Type:
Content:
simple
Defined:
locally witnin tns:ScriptType complexType; see XML source
tns:orderBy (type tns:PropertyReferenceType) Property by which the results should be sorted.
Type:
Content:
complex, 1 element
Defined:
locally witnin tns:PagingType complexType; see XML source
tns:orderDirection (type tns:OrderDirectionType) Direction of ordering (ascending or descending).
Type:
Content:
simple
Defined:
locally witnin tns:PagingType complexType; see XML source
tns:organizationalUnit (type xsd:string) Name or (preferrably) immutable identifier of organizational unit that the user belongs to.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:outbound (in tns:attribute in tns:accountType) Defines how the attribute value is constructed in case of information flow from IDM to the resource, e.g. in case of provisioning.
Type:
Content:
complex, 4 attributes, 8 elements
Defined:
tns:outboundPassword (in tns:credentials in tns:accountType) If true then the passowrd of the resource account will be automatically changed when user password is changed.
Type:
Content:
simple
Defined:
locally witnin tns:credentials element; see XML source
tns:overwrite (type xsd:boolean) If set to a true value it will cause that objects that are already in the repository will be overwritten by the imported objects.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:package (in tns:classLogger) TODO: packages are OR-ed TODO: string, wildcards allowed (* as in java)
Type:
Content:
simple
Defined:
tns:params (type tns:ParamsType)
Type:
Content:
complex, 1 element
Defined:
tns:partialResults (type tns:OperationResultType)
Type:
Content:
complex, 9 elements
Defined:
tns:password (defined in tns:CredentialsType complexType)
Type:
anonymous complexType
Content:
complex, 3 elements
Defined:
locally witnin tns:CredentialsType complexType; see XML source
Includes:
definitions of 3 elements
tns:passwordHistoryLength (in tns:lifetime) Number of unique passwords in history (0 - no history)
Type:
Content:
simple
Defined:
tns:passwordPolicy
Type:
Content:
complex, 2 attributes, 4 elements
Defined:
globally; see XML source
Used:
never
tns:path XPath expression selecting the property container.
Type:
Content:
mixed (allows character data)
Defined:
globally; see XML source
Used:
tns:pattern (in tns:appender in tns:logging)
Type:
Content:
simple
Defined:
tns:port (type xsd:string) Port number of the remote service.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorHostType complexType; see XML source
tns:present
Type:
Content:
complex, 1 element
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:progress (in tns:task) Relative metric of task progress.
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:property XPath expression selecting the property.
Type:
Content:
mixed (allows character data)
Defined:
globally; see XML source
Used:
tns:property (type tns:PropertyReferenceType)
Type:
Content:
complex, 1 element
Defined:
tns:propertyConstruction (type tns:PropertyConstructionType) Defines how any of the User's properties should be constructed.
Type:
Content:
complex, 3 elements
Defined:
locally witnin tns:UserTemplateType complexType; see XML source
tns:propertyModification
Type:
Content:
complex, 1 attribute, 2 elements
Defined:
globally; see XML source
Used:
tns:protectedString (in tns:password)
Type:
Content:
complex, 2 elements
Defined:
locally witnin tns:password element; see XML source
tns:query
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
never
tns:randomPasswordLength (in tns:credentials in tns:accountType) If set to any value, the password will be randomly generated when a new account is created and the password cannot be determined otherwise.
Type:
Content:
simple
Defined:
locally witnin tns:credentials element; see XML source
tns:reaction (in tns:synchronization) Reaction to a synchronization situation.
Type:
anonymous complexType
Content:
complex, 3 elements
Defined:
Includes:
definitions of 3 elements
tns:recurrence (in tns:task) TODO
Type:
Content:
simple
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:ref (type xsd:QName) QName of the XML node that the expression is supposed to produce.
Type:
Content:
simple
Defined:
locally witnin tns:ExpressionType complexType; see XML source
tns:referentialIntegrity (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:resource
Type:
Content:
complex, 2 attributes, 13 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:resource (type tns:ResourceType)
Type:
Content:
complex, 2 attributes, 13 elements
Defined:
locally at 3 locations
tns:resourceObjectShadow
Type:
Content:
complex, 2 attributes, 7 elements, elem. wildcard
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:resourceRef (type tns:ObjectReferenceType)
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally at 2 locations
tns:result (in tns:task) OperationResult that is used to compile task results (parent result).
Type:
Content:
complex, 9 elements
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:retrievalTimestamp (in tns:cachingMetadata) The timestamp of a time moment when the object was retrieved from the source.
Type:
Content:
simple
Defined:
locally witnin tns:CachingMetadata complexType; see XML source
tns:role
Type:
Content:
complex, 2 attributes, 4 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:rootLoggerAppender (in tns:logging)
Type:
Content:
simple
Defined:
tns:rootLoggerLevel (in tns:logging)
Type:
Content:
simple
Defined:
tns:schedule (in tns:task) Task schedule.
Type:
Content:
complex, 1 element
Defined:
locally witnin tns:TaskType complexType; see XML source
tns:schema
Type:
Content:
complex, 1 element, elem. wildcard
Defined:
globally; see XML source
Used:
tns:schemaHandling
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
tns:script (in tns:scripts) Specific script definition.
Type:
Content:
complex, 6 elements
Defined:
locally witnin tns:ScriptsType complexType; see XML source
tns:scripts
Type:
Content:
complex, 1 element
Defined:
globally; see XML source
Used:
tns:serialNumber (in tns:cachingMetadata) A string that uniquely represents the version of the data that was retrieved.
Type:
Content:
simple
Defined:
locally witnin tns:CachingMetadata complexType; see XML source
tns:shadow (type tns:ResourceObjectShadowType) Resource object shadow as seen by the component before the change, if possible.
Type:
Content:
complex, 2 attributes, 7 elements, elem. wildcard
Defined:
tns:sharedSecret (type xsd:string) Shared secret used to authenticate client to the host.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorHostType complexType; see XML source
tns:situation (in tns:reaction) Defines a particular synchronization situation.
Type:
Content:
simple
Defined:
locally witnin tns:reaction element; see XML source
tns:source (in tns:inbound) Source of assignement.
Type:
Content:
complex, 4 elements
Defined:
tns:sourceChannel (type xsd:anyURI) Definition of source channel (e.g. synchronization, reconciliation, discovery, ...)
Type:
Content:
simple
Defined:
tns:status (type tns:OperationResultStatusType)
Type:
Content:
simple
Defined:
tns:stopAfterErrors (type xsd:int) Number of errors that will cause import to stop.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:stringPolicy (in tns:passwordPolicy)
Type:
Content:
complex, 3 elements
Defined:
locally witnin tns:PasswordPolicyType complexType; see XML source
tns:substring
Type:
Content:
complex, 3 elements
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:subSystemLogger (in tns:logging)
Type:
Content:
complex, 3 elements
Defined:
tns:summarizeErrors (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:summarizeSucceses (type xsd:boolean) If set to true the successfuly imported items will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:synchronization
Type:
Content:
complex, 4 elements
Defined:
globally; see XML source
Used:
tns:systemConfiguration
Type:
Content:
complex, 2 attributes, 7 elements
Defined:
globally; see XML source
Used:
never
tns:target (in tns:assignment) TODO: target
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:AssignmentType complexType; see XML source
tns:target (in tns:inbound) Destination of the assignment.
Type:
Content:
mixed (allows character data)
Defined:
tns:targetRef (in tns:assignment) TODO: target ref
Type:
Content:
complex, 2 attributes, 2 elements
Defined:
locally witnin tns:AssignmentType complexType; see XML source
tns:targetSystemType (type xsd:anyURI) Identification of the kind of target system that the connector can connect to, such as "LDAP" or "DB Table".
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorType complexType; see XML source
tns:task
Type:
Content:
complex, 2 attributes, 16 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:telephoneNumber (type xsd:string) Primary telephone number of the user.
Type:
Content:
simple
Defined:
locally witnin tns:UserType complexType; see XML source
tns:timeout (type xsd:int) Timeout (in milliseconds) used when initially connecting to the host or during other connections when timeout is not otherwise specified.
Type:
Content:
simple
Defined:
locally witnin tns:ConnectorHostType complexType; see XML source
tns:token (type xsd:long)
Type:
Content:
simple
Defined:
tns:toString (in tns:unknownJavaObject)
Type:
Content:
simple
Defined:
tns:true
Type:
Content:
complex, 1 element
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:type
Type:
Content:
empty, 1 attribute
Subst.Gr:
may substitute for element tns:filter
Defined:
globally; see XML source
Used:
never
tns:type (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:typeExpression (type tns:ExpressionType)
Type:
Content:
complex, 4 elements
Defined:
locally at 2 locations
tns:unknownJavaObject
Type:
Content:
complex, 2 elements
Defined:
globally; see XML source
Used:
never
tns:user
Type:
Content:
complex, 2 attributes, 20 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:user (type tns:UserType)
Type:
Content:
complex, 2 attributes, 20 elements
Defined:
locally witnin tns:UserListType complexType; see XML source
tns:userTemplate
Type:
Content:
complex, 2 attributes, 5 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally; see XML source
Used:
never
tns:validateDynamicSchema (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:validateStaticSchema (type xsd:boolean) If set to true the importe errors will be summarized in the result.
Type:
Content:
simple
Defined:
locally witnin tns:ImportOptionsType complexType; see XML source
tns:validFrom (in tns:activation) A date from which is should the object be considered active.
Type:
Content:
simple
Defined:
locally witnin tns:ActivationType complexType; see XML source
tns:validTo (in tns:activation) A date to which is should the object be considered active.
Type:
Content:
simple
Defined:
locally witnin tns:ActivationType complexType; see XML source
tns:value (defined in tns:ValueConstructionType complexType) Static value for the attribute or property.
Type:
anonymous complexType
Content:
mixed (allows character data), elem. wildcard
Nillable:
(can be declared as nil using xsi:nil attribute in instance XML documents)
Defined:
Includes:
definition of elem. wildcard
tns:value (in tns:equal)
Type:
anonymous complexType
Content:
complex, elem. wildcard
Defined:
Includes:
definition of elem. wildcard
tns:value (in tns:propertyModification)
Type:
anonymous complexType
Content:
complex, elem. wildcard
Defined:
Includes:
definition of elem. wildcard
tns:value (type xsd:anyType) The elements and values of queried properties.
Type:
Content:
mixed (allows character data), attr. wildcard, elem. wildcard
Defined:
tns:value (type xsd:string)
Type:
Content:
simple
Defined:
locally at 2 locations
tns:valueConstruction (in tns:propertyConstruction) Reference (QName) of the property which value is defined by this type.
Type:
Content:
complex, 4 attributes, 8 elements
Defined:
tns:valueExpression (type tns:ExpressionType)
Type:
Content:
complex, 4 elements
Defined:
locally at 3 locations
tns:valueFilter
Type:
Content:
complex, 1 attribute, elem. wildcard
Defined:
globally; see XML source
Used:
tns:variable (type tns:VariableDefinitionType) Definition of additional variables that should be present during evaluation of the expression.
Type:
Content:
complex, 1 attribute, 3 elements
Defined:
tns:warnBeforeExpiration (in tns:lifetime) Number of days before password expiration to send warnings (0 means no warnings)
Type:
anonymous simpleType (restriction of xsd:int)
Content:
simple
Defined:
Complex Type Summary
Content:
complex, 9 elements
Defined:
globally; see XML source
Includes:
definitions of 9 elements
Used:
Account object type.
Content:
complex, 2 attributes, 9 elements, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Type that defines activation properties.
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
Contains free form loging configuration.
Content:
mixed (allows character data), elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
Configuration of the logger: the facility that collects log messages from the code.
Content:
complex, 1 attribute, 1 element
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
Generic assignments of one object to another object.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
Description of the attribute handling, such as display name, read/write access and value and synchronization expressions.
Content:
complex, 1 attribute, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 6 elements
Used:
Metadata that record when a cache copy was retrieved, the identifiers (etags) of that copy and possibly also other data.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
TODO
Content:
complex, elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
Definition of valid characters in class.
Content:
complex, 2 attributes, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 attributes, 2 elements
Used:
Configuration of the logger: the facility that collects log messages from the code.
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
Host definition for remote connector, remote connector framework or a remote "gateway".
Content:
complex, 2 attributes, 7 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
Description of a generic connector.
Content:
complex, 2 attributes, 12 elements
Defined:
globally; see XML source
Includes:
definitions of 9 elements
Used:
This is a container type for various credentials types: passwords, public keys, one-time password scheme identifiers, etc.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Type that contains nothing.
Content:
empty
Defined:
globally; see XML source
Used:
never
Content:
complex, 4 attributes, 10 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Content:
complex, 1 attribute, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, elem. wildcard
Used:
The expression code is supposed to be in the contect of this type.
Content:
mixed (allows character data)
Defined:
globally; see XML source
Used:
Generic expression.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
Object with generic extensibility mechanism.
Content:
complex, 2 attributes, 3 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
at 11 locations
Content:
complex, 1 attribute, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 5 elements
Used:
never
Content:
empty
Defined:
globally; see XML source
Used:
Generic object for storing unknown (unexpected) object types.
Content:
complex, 2 attributes, 4 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
The options for import tasks.
Content:
complex, 10 elements
Defined:
globally; see XML source
Includes:
definitions of 10 elements
Used:
never
Definition of complexity and string policy
Content:
complex, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 6 elements
Used:
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Configuration of logging levels, categories, log files, etc.
Content:
complex, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 6 elements
Used:
Content:
empty
Abstract:
(cannot be assigned directly to elements used in instance XML documents)
Defined:
globally; see XML source
Used:
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Describes object addition (creation, operation "add").
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Describes object deletion (operation "delete").
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Describes object modification (operation "modify").
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Describes a change of a specific object.
Content:
empty
Abstract:
(cannot be assigned directly to elements used in instance XML documents)
Defined:
globally; see XML source
Used:
Content:
complex, 1 attribute, 1 element
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
never
Describes a change of attributes of a specific object.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Reference to an object.
Content:
complex, 2 attributes, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 attributes, 2 elements
Used:
Common supertype for all identity objects.
Content:
complex, 2 attributes, 2 elements
Abstract:
(cannot be assigned directly to elements used in instance XML documents)
Defined:
globally; see XML source
Includes:
definitions of 2 attributes, 2 elements
Used:
TODO
Content:
complex, 9 elements
Defined:
globally; see XML source
Includes:
definitions of 9 elements
Used:
Parameters limiting the number of returned entries, offset, etc.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
never
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Content:
complex, 5 elements
Defined:
globally; see XML source
Includes:
definitions of 5 elements
Used:
Content:
complex, 2 attributes, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
TODO
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Describe available or proposed values of an attribute.
Content:
complex, 1 attribute, 1 element, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, elem. wildcard
Used:
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
Definition of construction of a (general) property.
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Property container reference.
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Describe a change to a single attribute.
Content:
complex, 1 attribute, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
TODO
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Property reference.
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
ONLY COPIED AND PASTED FROM ProtectedStringType, please update if needed later TODO
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
never
This is a general-purpose type to store sensitive values that should be encrypted in the repository.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
TODO Experimental object.
Content:
complex, 2 attributes, 5 elements
Abstract:
(cannot be assigned directly to elements used in instance XML documents)
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
never
TODO
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Content:
complex, elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
never
Describes a change of a specific resource object together with definitions of the source.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
never
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
Local copy of any object on the provisioning resource that is related to provisioning.
Content:
complex, 2 attributes, 7 elements, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 4 elements, elem. wildcard
Used:
Content:
complex, elem. wildcard
Defined:
globally; see XML source
Includes:
definition of elem. wildcard
Used:
never
Resource represents a system or component external to the IDM system which we manage.
Content:
complex, 2 attributes, 13 elements
Defined:
globally; see XML source
Includes:
definitions of 10 elements
Used:
A role that implies assignments.
Content:
complex, 2 attributes, 4 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Task schedule.
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Specification of handling details for resource schema.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Script argument.
Content:
complex, 4 attributes, 9 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Collection of scripts to be executed for various provisioning operations.
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Specifies how and when a script is executed during provisioning.
Content:
complex, 6 elements
Defined:
globally; see XML source
Includes:
definitions of 6 elements
Used:
Definition of valid single string limitation
Content:
complex, 5 elements
Defined:
globally; see XML source
Includes:
definitions of 5 elements
Used:
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
Configuration of the logger: the facility that collects log messages from subsystem code.
Content:
complex, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 3 elements
Used:
Defines a synchronization properties (configuration) for a resource.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
System configuration object.
Content:
complex, 2 attributes, 7 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
TODO
Content:
complex, 2 attributes, 16 elements
Defined:
globally; see XML source
Includes:
definitions of 13 elements
Used:
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Type used to represent Java objects that are otherwise unknown to the system and cannot be represented in "canonical" XML form.
Content:
complex, 2 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
Content:
empty, 1 attribute
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
complex, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
never
The user template used to create new users.
Content:
complex, 2 attributes, 5 elements
Defined:
globally; see XML source
Includes:
definitions of 2 elements
Used:
User object type.
Content:
complex, 2 attributes, 20 elements
Defined:
globally; see XML source
Includes:
definitions of 17 elements
Used:
Defines an assignment of value from one place (or expression) to another place.
Content:
complex, 4 elements
Defined:
globally; see XML source
Includes:
definitions of 4 elements
Used:
Defines how a value of a property (or attribute) should be constructed.
Content:
complex, 4 attributes, 8 elements
Defined:
globally; see XML source
Includes:
definitions of 4 attributes, 8 elements
Used:
Defines value filter.
Content:
complex, 1 attribute, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, elem. wildcard
Used:
Definition of a variable.
Content:
complex, 1 attribute, 3 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 3 elements
Used:
This element contains the XSD-formatted definition of schema.
Content:
complex, 1 element, elem. wildcard
Defined:
globally; see XML source
Includes:
definitions of 1 element, elem. wildcard
Used:
Defines a type for XPath pointer.
Content:
mixed (allows character data)
Defined:
globally; see XML source
Used:
Simple Type Summary
TODO
Defined:
globally; see XML source
Used:
TODO
Defined:
globally; see XML source
Used:
TODO
Defined:
globally; see XML source
Used:
TODO
Defined:
globally; see XML source
Used:
Type of an operation (change).
Defined:
globally; see XML source
Used:
Type of an operation (change).
Defined:
globally; see XML source
Used:
TODO The "TypeType" in the name is correct.
Defined:
globally; see XML source
Used:
An enumeration that defines where the script will be excuted.
Defined:
globally; see XML source
Used:
An enumeration that defines when the script will be excuted.
Defined:
globally; see XML source
Used:
TODO
Defined:
globally; see XML source
Used:
OID constants for system objects
Defined:
globally; see XML source
Used:
never
TODO
Defined:
globally; see XML source
Used:
Exclusivity status tells about task "locking" to a particular node.
Defined:
globally; see XML source
Used:
Execution status provides information about the task overall high-level execution state.
Defined:
globally; see XML source
Used:
TODO
Defined:
globally; see XML source
Used:
XML Source
<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2011 Evolveum -->
<!-- -->
<!-- The contents of this file are subject to the terms -->
<!-- of the Common Development and Distribution License -->
<!-- (the License). You may not use this file except in -->
<!-- compliance with the License. -->
<!-- -->
<!-- You can obtain a copy of the License at -->
<!-- http://www.opensource.org/licenses/cddl1 or -->
<!-- CDDLv1.0.txt file in the source code distribution. -->
<!-- See the License for the specific language governing -->
<!-- permission and limitations under the License. -->
<!-- -->
<!-- If applicable, add the following below the CDDL Header, -->
<!-- with the fields enclosed by brackets [] replaced by -->
<!-- your own identifying information: -->
<!-- -->
<!-- Portions Copyrighted 2011 [name of copyright owner] -->
<!-- -->
<!-- Portions Copyrighted 2010-2011 ForgeRock, Inc. -->
<xsd:schema elementFormDefault="qualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="2.0" targetNamespace="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:a="http://midpoint.evolveum.com/xml/ns/public/common/annotation-1.xsd" xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:tns="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
This is a common schema for midPoint project. It contains all the
data types that the stock midPoint is using.

This file contains more that a common schema in fact. It contains
all the objects, even parts of what is known as identity schema and
model schema in midPoint.

See https://wiki.evolveum.com/display/midPoint/Data+Model for more details.
</xsd:documentation>
<xsd:appinfo>
<jaxb:globalBindings>
<xjc:typeSubstitution type="complex"/>
<xjc:serializable uid="201105211233"/>
</jaxb:globalBindings>
</xsd:appinfo>
</xsd:annotation>
<xsd:import namespace="http://www.w3.org/2001/XMLSchema" schemaLocation="../../standard/XMLSchema.xsd">
<xsd:annotation>
<xsd:documentation>
Importing the schema of XSD schema definition explicitly. This causes that we can use "strict" matching
for the xsd:schema elements used in runtime.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="../../standard/xenc-schema.xsd">
<xsd:annotation>
<xsd:documentation>
The XML Encryption schema. Used for "protected" data types (property encryption).
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<xsd:annotation>
<xsd:documentation>
Common midPoint annotations used in various XSD schemas.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!-- ################################## -->
<!-- ## Common Schema Layer ## -->
<!-- ################################## -->
<!-- See https://wiki.evolveum.com/display/midPoint/Common+Schema -->
<xsd:element name="name" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Human-readable name for object, property, attribute or whatever.

TODO: Any special reason this is top-level element?
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType mixed="true" name="XPathType">
<xsd:annotation>
<xsd:appinfo>
<jaxb:dom/>
</xsd:appinfo>
<xsd:documentation>
Defines a type for XPath pointer. It points to a specific part
of the XML tree. Only a path expressions should be used in
this type, as it is used as an l-value, i.e. pointing to a
part of XML where an value can be assigned.

cf. ExpressionType
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<!-- Basic Object Types -->
<xsd:complexType abstract="true" name="ObjectType">
<xsd:annotation>
<xsd:documentation>
Common supertype for all identity objects.

Defines basic properties that each object must have to live in
our system (identifier, name).

Objects consists of identifier and name (see definition below)
and a set of properties represented as XML elements in the
object's body. The properties are represented as first-level
XML elements (tags) of the object XML representation and may
be also contained in other tags (e.g. extension, attributes)
that are marked by a propertyContainer annotation. The QName
(namespace and local name) of the element holding the property
is considered to be a property name.

Single-value properties must appear as a none or one instance
of the XML element holding the value.

Multi-value properties must appear as none or more instances of
the same XML element. Multi-valued properties are regarded as
unordered sets. Duplicate values are allowed, but duplicates
should not be preserved by the implementations. The implementations
should reduce duplicate values to a single value if it is
possible and efficient.

If an element for a specific property does not appear in the
object it means that the property value is undefined (property
does not exists). This is a different state as compared to
passing an empty XML element. Empty XML element means that the
property exists, but has an empty (null) value. Implementations
must be able to handle undefined (non-existent) properties, but
may NOT be able to handle empty (null) values. The use of empty
(null) values is DISCOURADGED.

It is not mandated by this specification how to pass ordered
lists and multi-value properties with duplicates. However it is
recommended to use single value properties with appropriate complex
XML data structures to hold such data.

The following XML snippet is an example of the object (omitting
namespace definitions, but assuming default namespace to be the
target namespace of this schema definition):
<![CDATA[
<user oid="d3adm3a4" version="42">
<name>foobar</name>
<extension>
<foo:geekName>F00 B4r</foo:geekName>
<org:guild>Societus Geekus Europeus</org:guild>
<org:guild>Basset User Group</org:guild>
<pet:pet><pet:species>dog</pet:species><pet:breed>basset</pet:breed><pet:name>Doggie</pet:name></pet:pet>
<pet:pet><pet:species>mouse</pet:species><pet:breed>logitech</pet:breed><pet:name>Mousee</pet:name></pet:pet>
<com:shoppingPreferences>
<com:tShirt><com:size>XXL</com:size><com:color>#000000</com:color></com:tShirt>
<com:tie><com:preference>no thanks</com:preference></com:tie>
</com:shoppingPreferences>
</extension>
<fullName>Foo Bar</fullName>
<givenName>Foo</givenName>
<familyName>Bar</familyName>
</user>
]]>
The above example describes an object with identifier "d3adm3a4",
name "foobar" and type defined by its top-level element User that
corresponds to URI "http://midpoint.evolveum.com/xml/ns/identity/1#User".
The object has 7 properties. Three of them are standard
properties defined by this schema:

Standard properties "fullName", "givenName" and "familyName"
in default namespace. These are single-valued string properties.

All the other properties are non-standard "extended" properties,
but they are considered equal to the standard attributes. They are
quarantined in the &lt;extension&gt; tag only to avoid XSD unique
particle attribution (UPA) problems. In the above example the
non-standard properties are:

Property "geekName" in namespace defined by "foo" prefix. This is also
single-valued string property.

Multi-valued non-standard property "guild". It is a string property
with multiple values. Multiple values are represented by providing
multiple instances of XML elements in the document.
Such properties are typically used for roles, groups, etc.

Complex property "pet". This property is defined by
complex XML type, using XML sub-elements to
represent structured data. Note that the use of XML attributes
is discouraged in the properties, although it might be possible in
some cases. This is also multi-valued property.

Complex property "shoppingPreferences". This property is using
complex XML type to form a structure of XML elements to
represent data. This is a single-valued property.
Note that the sub-elements "tShirt" and "tie" are NOT considered
to be properties.

QName-URI mapping:

For the purpose of this schema and all components that are using it,
URIs and QNames are considered equivalent. This is required by WWW
architecture and also helps avoid some drawbacks and bugs in XML-related
implementations that usually do not deal QNames well.

The QNames are mapped to URIs by concatenating namespace URI and a local
name. If URI does not end with slash (/) or hash (#) character, slash is
concatenated to the URI before adding the local name. The URI-QName
mapping is the reverse process.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" ref="tns:name">
<xsd:annotation>
<xsd:documentation>
Human-readable, mutable name of the object. It
may also be an identifier (login name, group name).
Should be unique in the respective context of
interpretation. E.g. the name of the UserType subtype
should be unique in the whole system.
The name of the AccountType subtype should be unique in the
scope of resource (target system) that it belongs to.

This may not be human-readable in a sense to display
to a common end-user. It is intended to be displayed to
IDM system administrator. Therefore it may contain quite
a "ugly" structures such as LDAP DN or URL.

Name is considered to be ordinary property of the object.
Therefore it can be changed by invoking usual modifyObject
operations. However, change of the name may have side
effects (rename process).

Although name is specified as optional by this schema, it
is in fact mandatory for most object types. The reason for
specifying the name as optional is that the name may be
generated by the system instead of supplied by the clients.
However, all objects stored in the repository must have a name.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" ref="tns:description">
<xsd:annotation>
<xsd:documentation>
Free-form textual description of the object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
System-wide immutable identifier for the object.
Will be probably quite long and not human-readable. It
should not be displayed to user. It has no meaning
outside of IDM system and should not be directly
passed to any third-party systems.

This identifier must be unique in the entire system.

This attribute is immutable.
It cannot be changed. Any operation attempting
to change this identifier must fail.

OID is not property and therefore cannot be "addressed"
in usual operations.

OID must be provided for all objects that are persistently
stored. There may be detached objects without OID.
Such objects have the same structure as normal objects,
they are just not stored in the repository. E.g.
object that are only stored on resource and are
not replicated in the repository. Such objects
do not have OID therefore their XML representation
cannot contain oid attribute.

The OID should be unique in both time and space. That
means that OIDs must be unique in the whole system
in any moment and should not be re-used. If an object is
deleted, the OID of that object should not be used by
a new object. The reason is to avoid problems with stale
links pointing to a wrong object and appearing valid.
However, this is not a strict requirement. Some marginal
probability of OID reuse is tolerated. The recommended
practice is to add some randomness to the process of
OID generation.

This attribute is NOT (necessarily) ASN.1 OID and should not
be confused with it.

The attribute is named "oid" meaning object identifier.
It is not named "id" to avoid confusion with xml:id
attribute as it is easy to confuse these two if
namespace prefix is omitted. The confusion with ASN.1
OID id not likely.

The oid is XML attribute of this object instead of
element because it has special purpose of identifying
the object. It is also immutable, therefore we do not
need to handle changes to it.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="version" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
Version for optimistic locking.

Contains the version in which this object was read from the
repository, fetched from the resource, etc.

Type of the version attribute is string, not integer to provide
flexibility for various versioning schemes in implementation
(e.g. ETags). The type really does not matter, the only
things that matters is if the version is the same or different.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="description" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Free-form textual description of the object. It is supposed to describe
the object or a construct that it is attached to.

Anything that the system administrator wants may be here. The system
will not interpret the information except for displaying it and allow
user to edit it.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extension">
<xsd:annotation>
<xsd:documentation>
Place for non-standard object properties. The
elements placed here will be handled exactly
like the elements in the object body.

It must NOT contain standard elements.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="ExtensibleObjectType">
<xsd:annotation>
<xsd:documentation>
Object with generic extensibility mechanism. It contains a
special XML element where almost any extension can be placed.
The extension is treated exactly the same as other object
properties by the code (storage, modifications, etc), except
that the system may not be able to understand their meaning.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:extension"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GenericObjectType">
<xsd:annotation>
<xsd:documentation>
Generic object for storing unknown (unexpected) object types.

The generic object should be used if there is a need to
store a custom object (e.g KangarooType) at deployment-time
and the XML type relacement extensibility cannot be used.
The properties of such custom objects are to be placed in the
extension part of this object. The schema is not checked or
enforced for this type of objects if technically possible.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ExtensibleObjectType">
<xsd:sequence>
<xsd:element name="objectType" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Type of the stored object.
This attribute contains URI defining the type (class) of
stored object. The URI that maps to a QName of an object
XML element should be used if possible (see QName
mapping above). However this is not mandatory and the
implementation must be able to work with any URI.

Object type may be changed, but the possible values may
be constrained by the implementation. E.g. the implementation
may allow to change the object type only to the subtype or
supertype, or it may fail if the attributes of the object
does not conform to the schema constraints defined for the
new type.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Reference to an object. It contains OID of the object that it
refers to.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element minOccurs="0" ref="tns:filter">
<xsd:annotation>
<xsd:documentation>
Filter that can be used to dynamically lookup the reference OID e.g. during imports.
It must not be used for normal operations and references with the filter must not
be stored in the repository.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="oid" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation>
Target of the reference.

Optional only during imports. The objects stored in the repository must have the OID
value filled in.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="type" type="xsd:QName" use="optional">
<xsd:annotation>
<xsd:documentation>
XSD type of the reference target object.

It should be provided if the type is known (e.g. when
reading object from the repository).

The primary reason for this is to have some kind of
type safety but especially to be able to use
this in the XPaths that specify what references to resolve.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="object" type="tns:ObjectType"/>
<xsd:element name="genericObject" substitutionGroup="tns:object" type="tns:GenericObjectType"/>
<xsd:element name="objectRef" type="tns:ObjectReferenceType"/>
<!-- Property-related types -->
<xsd:complexType name="PropertyReferenceType">
<xsd:annotation>
<xsd:documentation>
Property reference. Selects one or more properties in the
object instance documents. Subtypes of property reference
describe properties in the object instances. For example by
describing change to the property, available values
for the property, etc.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="c:property"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="property" type="tns:XPathType">
<xsd:annotation>
<xsd:documentation>
XPath expression selecting the property. It may select
multiple properties. But it must not be used to select
XML constructs inside a property, unless such property is
in itself an object.

The root of the path is assumed to be the element
of the top-most ObjectType. The path should be absolute,
starting with leading slash ("/"). If the leading slash is
not present, it should be assumed, but warning message
should be logged in such case.

Good
examples:
/fullName
/extension/foobar
/account/name
/account[@oid='1234']/name
/account/attribute/ldap:cn

Bad examples:
/extension/shoppingPreferences/tShirt (tShirt is not
property,
shoppingPreferences is)
/extension (extension is not
property, it is
rather container of properties)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="PropertyContainerReferenceType">
<xsd:annotation>
<xsd:documentation>
Property container reference. Selects exactly one XML element
that holds properties. Subtypes of property container
reference describe properties in the object instances, but they
use native reference to the specific property (e.g.
QName or XML elements using xsd:any type).
For example by describing change to the
property, available values for the property, etc.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" ref="c:path"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="path" type="tns:XPathType">
<xsd:annotation>
<xsd:documentation>
XPath expression selecting the property container.
It must select exactly one XML element. It must not be used to
select XML constructs inside a property, unless such property is
in itself an object.

The root of the path is assumed to be the element of the
top-most ObjectType. Path attribute may be ommited. In that
case it is assumed to be "/". The path should be absolute,
starting with leading slash ("/"). If the leading slash is
not present, it should be assumed, but warning message
should be logged in such case.

Good
examples:
/
/extension
/account[@oid='1234']/attributes

Bad examples:
/extension/shoppingPreferences this selects a property, not property container
/extension/shoppingPreferences/tShirt (tShirt is not property container)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="PropertyReferenceListType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="property" type="tns:PropertyReferenceType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PropertyAvailableValuesType">
<xsd:annotation>
<xsd:documentation>
Describe available or proposed values of an
attribute.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:PropertyReferenceType">
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other">
<xsd:annotation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
<xsd:attribute name="closed" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
True if property can contain only the values
listed
in the instance of this type.

False is
property can
contain
other values as well.
In such case the list of values listed in
the
instance of this type
should be considered only a
list of
suggested values.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertyAvailableValuesListType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="availableValues" type="tns:PropertyAvailableValuesType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="AccessType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="read">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="READ"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="update">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="UPDATE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="create">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="CREATE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="access" type="tns:AccessType"/>
<xsd:element default="true" name="ignore" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
Presence of this element signifies that the strcture that it contains should
be ignored. If this element is present in the attribute definition, the attribute
should be ignored. If it appears in the object class definition, the entire object
class should be ignored. "Ignored" means that the system should pretend that the
structure does not exist at all.

This element may also be used as XSD annotation in the dynamic schemas.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- Object changes -->
<xsd:complexType name="ObjectModificationType">
<xsd:annotation>
<xsd:documentation>
Describes a change of attributes of a specific
object.
All changes are expected to happen
atomically, but
there may be
exceptions. Please check with the
documentation of the interface
using this type for
more
details.

This should
probably go to some kind
of common schema.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="oid" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
OID of the object to modify.

Due to consistency
reasons this should rather be
an attribute. But it
is an
element
because of
OpenESB bug with attributes in message parts.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="1" ref="tns:propertyModification">
<xsd:annotation>
<xsd:documentation>
Describe a change to a single attribute of an
object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="objectModification" type="tns:ObjectModificationType"/>
<xsd:complexType name="PropertyModificationType">
<xsd:annotation>
<xsd:documentation>
Describe a change to a single attribute.
In this
case the path expression used in the "property"
attribute
must select
exactly one property.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:PropertyContainerReferenceType">
<xsd:sequence>
<xsd:element name="value">
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax">
<xsd:annotation>
<xsd:documentation>
The elements and values of changed
properties.
Multi-valued properties are expressed as
usual,
that
means by repeating the element containing
the property
value.
All the elements must have the same
QName and be
of the
same
type.
If more than one property is changed, the entire
PropertyChangeType element must
be repeated.
</xsd:documentation>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="PropertyModificationTypeType">
<xsd:annotation>
<xsd:documentation>
TODO

The "TypeType" in the name is correct. This is
the
type for "change type" therefore the name is
OK
although
it looks
strange.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="add">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="add"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="replace">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="replace"/>
</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:restriction>
</xsd:simpleType>
<xsd:complexType abstract="true" name="ObjectChangeType">
<xsd:annotation>
<xsd:documentation>
Describes a change of a specific object.
This is abstract type. It cannot be used directly.
Use the subtypes instead.
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="ObjectChangeAdditionType">
<xsd:annotation>
<xsd:documentation>
Describes object addition (creation, operation
"add").
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectChangeType">
<xsd:sequence>
<xsd:element name="object" type="tns:ObjectType"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ObjectChangeModificationType">
<xsd:annotation>
<xsd:documentation>
Describes object modification (operation
"modify").
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectChangeType">
<xsd:sequence>
<xsd:element name="objectModification" type="tns:ObjectModificationType"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ObjectChangeDeletionType">
<xsd:annotation>
<xsd:documentation>
Describes object deletion (operation "delete").
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ObjectChangeType">
<xsd:sequence>
<xsd:element name="oid" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
OID of the deleted object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:annotation>
<xsd:documentation>
Describes a change of a specific resource object
together with
definitions of the source.

Note: This
is quite
an
atrificial structure. In fact it should
be splint into WSDL message
parts instead one XSD type. But the
ObjectChangeType
is
polymorphic
and OpenESB has problems with such types if placed
directly into
message parts.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="objectChange" type="tns:ObjectChangeType">
<xsd:annotation>
<xsd:documentation>
Description of changes that happened to an
resource
object shadow.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sourceChannel" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Definition of source channel (e.g.
synchronization,
reconciliation, discovery, ...)
Should in fact
be
QName.
But OpenESB has problems with
QNames.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="shadow" type="tns:ResourceObjectShadowType">
<xsd:annotation>
<xsd:documentation>
Resource object shadow as seen by the component
before the
change, if possible. This object is
mandatory.

In some
cases (e.g. addition) the object may not exist
before the change.
In such a case the caller is
reponsible
to create
such object in the
repository before calling
this operation (see the note before).

Even thought
this object is mandatory, it
may not be
complete. The
content of this object depends on how the
change was detected,
configuration of a calling component
and so on. On the very
minimum, the shadow object must
contain:
* OID
*
Identifiers necessary
to locate the associated resource
object on the resource.

Note: This
is actually the shadow
object that was stored
in the repository at
the time the change was
detected
(or created at that moment).

Note:
This
was orginally defined as an object before the
change and it was
option. Such
definition does not allow
some
operations, such as
create a user and link account
(because the objectChange does not
have OID
and therefore
cannot
be linked to).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="resource" type="tns:ResourceType">
<xsd:annotation>
<xsd:documentation>
Resource that was the origin of the change.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CachingMetadata">
<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 relativelly rough
granularity and the time in distributed system is relative anyway, it is not really
useful for anything else.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="serialNumber" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
A string that uniquely represents the version of the data that was retrieved.
The objects of the same type and origin with the same serial number are assumed to
be the same.
There is no requirement for this to be identifier - the serialNumber cannot be used
to retrieve the object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="cachingMetadata" type="tns:CachingMetadata"/>
<xsd:complexType name="ProtectedStringType">
<xsd:annotation>
<xsd:documentation>
This is a general-purpose type to store sensitive values that should be encrypted in
the repository. It is using starndard XML Encryption schema.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<!-- <xsd:element name="alias" type="xsd:string" minOccurs="0" /> -->
<xsd:element ref="xenc:EncryptedData">
<xsd:annotation>
<xsd:documentation>
Use of XML Encryption standard EncryptionData element.
</xsd:documentation>
<!-- <xsd:appinfo>
<jaxb:dom />
</xsd:appinfo>
-->
</xsd:annotation>
</xsd:element>
<xsd:element name="clearValue" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Clear text value of the protedted data. It is useful for imports and tests.
This element should never appear in repository or any other long-term storage.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="ProtectedByteArrayType">
<xsd:annotation>
<xsd:documentation>
ONLY COPIED AND PASTED FROM ProtectedStringType, please update if needed later
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<!-- <xsd:element name="alias" type="xsd:string" minOccurs="0" /> -->
<xsd:element ref="xenc:EncryptedData">
<xsd:annotation>
<xsd:documentation>
Use of XML Encryption standard EncryptionData element.
</xsd:documentation>
<!-- <xsd:appinfo>
<jaxb:dom />
</xsd:appinfo>
-->
</xsd:annotation>
</xsd:element>
<xsd:element name="clearValue" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Clear text value of the protedted data. It is useful for imports and tests.
This element should never appear in repository or any other long-term storage.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="EmptyType">
<xsd:annotation>
<xsd:documentation>
Type that contains nothing.
Used in WSDL messages that do not return anything to silence the warnings.
</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<!-- Filters & queries -->
<xsd:complexType name="FilterType">
<xsd:annotation>
<xsd:appinfo>
<jaxb:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:complexType>
<xsd:element name="query" type="tns:QueryType"/>
<xsd:complexType name="QueryType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element ref="tns:filter"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="filter" type="tns:FilterType"/>
<xsd:complexType name="UriFilterType">
<xsd:complexContent>
<xsd:extension base="tns:FilterType">
<xsd:attribute name="uri" type="xsd:anyURI"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="type" substitutionGroup="tns:filter" type="tns:UriFilterType"/>
<xsd:complexType name="PropertyComplexValueFilterType">
<xsd:complexContent>
<xsd:extension base="tns:FilterType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:path">
<xsd:annotation>
<xsd:documentation>
XPath to the containing XML element for the
queried propoerty. If not specified, defatults
to
"." (which
is
also the most usual value).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:choice>
<xsd:element name="value">
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax">
<xsd:annotation>
<xsd:documentation>
The elements and values of queried
properties.
Multi-valued properties are not allowed
here.
Use
"and"
or "or" clauses if needed.
</xsd:documentation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="valueExpression" type="tns:ExpressionType">
<xsd:annotation>
<xsd:documentation>
The expression that can be used to
dynamically evaluate the value. It may or
may not be used,
depending
on where is this
type used.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertySimpleValueFilterType">
<xsd:complexContent>
<xsd:extension base="tns:FilterType">
<xsd:sequence>
<xsd:element ref="c:property">
<xsd:annotation>
<xsd:documentation>
XPath to the property being queried.
It is
mandatory, as there is no reasonable
default as in
the case of
path.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:choice>
<xsd:element name="value" type="xsd:anyType">
<xsd:annotation>
<xsd:documentation>
The elements and values of queried
properties.
Multi-valued properties are not allowed here.
Use
"and" or
"or" clauses if needed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="valueExpression" type="tns:ExpressionType">
<xsd:annotation>
<xsd:documentation>
The expression that can be used to
dynamically evaluate the value. It may or
may not be used,
depending
on where is this
type used.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertyNoValueFilterType">
<xsd:complexContent>
<xsd:extension base="tns:FilterType">
<xsd:sequence>
<xsd:element ref="c:property"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="equal" substitutionGroup="tns:filter" type="tns:PropertyComplexValueFilterType"/>
<xsd:element name="greaterOrEqual" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/>
<xsd:element name="lessOrEqual" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/>
<!-- Following element should be constrained a bit more, because their value
is always string respectively. But we don't know how to constrain it now
and we do not have the time to find out. Therefore it should be OK for now.
-->
<xsd:element name="substring" substitutionGroup="tns:filter" type="tns:PropertySimpleValueFilterType"/>
<xsd:element name="present" substitutionGroup="tns:filter" type="tns:PropertyNoValueFilterType"/>
<xsd:element name="true" substitutionGroup="tns:filter" type="tns:PropertyNoValueFilterType"/>
<xsd:complexType abstract="true" name="LogicalOperatorFilterType">
<xsd:complexContent>
<xsd:extension base="tns:FilterType"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="UnaryLogicalOperatorFilterType">
<xsd:complexContent>
<xsd:extension base="tns:LogicalOperatorFilterType">
<xsd:sequence>
<xsd:element ref="tns:filter"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="NAryLogicalOperatorFilterType">
<xsd:complexContent>
<xsd:extension base="tns:LogicalOperatorFilterType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="1" ref="tns:filter"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="and" substitutionGroup="tns:filter" type="tns:NAryLogicalOperatorFilterType"/>
<xsd:element name="or" substitutionGroup="tns:filter" type="tns:NAryLogicalOperatorFilterType"/>
<xsd:element name="not" substitutionGroup="tns:filter" type="tns:UnaryLogicalOperatorFilterType"/>
<xsd:complexType name="PagingType">
<xsd:annotation>
<xsd:documentation>
Parameters limiting the number of returned
entries, offset, etc.
Used in the web service operations
such as
list
or search
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" name="orderBy" type="c:PropertyReferenceType">
<xsd:annotation>
<xsd:documentation>
Property by which the results should be sorted.
Reference to a property (XPath).
Just one property
for now.
Maybe we
will change this to a
list later.
If not specified, the ordering is
arbitrary.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="ascending" minOccurs="0" name="orderDirection" type="c:OrderDirectionType">
<xsd:annotation>
<xsd:documentation>
Direction of ordering (ascending or descending).
Only
valid if "orderBy" element is specified.
If
not
specified, the
ordering order is ascending.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="0" minOccurs="0" name="offset" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
The index of the first returned entry, starting
with zero.
Therefore if 0 is specified, the
resulting list
will
start
with first entry. If 1 is specified, the resulting set will
start with second entry.
If not
specified, value of zero
(0) is
assumed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="2147483647" minOccurs="0" name="maxSize" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
The maximum number of entries returned. The
operation may
return specified number of number of
entries or
less.
If not specified, unlimited maximum size is assumed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="OrderDirectionType">
<xsd:annotation>
<xsd:documentation>
Type of an operation (change). It defines
operations to change
object, it is not limited to object
modifications.
TODO: How to handle renames?
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ascending">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="ASCENDING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="descending">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="DESCENDING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ImportOptionsType">
<xsd:annotation>
<xsd:documentation>
The options for import tasks. It specifies optional settings for import such as "overwrite" and "stop on error".
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" name="overwrite" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to a true value it will cause that objects that are already in the repository will be
overwritten by the imported objects.
It may not be applicable to all import types. E.g. it makes no sense for import from resource, as this
is not storing objects in the repository directly.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="keepOid" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to a true value it will cause that objects that overwritten objects will reuse the same OID
as previous objects.
May be potentially dangerous. USE WITH CARE.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="stopAfterErrors" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
Number of errors that will cause import to stop. If set to one the import will stop on first error.
If set to zero or negative value the import will not stop on any error.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="true" minOccurs="0" name="summarizeSucceses" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the successfuly imported items will be summarized in the result.
WARNING: setting this to false may result in a very large result structure and may cause overflow of
the system memory.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="false" minOccurs="0" name="summarizeErrors" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="false" minOccurs="0" name="referentialIntegrity" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="true" minOccurs="0" name="validateStaticSchema" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="true" minOccurs="0" name="validateDynamicSchema" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="true" minOccurs="0" name="encryptProtectedValues" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="false" minOccurs="0" name="fetchResourceSchema" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If set to true the importe errors will be summarized in the result.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="TaskType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ExtensibleObjectType">
<xsd:sequence>
<xsd:element name="executionStatus" type="tns:TaskExecutionStatusType">
<xsd:annotation>
<xsd:documentation>
Execution status provides information about the task overall high-level execution state. It tells
whether the task is running/runnable, waits for something or is done.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
Exclusivity status tells about task "locking" to a particular node.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="node" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Identifier of the node that has claimed this task. Should be only present if excelusivity status is
"claimed".
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="claimExpirationTimestamp" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
Expiration of the claim. If a "claimed" task is found after the moment specified in this attribute,
the task is no longer considered claimed.
Should be only present if excelusivity status is "claimed".
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="handlerUri" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Handler URI indirectly specifies which class is responsible to handle the task. The handler will
execute reaction to a task lifecycle events such as executing the task, task heartbeat, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="result" type="tns:OperationResultType">
<xsd:annotation>
<xsd:documentation>
OperationResult that is used to compile task results (parent result).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="objectRef" type="tns:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Object that the task is associated with. Tasks may be associated with a particular objects. For
example a "import from resource" task is associated with the resource definition object that it imports from. Similarly
for synchronization and reconciliation tasks (cycles).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="lastRunStartTimestamp" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="lastRunFinishTimestamp" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="progress" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>
Relative metric of task progress.
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="recurrence" type="tns:TaskRecurrenceType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="binding" type="tns:TaskBindingType">
<xsd:annotation>
<xsd:documentation>
TODO loose - tight
If not present the nodes may decide independently.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="schedule" type="tns:ScheduleType">
<xsd:annotation>
<xsd:documentation>
Task schedule. Specifies when and how often to execute the task.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="task" substitutionGroup="c:object" type="tns:TaskType"/>
<xsd:simpleType name="TaskExecutionStatusType">
<xsd:annotation>
<xsd:documentation>
Execution status provides information about the task overall high-level execution state. It tells
whether the task is running/runnable, waits for something or is done.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="running">
<xsd:annotation>
<xsd:documentation>
The task is running or is ready to be executed. This state implies that the task is being actively executed by IDM nodes, e.g. there is a thread on one of the IDM nodes that executes the task or the system needs to allocate such thread.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="RUNNING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="waiting">
<xsd:annotation>
<xsd:documentation>
The IDM system is waiting while the task is being executed on an external node (e.g. external workflow engine) or is waiting for some kind of external signal (e.g. approval in internal workflow). The task may be running on external node or blocked on IDM node. One way or another, there is no point in allocating a thread to run this task. Other task properties provide more information about the actual "business" state of the task.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="WAITING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="closed">
<xsd:annotation>
<xsd:documentation>
The task is done. No other changes or progress will happen. The task in this state is considered immutable and the only things that can happen to it is a delete by a cleanup code.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="CLOSED"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TaskExclusivityStatusType">
<xsd:annotation>
<xsd:documentation>
Exclusivity status tells about task "locking" to a particular node.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="claimed">
<xsd:annotation>
<xsd:documentation>
The tasks is being held by one of the IDM nodes. The node is either executing the task or making some kind of "exclusive" operation on the task. Only one node may "claim" a task. Claimed tasks has an allocated *thread* that is used for task execution.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="CLAIMED"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="released">
<xsd:annotation>
<xsd:documentation>
The task is free for all nodes to participate. Any node may try to "claim" the task to execute it or make another step in the task lifecycle. Released task is not being executed by an IDM node and therefore does not have an allocated thread.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="RELEASED"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TaskRecurrenceType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="single">
<xsd:annotation>
<xsd:documentation>
TODO
The task is executed only once, at the first moment that the scedule specifies. If that moment is in
the past, the task will be executed as soon as any execution environment (node) is available.
Once the task is finished, it will not be executed again.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="SINGLE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="recurring">
<xsd:annotation>
<xsd:documentation>
TODO
The task is executed as many times as the schedule specifies.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="RECURRING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="TaskBindingType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="loose">
<xsd:annotation>
<xsd:documentation>
The task is claimed (exclusivelly locked) to a specific node only if it is executing.

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

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

This is efficient for tasks that take long time to execute and the execution mostly waits (e.g. approvals)
or for tasks which have long interval between executions (e.g. reconciliation).
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="LOOSE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="tight">
<xsd:annotation>
<xsd:documentation>
Task is claimed (exclusivelly locked) to a specific node for a long time. It may be claimed until the
executing node is up and running.

A theread may be running and allocated for the task all the time. The thread may to to sleep as needed,
but during that time the task remains claimed.

The node that started to execute this task will be preferred for subsequent executions.

This is efficient for recurring tasks executed in short intervals, such as live synchronization.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="TIGHT"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ScheduleType">
<xsd:annotation>
<xsd:documentation>
Task schedule. Specifies when and how often something should happen.
UNSTABLE. This type will most likely change. A lot.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" name="interval" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>
Interval in seconds between task invocations.
UNSTABLE. This element will most likely change. A lot.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!-- Following types SHOULD NOT be here. They should be in the respository
WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing
the elements to this namespace works around that bug. This should be moved
to the WSDL once the bug is resolved.
-->
<xsd:complexType name="ObjectListType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="object" type="tns:ObjectType"/>
</xsd:sequence>
<xsd:attribute name="count" type="xsd:int"/>
</xsd:complexType>
<!-- ################################## -->
<!-- ## Identity Schema Layer ## -->
<!-- ################################## -->
<!-- The following clauses belong to the identity schema layer. This schema
defines the "identity model", the basic objects for midPoint system that
are common for most IDM deployments. It is supposed to be heavily used by
midPoint low-level components and also by business logic.
See https://wiki.evolveum.com/display/midPoint/Identity+Schema
-->
<xsd:complexType name="UserType">
<xsd:annotation>
<xsd:documentation>
User object type. Represents physical user of the system.

TODO: More details

Inspired by FOAF, but still
quite LDAP-ish.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="c:ExtensibleObjectType">
<xsd:sequence>
<xsd:element name="fullName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Full name of the user with all the
decorations,
middle name initials, honorific title and any
other
structure that is usual in the cultural
environment that the
system operates in. This
element is intended to
be displayed to
a
common
user of the system.

Examples: cpt. Jack Sparrow,
William
"Bootstrap" Turner,
James W.
Random, PhD.,
Chuck Norris
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="givenName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Given name of the user. It is usually the
first
name of the user, but the order of names may
differ in
various cultural environments. This
element will always contain
the name that was
given to the user at
birth or was chosen
by the
user.

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

Examples: Sparrow, Norris
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="additionalNames" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Middle name, nick name or any other names of a
person.

Examples: "Bootstrap", Walker

Multi-valued
property.
Please note that the order
of additional names may not be
preserved. If
the order is
important, the use a single
value with
all the names concatenated as
appropriate.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="honorificPrefix" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Honorific titles that go before the name.

Examples: cpt., Ing., Sir

This property is
single-valued.
If
more
than one title is applicable, they have to be represented in
a
single string (concatenated)
form in the correct order.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="honorificSuffix" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Honorific titles that go after the name.

Examples: PhD., KBE

This property is single-valued.
If
more than
one title is applicable, they have to be represented in
a single
string (concatenated) form in the
correct order.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="eMailAddress" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
E-Mail address of the user. This is the
address
supposed to be used for communication with the
user. E.g.
IDM system may send notifications
to the e-mail address. It is
NOT supposed to be
full-featured e-mail
address data
structure
e.g.
for the purpose of comlex address-book application.

This is
mult-valued property. In
case more than
one e-mail
address is
specified, the same message
should be sent to all the addresses.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="telephoneNumber" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Primary telephone number of the user.

This is
multi-valued attribute. In case more than
one
telephone
number is
specified, all telephone
numbers are considered equivalent.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="employeeNumber" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Unique, business-oriented identifier of the
employee.
Typically used as correlation identifier
and for
auditing purposes. Should be immutable, but the
specefic
properties and usage are deployment-specific.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="employeeType" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Employee type specification such as internal
employee,
external or partner. The specific values
are
deployment-specific.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="organizationalUnit" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Name or (preferrably) immutable identifier of
organizational unit that the user belongs to.
The
format is
deployment-specific.

This is multi-valued property to allow
membership
of a user to several
organizational units.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="locality" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Primary locality of the user, the place where
the user usually works, the contry, city or
building that
he
belongs to. The specific meaning
and form of this property is
deployment-specific.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="credentials" type="tns:CredentialsType">
<xsd:annotation>
<xsd:documentation>
The set of user's credentials (such as passwords).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="activation" type="tns:ActivationType">
<xsd:annotation>
<xsd:documentation>
User's activation. e.g. enable/disable status, start and end dates, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="assignment" type="tns:AssignmentType">
<xsd:annotation>
<xsd:documentation>
Set of user's assignments.
Represents objects (such as roles) or accounts directly assigned to
a user.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- xsd:choice minOccurs="0" maxOccurs="unbounded" -->
<xsd:element maxOccurs="unbounded" minOccurs="0" name="account" type="tns:AccountShadowType">
<xsd:annotation>
<xsd:documentation>
Set of user's accounts. This is the set of
accounts that belongs to the user in a sense
that
these
accounts
represents the user (the
same physical person, they are
analogous).
This element contains full
AccountType XML
elements.
This version will
probably be used in workflows and
business
logic.

If this attribute is
present in the User object,
the
accountRef attribute for the same account
OID must not be
present.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="accountRef" type="c:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Set of user's accounts. This is the set of
accounts that belongs to the user in a sense
that
these
accounts
represents the user (the
same physical person, they are
analogous).
This element contains a set of
pointers to
Account
objects (by OID) this version
will be used in repository (for
storage).

If this attribute is
present in the User
object,
the
account attribute for the same account
OID must not be present.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- /xsd:choice -->
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="credentials" type="tns:CredentialsType"/>
<xsd:complexType name="CredentialsType">
<xsd:annotation>
<xsd:documentation>
This is a container type for various credentials types: passwords, public keys, one-time password
scheme identifiers, etc. However, we expect that password will be the most widely used credential
type and that's actually also the only supported type.

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

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

TODO: support for "old password", e.g. some resource need it to change password.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="password">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="protectedString" type="tns:ProtectedStringType"/>
<xsd:element minOccurs="0" name="failedLogins" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>
The number of failed logins. It should be
increased after every unsuccessful use of
the
credential. It
may
be reset after
successful login or a time-out or may not.
It
depends on the policy setting.
If
not present, value of zero
(0)
is assumed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="lastFailedLoginTimestamp" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
The date and time of last failed login
attempt.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- More credentail types may be here, such as OTP seeds, X.509 credentials,
etc.
-->
<xsd:element default="false" minOccurs="0" name="allowedIdmGuiAccess" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If true, the user will have access to the IDM
GUI. The
access will provide access to all
functions,
therefore
this
is kind of "superuser" flag.

This is a temporary solution until we
implement
fully-featured
authorization
mechanism.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AssignmentType">
<xsd:annotation>
<xsd:documentation>
Generic assignments of one object to another object.
This will usually be assignment of a role to a user, assignment of an
organizational unit, team or whatever. It may also be used to assing
role to another role, creating a role hierarchy.

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

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

TODO: constraints
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice>
<xsd:element name="target" type="tns:ObjectType">
<xsd:annotation>
<xsd:documentation>
TODO: target
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="targetRef" type="c:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
TODO: target ref
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:element minOccurs="0" name="activation" type="tns:ActivationType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ActivationType">
<xsd:annotation>
<xsd:documentation>
Type that defines activation properties. Determines whether something is active
(and working) or inactive (e.g. disabled).

It applies to several object types. It may apply to user, account, assignement, etc.
The data in this type define if the described concept is active, from when it is active
and until when. The "active" means that it works. If something is not active, it should
not work or not cause any effect. E.g. inactive user should not be able to log in or run
any tasks, the non-active role should not be assigned and if assigned it should not be
taken into account when computing the accounts.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" name="enabled" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
Flag that indicates if the described concept is active.

true =&gt; active, enabled
flase =&gt; inactive, disabled

This defines the "administrative state", i.e. the administrator's decision.
If set, this flag overrides any other constraints in the activation type.
E.g. if this is set to true and the object is not yet valid (according to
validFrom below), the user should be considered active. If set to false the
user should be considered inactive regardless of other settings.

Therefore this flag does NOT define an actual state of
the object. It is a kind of "manual override".

If this flag is not present then the other constraints in the activation type
should be considered.

If not present and there are no other constraints in the activation type or if there
is no activation type at all then the values is assumed to be true, i.e. that the
described concept is active (enabled).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="validFrom" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
A date from which is should the object be considered active.
Not applied if the "enabled" flag is set to any value.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="validTo" type="xsd:dateTime">
<xsd:annotation>
<xsd:documentation>
A date to which is should the object be considered active.
Not applied if the "enabled" flag is set to any value.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<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}} will
most likely
provide a combination of several functions (e.g.
both
provisioning
and authoritative data for some attributes).
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="c:ExtensibleObjectType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="connector" type="tns:ConnectorType">
<xsd:annotation>
<xsd:documentation>
"Composite" version of the ConnectorType
reference. See below for more details.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" 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
connecotor or
connectorRef MUST be
present in the
resource
object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="namespace" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Resource private namespace. This is the
namespace
that is private for a specific resource
INSTANCE.
It may
be used by the connector e.g. to generate
instance-specific
resource schema or for other
purposes. It should be set by the
system
administrator to a unique value for each resource
instance. The
configuration tools (e.g. admin GUI)
should provide
a
reasonable default value.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element ref="tns:configuration"/>
<xsd:element minOccurs="0" ref="tns:schema">
<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 will be
only available at run-time
and
can be diffrent for every
resource
instance,
even for resource instances of the same type.
It is
supposed to be
dynamically interpreted in
run-time.

Schema defines
data types (XSD types), but it
does NOT define how these types
are handled.
E.g. it defines attributes and
object class for
inetOrgPerson, it defines that inetOrgPerson
extends
organizationalPerson and persona, that
cn is
multi-valued string
attributed of Person,
etc. But it does NOT define
that
inetOrgPerson
object class should be used as
account and that
modifyTimestamp attribute is read-only. Such
additional details
are specified in
schemaHandling element
defined below.

Resource
schema is read-only. Changing
resource
schema is
not supported.

TODO: annotations in the schema
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" ref="tns:schemaHandling"/>
<xsd:element minOccurs="0" name="nativeCapabilities" type="tns:CapabilitiesType">
<xsd:annotation>
<xsd:documentation>
The capabilities nativelly supported by the connector without any simulation or any
other workaround. This may not be stored in the repository, as this can be fetched
any time from the connector.
If this element is not present then the connector provides no capabilities.
The value of this element indicates what the connector can do.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element 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 simulated capabilities.
If this element is not present at all, the value of nativeCapabilities element is assumed.
The value of this element is not generated, it should be set by the administrator.
The value of this element indicates administrator decisions what connector capabilities
to use, what capabilities to simulate and how to simulate them.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" ref="tns:scripts"/>
<xsd:element minOccurs="0" ref="tns:synchronization"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="schema" type="tns:XmlSchemaType"/>
<xsd:complexType name="XmlSchemaType">
<xsd:annotation>
<xsd:documentation>
This element contains the XSD-formatted definition
of schema.

The schema available in this
definition is
expeceted to
comply
to the usual midPoint schema structure (properties,
property
containers), although it
should not contain
objects (persistent
objects identified by OID).

Note: This schema is considered to be
available
only in run-time.
Therefore
code-generation methods such as
JAXB cannot be
applied
here.

Note: xsd:any is here, but
maybe a stricter
type would be
preferable.
However xsd:any seems to be a common
practice
(e.g. SPML, WSDL).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" ref="tns:cachingMetadata"/>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="strict">
<xsd:annotation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="schemaHandling" type="tns:SchemaHandlingType"/>
<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.

TODO: more details

This element belongs to ResourceType
and should
not be used elsewhere.
This is a top-level
element to make
the implementation
(JAXB marshall/unmarshall) easier.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="accountType">
<xsd:annotation>
<xsd:documentation>
Defiens a type from the resource schema (object
class)
that can be used for creating accounts.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:name">
<xsd:annotation>
<xsd:documentation>
Human readable name for the account object
class.
This name may be displayd in tools and GUIs
to
provide
more
pleasant user experience, as the
XML data type names may look
quite frightening.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" ref="tns:description"/>
<xsd:element name="objectClass" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
XSD type from the resource schema (Object
Class)
that should be used for accounts on this
resource.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:AttributeDescriptionType">
<xsd:annotation>
<xsd:documentation>
Specification of handling of an account
attribute.
This overrides annotations in the resource
schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="credentials">
<xsd:annotation>
<xsd:documentation>
Definition of credentials handling for this
account type.
EXPERIMENTAL. Will most likely change
later.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element default="false" minOccurs="0" name="outboundPassword" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
If true then the passowrd of the
resource
account will be automatically
changed when user
password is
changed.
EXPERIMENTAL. Will most likely change later.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="randomPasswordLength" type="xsd:integer">
<xsd:annotation>
<xsd:documentation>
If set to any value, the password will be
randomly generated when a new account
is created
and the
password cannot be
determined otherwise.
If set to zero, empty
password will be
generated. If not set
at all, the
password
attribute will not be present.
If a password can be
determined otherwise
(e.g. from User
object), the random
generation
will not be applied.
EXPERIMENTAL. Will most likely
change later.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute default="user" name="id" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Short string identifier (name) of the account
type
E.g. user, tester, guest, ...
It is supposed
to be used
in
references to this
section of XML defining account type.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute default="false" name="default" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
Specifies whether this account type is the
default
account type for the resource. Only one
account
type
can be
default. Setting this flag for more
than one type is an error.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="entitlementType">
<xsd:annotation>
<xsd:documentation>
Type of entitlements such as groups, roles
entitlements, organizatrions, etc.

Not yet fully
figured out.
Please
ignore for now.

TODO
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:name">
<xsd:annotation>
<xsd:documentation>
Human readable name for
the object class.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="objectClass" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="assignmentProperty">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="ref" type="xsd:QName"/>
<xsd:attribute default="1" name="minOccurs" type="xsd:string" use="optional"/>
<xsd:attribute default="1" name="maxOccurs" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CapabilitiesType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="scripts" type="tns:ScriptsType"/>
<xsd:complexType name="ScriptsType">
<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:ScriptType">
<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:complexType name="ScriptType">
<xsd:annotation>
<xsd:documentation>
Specifies how and when a script is executed during
provisioning.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="operation" type="tns:OperationTypeType">
<xsd:annotation>
<xsd:documentation>
Defines a set of operations for which the script
should
be executed.
If more than one operation is
specified, the same
script should be executed for each of them.
If no operation is
specified, the script will not be
executed
(this is meant as poor
man's disable feature)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="order" type="tns:ScriptOrderType">
<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 default="resource" minOccurs="0" name="host" type="tns:ScriptHostType">
<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:ScriptArgumentType">
<xsd:annotation>
<xsd:documentation>
Script aguments. 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:sequence>
</xsd:complexType>
<xsd:simpleType name="OperationTypeType">
<xsd:annotation>
<xsd:documentation>
Type of an operation (change). It defines
operations to change
object, it is not limited to object
modifications.
TODO: How to handle renames?
</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:restriction>
</xsd:simpleType>
<xsd:simpleType name="ScriptOrderType">
<xsd:annotation>
<xsd:documentation>
An enumeration that defines when the script will
be excuted.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before">
<xsd:annotation>
<xsd:documentation>
The script will be executed before the
provisioning
operation.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="BEFORE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="after">
<xsd:annotation>
<xsd:documentation>
The script will be executed after the
provisioning
operation.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="AFTER"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ScriptHostType">
<xsd:annotation>
<xsd:documentation>
An enumeration that defines where the script will
be excuted.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="connector">
<xsd:annotation>
<xsd:documentation>
The script will be executed on "connector", it
means
it will be executed on the same host as the
connector
is
running (which is usually IDM system).
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="CONNECTOR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="resource">
<xsd:annotation>
<xsd:documentation>
The script will be executed on "resource", it
means
it will be executed on the target sytem.
Please refer
to the
connector documentation for more details, e.g.
in case of
multi-host resources.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="RESOURCE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ScriptArgumentType">
<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:ValueConstructionType">
<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:element name="configuration">
<xsd:annotation>
<xsd:documentation>
Resource configuration (hostname, port, ...).
Specific for each resource type.
TODO

This element
belongs to
ResourceType and should
not be used elsewhere.
This is a top-level
element to make the implementation
(JAXB
marshall/unmarshall)
easier.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="AttributeDescriptionType">
<xsd:annotation>
<xsd:documentation>
Description of the attribute handling, 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.

This is supposed to be
used only in
schemaHandling.
It is not a reusable
data structure
(composition).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:name">
<xsd:annotation>
<xsd:documentation>
Human readable name for the account attribute.
This name may be displayd in tools and GUIs to
provide more
pleasant user experience, as the
native attribute names may look
quite frightening
(especially in
LDAP).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element minOccurs="0" ref="tns:ignore"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="c:access">
<xsd:annotation>
<xsd:documentation>
Access to the attribute as defined
by the system
administrator or deployer.
This can constrain the
access
defined by
resource schema annotations.
Specifying broader access that the
resource
connector can handle is an
error.

If no
access is specified,
it defaults to
read-write.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="outbound" type="tns:ValueConstructionType">
<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.

This may be a static value or an expression.

In case
an expression is used,
the expression
variables
should be as
follows:
$user - the user to whom the account belongs
$account - the
account to
be changed

Motivation: This is
"value construction" type,
it is
using similar format that is used eleswhere in the
system
(e.g. in roles) and therefore a
common
expression processor can be
used to process all of
that. E.g. a single
processor may take into a
consideration both
schema handling and dynamic
attributes set by
roles.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:ValueAssignmentType">
<xsd:annotation>
<xsd:documentation>
Defines how the attribute values are used
(assigned) in
case of information flow from resource to
IDM, e.g.
in
case of synchronization, reconciliation or discovery.

In case a
source expression is used, the
expression
variables should
be as
follows:
$user - the user to whom the account belongs
$account - the
account that
has been changed (after the change)

Explanation: This
is not a "value construction" as it
is not constructing a new
attribute value. It is rather
using attribute
value that was set be
someone else.
A simpler way how to express the
assignement is needed
here, especially a simple way how
to express assignment
target.
Some rules may use that
information and we
definitelly need that to
generate correct relative
change descriptions.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ref" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
Name of the property attribute (XSD element) that
this
definition describes. It must point to the
first-level
attribute
in the resource schema that belongs to an
object class that is being
described here.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:complexType name="ValueConstructionType">
<xsd:annotation>
<xsd:documentation>
Defines how a value of a property (or attribute)
should be
constructed. The value may be static or
constructed as an
result of evaluating an expression.

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

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

Motivation: We need to construct attribute or
property values
on
many places in midPoint. E.g. we need that in
roles to generate
dynamic account attribute values,
we need that to
define
"templates" for identifiers and default values for attributes
when creating a new account. We
also need that to specify
values
when
creating a new user (user templates).
Having the same data structure
for all of
these cases may
simplify the code, as it all
can be handled
by a generic library
reused in many places throught the
system.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:extension"/>
<xsd:choice>
<xsd:element name="value" nillable="true">
<xsd:annotation>
<xsd:documentation>
Static value for the attribute or property.

Please note that this is nillable and therefore it
may be
explicitly set to "nil" value. Doing this
means that empty set of
values should be constructed.
E.g. setting
this to "nil"
and also
setting
"authoritative" flag may enforce removal of all
attribute
values (if used properly).
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax">
<xsd:annotation>
<xsd:documentation>
Static attribute values.
The values in this
element should be
assigned to the account as-is.

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

Only one
attribute may be specified
here, although it may have multiple
values. Multi-valued
attributes are
expressed by
repeating the
same XML
element multiple times.
Hence all the XML elements that
match
this xsd:any must have the same
element
names (may have
different values of course).
</xsd:documentation>
<xsd:appinfo>
<jaxb:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="variable" type="tns:VariableDefinitionType">
<xsd:annotation>
<xsd:documentation>
Definition of additional variables that should
be
present during evaluation of the expression.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="valueExpression" type="tns:ExpressionType">
<xsd:annotation>
<xsd:documentation>
Expression to dynamically generate the value.
See ExpressionType for more details.

The
expression will
most
likely use variables. The
names and content of the variables
depends on the
specific usage of
this type. Please refer to
the
containing or deriving type documentation for more
details.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="dependency" type="c:XPathType">
<xsd:annotation>
<xsd:documentation>
Defines the XPath of a property on which the
expression
depends. If there are other expressions
to be
evaluated
that set such value, such expressions will
be evaluated before
this expression.

This may or may not
be needed. If
the
dependencies
can be derived from the expression implicitly, the
dependency element may be
omitted. It may also be
omitted if the
order of expression execution is not
significant. In case the
user want to
make sure that
expressions will be
executed in a
crertain order, he
should include dependency elements.

Due to the
JAXB "feature" this does not work for now.
Please do not use it.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:choice>
<xsd:element minOccurs="0" ref="c:condition">
<xsd:annotation>
<xsd:documentation>
The value will only be valid if the condition is
evaluated to true. If the condition is false,
the value
definition
should not be applied at all (exactly as if
there is no
definition).
If there is no condition,
it is assumed to be
true.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="tns:valueFilter">
<xsd:annotation>
<xsd:documentation>
List of filters that will be applied to the
value after
it was constructed. The filters will get
applied as
the
very last step, after the expression had run.

The filters will be
executed in chain in the order as
specified here.

The
filters are
supposed to "mess up" or transcode
the value from XML standards to
any format
suitable for
native storage (e.g. on
resource).
(but see
the note in ValueFilterType documentation)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute default="false" name="exclusive" type="xsd:boolean" use="optional">
<xsd:annotation>
<xsd:documentation>
The value construction cannot be combined with
other
value constructions.

If there are other
non-exclusive
value
constructions to be
applied to the same propert or attribute, such
constructions
should be
ignored. If there are other
exclusive value
constructions, the error should be produced and the values
should
not be
changed.

TODO: not yet finished
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute default="false" name="default" type="xsd:boolean" use="optional">
<xsd:annotation>
<xsd:documentation>
This value construction should only be applied if the
property or attribute does not have a value.

This flag makes the value construction conditional. Please
note that now there is no way how to get attribute value and
set a new value atomically. Therefore also the "default" flag
cannot be executed atomically and a risk of inconsistency is
still there. The implementation should minimize that risk by
making the "window of risk" as shortas possible and utilize
any additional consistency guarantees if possible.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute default="true" name="authoritative" type="xsd:boolean" use="optional">
<xsd:annotation>
<xsd:documentation>
The value provided by this construction element
is authoritative.

It means that this value
construction is
supposed
to both
add the value and remove it.

TODO: not yet finished
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute default="false" name="clear" type="xsd:boolean" use="optional">
<xsd:annotation>
<xsd:documentation>
The value construction is supposed to be executed
on the
"clear" value for a attribute or
property.

If there
are any
existing values on the property or attribute
before the execution of
all applicable value
construction
definitions, such
values should be
cleared.

TODO: not yet finished
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:complexType name="PropertyConstructionType">
<xsd:annotation>
<xsd:documentation>
Definition of construction of a (general)
property. The property
may be constructed as a static
value of as a
result of an
expression (See ValueConstructionType documentation).
This can be used e.g. to constuct a
value for user's
fullName
in User
Template or also on other places in the future.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:PropertyReferenceType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element name="valueConstruction" type="tns:ValueConstructionType">
<xsd:annotation>
<xsd:documentation>
Reference (QName) of the property which value
is
defined by this type.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ValueAssignmentType">
<xsd:annotation>
<xsd:documentation>
Defines an assignment of value from one place (or
expression) to
another place.
This is supposed to
be a
general-purpose
construct.
TODO: merging options

This type is marked with jaxb:dom
annotation, which will avoid
JAXB parsing of
it. This is a workaround
to a JAXB limitation,
which cannot handle more than one "any"
elements in a
type.
See
http://java.net/jira/browse/JAXB-798
</xsd:documentation>
<xsd:appinfo>
<jaxb:dom/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="tns:valueFilter">
<xsd:annotation>
<xsd:documentation>
List of filters that will be applied to the
value before
it even gets processed by this
assignment. The
filters
will
get applied even before the expression.

The filters will be
executed in chain in the
order as
specified here.

The
filters are
supposed to "clean up" or transcode
the value to comply with usual
XML
standards.
(but see the note in
ValueFilterType documentation)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="source" type="c:ExpressionType">
<xsd:annotation>
<xsd:documentation>
Source of assignement. R-value.
The value (or
values) will be copied from this place
or from the
result of
the
expression.
Depending on how this type is used, the source may be
implicit. Therefore the source
definition is optional.

The
expression will most likely contain variables.
Please refer to the
documentation of
containing or
derived type for more
details.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="target" type="c:XPathType">
<xsd:annotation>
<xsd:documentation>
Destination of the assignment. L-value.
The value
(or values) will be copied to this place.
It is
an XPath
pointer
that must point to an existing,
mutable part of XML document.

The
copy will replace all existing
values. But that
behavior may change
in the future.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ValueFilterType">
<xsd:annotation>
<xsd:documentation>
Defines value filter. The value filters are
supposed to take a
single value of a specific type and
return a
single
value of
the same type. Filters are used to transforms values, e.g.
to clean up illegal characters, to
do charset
transcoding,
etc.

Note:
Strictly speaking, filters should be used for things like
transliteration of
national characters, case
conversions, etc.
They
should not be used to "technical" transformations such as
character
set conversions. Connector should do
that and connector
should return
nice, clean unicode strings. But some
connectors
are faulty and the
ability of filters to do
"technical" things
may come handy.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" processContents="lax">
<xsd:annotation>
<xsd:documentation>
Filter parameters.
</xsd:documentation>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
<xsd:attribute name="type" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
URI identifying the type of the filter. This is a
identifier
of the filter code. Individual
filters may
plug-in under a
specific URI.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="valueFilter" type="tns:ValueFilterType"/>
<xsd:element name="synchronization" type="tns:SynchronizationType"/>
<xsd:complexType name="SynchronizationType">
<xsd:annotation>
<xsd:documentation>
Defines a synchronization properties
(configuration) for a
resource.

TODO: add reconciliation setup
(later)
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element default="true" minOccurs="0" name="enabled" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
Flag indicating if the synchronization is
enabled. If it
is not, the synchronization process will
be
suspended.
If enabled, the synchronization should pull in even the
changes that were done during disabled
synchronization
(limitations
may apply, such as the legth of history
logs on the resource).

Disabling synchronization
means that it will not
be
executed
automatically (e.g. polling resource in regular
intervals). The
synchronization
may still be executed
explicitly
(manually), even if
it is disabled.

If this flag is not present, but a valid
synchronization
setup is found (which usually
means valid
"synchrnization"
element), the synchronization is assumed
to be
enabled.
This flag is meant to act as a tool to
temprarily disable
synchronizatoin without loosing the
configuration and
and state.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="correlation" type="c:QueryType">
<xsd:annotation>
<xsd:documentation>
Correlation expression. It should return a list
of
candadate user entries that may be owners of a
particular
account.

Correlation is an rough but an efficient way how to
relate
the account to a user. The correlation
expression
is in fact just a
search filter. If correlation search
returns more that one entries,
confirmation
expression
will be
executed for each of them.
</xsd:documentation>
</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
relativelly
inefficient, as it will only be run for
candidate entries returned
by correlation expression.

The expression
variables should be set as
follows:
$user - the candidate
user object (one of the results of
correlation expression)
$account - the changed account object
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="reaction">
<xsd:annotation>
<xsd:documentation>
Reaction to a synchronization situation.
Situation identifier must be unique in this set (i.e.
a
situation
definition may occur only once for each
situation).
If there is no
definition for a particular situation,
there will be no
reaction
("do nothing").
The set of situation reactions is considered to be
unordered.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<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="action">
<xsd:annotation>
<xsd:documentation>
Defines an action to take when a situation is
encountered.
If there is no action for a
particular
situation,
there will be no reaction ("do nothing").
There may be sevaral
actions defined here.
In such
case all the actions
will be
executed
in the order as they are defined here.
</xsd:documentation>
</xsd:annotation>
<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:attribute name="ref" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Action identifier (URL)
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="SynchronizationSituationType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="confirmed">
<xsd:annotation>
<xsd:documentation>
The account exists as it should.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="CONFIRMED"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="collision">
<xsd:annotation>
<xsd:documentation>
The account is assigned to two or more IDM
users.
TODO: Do we need this situation?
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="COLLISION"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<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="missing">
<xsd:annotation>
<xsd:documentation>
The account should exist on the resource but it
does not.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="MISSING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="found">
<xsd:annotation>
<xsd:documentation>
The new account is found on the resource (it
exists) and
IDM determines exactly one owner for
that account
in IDM
and that owner should have the account (e.g. has a valid
assignment that implies such account).
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="FOUND"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="unassigned">
<xsd:annotation>
<xsd:documentation>
The new account is found on the resource (it
exists) and
IDM determines exactly one owner for
that account
in IDM
and that owner should not have the account.
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="UNASSIGNED"/>
</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: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:restriction>
</xsd:simpleType>
<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.

More specific types derived from this type may
exists. E.g. a
connector framework may create a derived type and return that instead of this type.

The values of "framework", "connectorType" and "connectorVersion" (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:ExtensibleObjectType">
<xsd:sequence>
<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 (numberic
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 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="connectorHost" type="tns:ConnectorHostType">
<xsd:annotation>
<xsd:documentation>
Connector host that hosts this connector.
</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:annotation>
</xsd:element>
<xsd:element minOccurs="0" ref="tns:schema">
<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 will most likely be only
available at run-time
and will be diffrent
for
every connector. It
is supposed to be
dynamically
interpreted in run-time.

Connector schema is
read-only.
Changing the
schema
is not supported.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="connector" 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:ExtensibleObjectType">
<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="xsd:string">
<xsd:annotation>
<xsd:documentation>
Shared secret used to authenticate client to the host.
</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="ResourceObjectShadowType">
<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.

This XML object provides a representation of the
resource object in the IDM
system, in the LOCAL
REPOSITORY.
It may
represents a minimal data structure in IDM repository
that contains
only
identifier and nothing else. It may
also
represent a rich
structure with a lot of cached or fetched
data. The actual
content of
this object depends on usage: on the
specific
interface and operation
used and even on the system state
and configuration.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="c:ExtensibleObjectType">
<xsd:sequence>
<!-- xsd:choice -->
<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:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="resource" type="tns:ResourceType">
<xsd:annotation>
<xsd:documentation>
Resource that this resource
object shadow
belongs to.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- /xsd:choice -->
<xsd:element name="objectClass" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
TODO
This QName instead of URI becase it may
refer to
a foreign (non-midPoint) schema. Such
schemas may
have
uknown URI-QName mapping, therefore using
QName seems to be more
reliable.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:choice>
<xsd:sequence>
<xsd:element name="attributes">
<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 service or operation that was
invoked.

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

At the normal case there should be at least
attributes that identify the resource object
on the resouce
(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 idenfiers are which are
ordinary
attributes. That can be learned from the
resource
schema provided byresource 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 sotred cached values this may be
days
or even
weeks old value.

Even though there is a
single extenaible
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.

This element is
supposed
to be
used only for
resource object that follow
standard resource
schema. It must not be
used for other
resource
objects.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="0" namespace="##other" processContents="lax"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:any maxOccurs="1" minOccurs="1" namespace="##other" processContents="lax">
<xsd:annotation>
<xsd:documentation>
Any representation of resource object (as a
single element). This may be used only for
resource object
that
do not use standard
resource schema.
For non-standard resource
schemas.
</xsd:documentation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AccountShadowType">
<xsd:annotation>
<xsd:documentation>
Account object type. Represents account on a
target system.
May be used for locally caching the
account data
(in
local
repository).

This is not much more than a marker type, but it is
necessary
as accounts are
important objects in identity
management and
a lot of functionality has special behavior for accounts.

This object
is
supposed to be stored in LOCAL
REPOSITORY, it is
NOT the object on
provisioning resource. For that please see
the
resource schema which
is dynamic and may be
different for
each resource. There is a
standard Account type in standard
resource schema provided by
midPoint project. Resource
connectors
should use that as a supertype
(marker type) for
accounts, but
there may be exceptions.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ResourceObjectShadowType">
<xsd:sequence>
<!-- TODO Account Type -->
<xsd:element maxOccurs="1" minOccurs="0" name="credentials" type="tns:CredentialsType">
<xsd:annotation>
<xsd:documentation>
The set of account credentials (such as
passwords).
</xsd:documentation>
</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:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Following types SHOULD NOT be here. They should be in the respository
WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing
the elements to this namespace works around that bug. This should be moved
to the WSDL once the bug is resolved.
-->
<xsd:complexType name="ResourceObjectShadowListType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="object" type="tns:ResourceObjectShadowType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="UserListType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="user" type="tns:UserType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="user" substitutionGroup="c:object" type="tns:UserType"/>
<xsd:element name="resource" substitutionGroup="c:object" type="tns:ResourceType"/>
<xsd:element name="account" substitutionGroup="c:object" type="tns:AccountShadowType"/>
<xsd:element name="resourceObjectShadow" substitutionGroup="c:object" type="tns:ResourceObjectShadowType"/>
<xsd:element name="modification" type="tns:ObjectModificationType"/>
<!-- Following types SHOULD NOT be here. They should be in the provisioning
WSDL definition. However, there is a bug in OpenESB (OPENESB-5) and placing
the elements to this namespace works around that bug. This should be moved
to the WSDL once the bug is resolved.
-->
<xsd:complexType name="ResourceObjectType">
<xsd:annotation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="1" namespace="##other" processContents="lax">
<xsd:annotation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ResourceObjectIdentificationType">
<xsd:annotation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" minOccurs="1" namespace="##other" processContents="lax">
<xsd:annotation>
<xsd:appinfo>
<xjc:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
</xsd:complexType>
<!-- CONVENIENCE ELEMENTS Following definitions are there to use in examples,
import files, etc. These should not be used in the services
-->
<xsd:element name="objects">
<xsd:complexType>
<xsd:annotation>
<xsd:documentation>
Object list, to be used in import files and
examples.
</xsd:documentation>
<xsd:appinfo>
<a:propertyContainer/>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="c:object"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- MODEL SCHEMA -->
<!-- The following clauses belong to the model schema, not here. But due
to a couple of OpenESB bug (see OPENIDM-124) we were forced to include the
whole model and identity schema in this namespace. It's bad, ugly and very
dangerous. But there is no other known solution. If you know one, please
let us know. We will really appreciate that.
-->
<xsd:annotation>
<xsd:documentation>
IDM Model schema defines the structure of roles,
rules, access
policies, method of assignment of
accounts and
other
resource
objects and all the properties of access control model. It is
based
on the identity schema,
using concepts of User,
Account Shadow
and
so on. IDM Model schema is static, it is available in
compile-time.

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

Expect
that the model will be replaced and do not
depend
on this schema in
low-level components
(except perhaps repository).
</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="ExpressionType">
<xsd:annotation>
<xsd:documentation>
Generic expression. The purpose of the expression
is to return
a value. The expression must produce
something that is a
piece
of XML, which means that it may produce either string value,
XML node or a list of XML
nodes.

The expression may use variables or
arguments. However, such
variables or arguments passed to
the
expression will be
different
for each invocation. It should be
documented in each case this
type is used.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" ref="tns:description"/>
<xsd:element minOccurs="0" name="ref" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
QName of the XML node that the expression is
supposed to produce. This attribute is optional.

If this attribute is used and the expression produces a string output, the output
should be considered as the content of a XML element defined by the contect of this
attribute.

If the expression produces a XML node or a set of nodes, the node(s) should match the
content of this attribute.

However, the exact interpretation of this attribute is not defined here, it may be
different for each use of this type.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="http://www.w3.org/TR/xpath/" minOccurs="0" name="language" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
Language of the expression.
The expressions in
multiple languages may be supported in
later
versions of
midPoint.
Now the only supported language
is XPath 1.0, which is also the
default language.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="code" type="tns:ExpressionCodeType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="expression" type="tns:ExpressionType"/>
<xsd:complexType mixed="true" name="ExpressionCodeType">
<xsd:annotation>
<xsd:documentation>
The expression code is supposed to be in the contect of this type. The content ix "mixed"
which allows both XML and non-XML languages.

The expression may use variables or arguments. However, such variables or arguments passed
to the expression will be different for each invocation. It should be documented in each
case this type is used.
</xsd:documentation>
<xsd:appinfo>
<jaxb:dom/>
</xsd:appinfo>
</xsd:annotation>
</xsd:complexType>
<xsd:element name="condition" type="tns:ExpressionType">
<xsd:annotation>
<xsd:documentation>
Boolean condition. The return of this expression
must be either
true or false.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="VariableDefinitionType">
<xsd:annotation>
<xsd:documentation>
Definition of a variable. This type declares a
variable name
and defines the initial content of the
variable.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element minOccurs="0" ref="tns:description"/>
<xsd:choice>
<xsd:element name="objectRef" type="tns:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="value" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
Variable name. The variable will be presented to
the expression
using specified name.

The name is a
QName,
which is
good for XML-based expression
languages such as XPath. For languages
with flat names the
namespace is
fixed (see
documentation of midPoint
language
binding) and the only relevant name is the local part.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:complexType abstract="true" name="ProtoStructureType">
<xsd:annotation>
<xsd:documentation>
TODO

Experimental object. MOST LIKELY WILL CHANGE.

TODO: type???

Defines hierarchical objects - or
more
exactly nested.

may contain other entitlements. Such a containing
object, when
assigned to user, is equivalent to
the union
of
all contained objects
(and objects contained in the
contained objects, ad infinutum). There
is no
constrain that
the containing
and contained objects must be of
the same type.
Therefore it should be possible to
create a "business
role" that
will contain a
set of "IT roles" that specify access to
resources
and a set of "IDM
roles" that gives user administrator
privileges in midPoint
system.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ExtensibleObjectType">
<xsd:sequence>
<xsd:choice maxOccurs="unbounded" minOccurs="0">
<xsd:element name="containedObject" type="tns:ObjectType">
<xsd:annotation>
<xsd:documentation>
Contained object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="containedObjectRef" type="c:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Reference to the contained object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="RoleType">
<xsd:annotation>
<xsd:documentation>
A role that implies assignments.
The role may "grant" accounts on resources, attributes and
entitlements for such accounts. The role can also assign
organizational units, other roles or various IDM objects
that can be assigned directly to user. Role is in fact just
a named set of assignments.

The speicific roles are also called technical role or IT role,
however this definition is an abstract definition of concept
that can span wide area of intepretation.

This is the basic building blog of role-based access
contol (RBAC) in the provisioning system. It defines what
rights (e.g. accounts) should be given to user, how they
should look like (attributes) and what groups or native
roles to assign to them (entitlements).

This role definition is quite simplistic now. It does not
support rule-derived values or any other advanced dynamics.
Yet. It will be extended later in the development.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ExtensibleObjectType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="assignment" type="tns:AssignmentType">
<xsd:annotation>
<xsd:documentation>
Set of roles's assignments.
Represents objects (such as roles) or accounts assigned to the
role and therefore implied by the role.

The assignment may contain account construction. Such element
specified the account specified by this element should be
created when the role is assigned (unless such account already
exists). The account should be set up according to the definitions
contained in this element.

TODO: variables in the expressions:
$user
$role
$assignment
$account
$resource

If the role implying this account is unassigned
and no other role or assignment implies the account, the
account should be removed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="role" substitutionGroup="tns:object" type="tns:RoleType"/>
<xsd:complexType name="AccountConstructionType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>
<xsd:element maxOccurs="1" minOccurs="0" ref="c:extension"/>
<xsd:choice>
<xsd:element minOccurs="0" name="resourceRef" type="c:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Reference to a resource that
should host the
implied account.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="resource" type="tns:ResourceType">
<xsd:annotation>
<xsd:documentation>
Resource that should host the
implied account.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:choice>
<xsd:element minOccurs="0" name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Type of account that should be created on the
resource.

This must point to the a valid
accountType
definition in
the resource
object (in schemaHandling section).

This element is
optional. If not
specified then the account
type
marked as default
in the resource
definition should be used.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="typeExpression" type="c:ExpressionType">
<xsd:annotation>
<xsd:documentation>
Expression that determines type of account that
should be created on the resource.
TODO: more

The
variables should
be set as follows:
$user - the user that this account will belong
to
$assignment - an assignemt
that is
assigning the
object in which
context is this expression
evaluated (e.g. assignment of role)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:element minOccurs="0" ref="c:condition">
<xsd:annotation>
<xsd:documentation>
The account is implied only if the condition is
evaluated to true.
If condition is not present, it
is
assumed to be
true.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:ValueConstructionType">
<xsd:annotation>
<xsd:documentation>
Account attribute values implied by
this role.
When the role is assigned
the attributes specified
below
should
be
assigned values specified below.

When the role is unassigned, the
values specified below should be
removed unless
some other role
is
still specifying them.

TODO: this is very simplistic now.
Later we
need flags for
value
removal,
authoritativeness, merging
approach,
etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="entitlement" type="tns:EntitlementConstructionType">
<xsd:annotation>
<xsd:documentation>
Assignments implied by this role.
When the role
is assigned the
assignable types (groups, native
roles)
specified
below should
be assigned to the account.

When the role is
unassigned, the
assignable types specified
below
should be
unassigned
unless some
other role is still specifying them.

TODO: this is very
simplistic now.
Later
we need flags for value
removal,
authoritativeness, merging
approach, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="EntitlementConstructionType">
<xsd:complexContent>
<xsd:extension base="tns:ValueConstructionType">
<xsd:choice>
<xsd:element minOccurs="0" name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Type of entitlement that should be created on
the resource.

This must point to the a valid
entitlementType
definition in the resource
object (in schemaHandling section).

This element is optional. If not
specified
then the entitlement
type
marked as default in the resource
definition should be used.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="typeExpression" type="c:ExpressionType">
<xsd:annotation>
<xsd:documentation>
Expression that determines type of account
that
should be created on the resource.
TODO

The
variables
should be
set as follows:
$account - the account that this entitlement will
be part of
$user - the user
that such account
will belong to
$assignment - an assignemt that is assigning the
object in which
context is this
expression
evaluated (e.g.
assignment of role)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="UserTemplateType">
<xsd:annotation>
<xsd:documentation>
The user template used to create new users.
It
contains fixed values or expressions that can set-up
a new
user
obejct. It is used only during user creation in the
synchronization
code, but will be most likely used also
on other
places
later.

The goal
is to make this a kind of "policy" how the use object
should look
like and check it on
every user modification.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="c:ExtensibleObjectType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="propertyConstruction" type="tns:PropertyConstructionType">
<xsd:annotation>
<xsd:documentation>
Defines how any of the User's properties
should
be constructed. It can contain fixed value or
an
expression.

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

Note: the expressions will
be evaluated in the
order as
they are specified in the XML file for
now, as the dependency
mechanism does not work
yet. Later, the order should be
insignificant.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- TODO: Assignment construction. Later. -->
<xsd:element maxOccurs="unbounded" minOccurs="0" name="accountConstruction" type="tns:AccountConstructionType">
<xsd:annotation>
<xsd:documentation>
Defines an account that the user should have.
It
defines the resource and account type. Such
account will
be
created (if it does not yet
exist) and will be linked to the
user.
Usual outbound expressions from
the resource
definition
are
used to set-up the account
parameters.

This may be non-systemic
short-term solution. We
need a way how "assign" the
account to
the user
correctly.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="userTemplate" substitutionGroup="c:object" type="tns:UserTemplateType"/>
<!-- OPERATIONAL SCHEMA -->
<!-- The following clauses belong to the operation support. -->
<!-- TODO - check -->
<xsd:element name="passwordPolicy" type="tns:PasswordPolicyType"/>
<xsd:complexType name="PasswordPolicyType">
<xsd:complexContent>
<xsd:extension base="c:ObjectType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="lifetime" type="c:PasswordLifeTimeType"/>
<xsd:element maxOccurs="1" minOccurs="1" name="stringPolicy" type="c:StringPolicyType"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PasswordLifeTimeType">
<xsd:sequence>
<xsd:element default="-1" minOccurs="0" name="expiration" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
Number of days before password expires
-1 : means
password doesn't expire
0 : means password is
expired
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="0" minOccurs="0" name="warnBeforeExpiration">
<xsd:annotation>
<xsd:documentation>
Number of days before password expiration to
send warnings (0 means no warnings)
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element default="0" minOccurs="0" name="lockAfterExpiration">
<xsd:annotation>
<xsd:documentation>
Number of days after password after password
expiration the account will be locked (0 means never
will be
locked)
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element default="0" minOccurs="0" name="minPasswordAge" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
Number of days before password may be changed (0
means password can be changed immediately)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element default="0" minOccurs="0" name="passwordHistoryLength" type="xsd:int">
<xsd:annotation>
<xsd:documentation>
Number of unique passwords in history (0 - no
history)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="StringPolicyType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="description" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="limitations" type="tns:limitationsType"/>
<xsd:element maxOccurs="1" minOccurs="0" name="characterClass" type="tns:CharacterClassType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="limitationsType">
<xsd:annotation>
<xsd:documentation>
Definition of complexity and string policy
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element default="0" maxOccurs="1" minOccurs="0" name="minLength" type="xsd:int"/>
<xsd:element default="-1" maxOccurs="1" minOccurs="0" name="maxLength" type="xsd:int"/>
<xsd:element default="0" maxOccurs="1" minOccurs="0" name="minUniqueChars" type="xsd:int"/>
<xsd:element default="false" maxOccurs="1" minOccurs="0" name="checkAgainstDictionary" type="xsd:boolean"/>
<xsd:element maxOccurs="1" minOccurs="0" name="checkPattern" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="limit" type="tns:StringLimitType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="StringLimitType">
<xsd:annotation>
<xsd:documentation>
Definition of valid single string limitation
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="description" type="xsd:string"/>
<xsd:element default="0" maxOccurs="1" minOccurs="0" name="minOccurs" type="xsd:int"/>
<xsd:element default="-1" maxOccurs="1" minOccurs="0" name="maxOccurs" type="xsd:int"/>
<xsd:element default="false" maxOccurs="1" minOccurs="0" name="mustBeFirst" type="xsd:boolean"/>
<xsd:element maxOccurs="1" minOccurs="0" name="characterClass" type="tns:CharacterClassType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="CharacterClassType">
<xsd:annotation>
<xsd:documentation>
Definition of valid characters in class. Default
value is ASCII printable characters (Codes 0x20
to 0x7E)
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice>
<xsd:element maxOccurs="unbounded" minOccurs="1" name="characterClass" type="tns:CharacterClassType"/>
<xsd:element minOccurs="1" name="value" type="xsd:string"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="ref" type="xsd:QName" use="optional"/>
<xsd:attribute name="name" type="xsd:QName" use="optional"/>
</xsd:complexType>
<!-- End of TODO -->
<xsd:element name="operationResult" type="tns:OperationResultType"/>
<xsd:complexType name="OperationResultType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="operation" type="xsd:string"/>
<xsd:element name="status" type="tns:OperationResultStatusType"/>
<xsd:element minOccurs="0" name="params" type="tns:ParamsType"/>
<xsd:element minOccurs="0" name="token" type="xsd:long"/>
<xsd:element minOccurs="0" name="messageCode" type="xsd:string"/>
<xsd:element minOccurs="0" name="message" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Error or warning message.
This is optional, as some types does not need a message (e.g. success).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="0" name="localizedMessage" type="tns:LocalizedMessageType"/>
<xsd:element minOccurs="0" name="details" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="partialResults" type="tns:OperationResultType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="LocalizedMessageType">
<xsd:sequence>
<xsd:element name="key" type="xsd:string"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="argument" type="xsd:anySimpleType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ParamsType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="entry" type="tns:EntryType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="EntryType">
<xsd:sequence>
<xsd:any minOccurs="0" processContents="lax">
<xsd:annotation>
<xsd:documentation>
Value of the entry. If there is a object that can native XML representation, such representation should
be used. Otherwise the UnknownJavaObject can be used.
</xsd:documentation>
</xsd:annotation>
</xsd:any>
</xsd:sequence>
<xsd:attribute name="key" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:simpleType name="OperationResultStatusType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="success">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="SUCCESS"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="warning">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="WARNING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="partial_error">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="PARTIAL_ERROR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="fatal_error">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="FATAL_ERROR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="not_applicable">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="NOT_APPLICABLE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="in_progress">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="IN_PROGRESS"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="unknown">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="UNKNOWN"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="UnknownJavaObjectType">
<xsd:annotation>
<xsd:documentation>
Type used to represent Java objects that are otherwise unknown to the system and cannot be
represented in "canonical" XML form. This must be used only in diagnostics messages intended
to be displayed to the human user. It must not be used in places indended for computer processing.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="class" type="xsd:string"/>
<xsd:element name="toString" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="unknownJavaObject" type="tns:UnknownJavaObjectType"/>
<!-- Configuration types -->
<xsd:complexType name="SystemConfigurationType">
<xsd:annotation>
<xsd:documentation>
System configuration object.

Holds global system configuration setting. There will be just one object of
this type in the system. It will have a well-known OID.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:ExtensibleObjectType">
<xsd:sequence>
<xsd:element minOccurs="0" name="logging" type="tns:LoggingConfigurationType">
<xsd:annotation>
<xsd:documentation>
Persistent configuration of logging levels, categories, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="defaultUserTemplate" type="tns:UserTemplateType">
<xsd:annotation>
<xsd:documentation>
User template that will be used "universtally" in all situations regarding user internal consistency.

TODO: better documentation
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="defaultUserTemplateRef" type="c:ObjectReferenceType">
<xsd:annotation>
<xsd:documentation>
Reference to the default user template that will be used "universtally" in all situations regarding
user internal consistency.

TODO: better documentation
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="1" minOccurs="0" name="connectorFramework">
<xsd:annotation>
<xsd:documentation>
Global configuration of connectors and connector frameworks.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="configuration">
<xsd:annotation>
<xsd:documentation>
Global configuration properties of a connector framework.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" 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:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="LoggingConfigurationType">
<xsd:annotation>
<xsd:documentation>
Configuration of logging levels, categories, log
files, etc.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="subSystemLogger" type="tns:SubSystemLoggerConfigurationType"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="classLogger" type="tns:ClassLoggerConfigurationType"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="appender" type="tns:AppenderConfigurationType"/>
<xsd:element name="rootLoggerAppender" type="xsd:string"/>
<xsd:element name="rootLoggerLevel" type="tns:LoggingLevelType"/>
<xsd:element maxOccurs="1" minOccurs="0" name="advanced" type="tns:AdvancedLoggingConfigurationType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType mixed="true" name="AdvancedLoggingConfigurationType">
<xsd:annotation>
<xsd:documentation>
Contains free form loging configuration.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:any maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ClassLoggerConfigurationType">
<xsd:annotation>
<xsd:documentation>
Configuration of the logger: the facility that
collects log
messages from the code.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="level" type="tns:LoggingLevelType">
<xsd:annotation>
<xsd:documentation>
Logger level
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="1" name="package" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
TODO: packages are OR-ed
TODO: string, wildcards
allowed (* as in java)
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="appender" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Appender name defined in appenders section in
logging configuration
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SubSystemLoggerConfigurationType">
<xsd:annotation>
<xsd:documentation>
Configuration of the logger: the facility that
collects log messages from subsystem code.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="level" type="tns:LoggingLevelType">
<xsd:annotation>
<xsd:documentation>
Logger level
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element minOccurs="1" name="component" type="c:LoggingComponentType">
<xsd:annotation>
<xsd:documentation>
TODO: components are OR-ed
TODO: string, but
there should be a way how to determine
list of valid
categories.
Maybe switch to enum later.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="appender" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Appender name defined in appenders section in
logging configuration
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="LoggingLevelType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ALL">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="ALL"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="OFF">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="OFF"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="ERROR">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="ERROR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="WARN">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="WARN"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="INFO">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="INFO"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="DEBUG">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="DEBUG"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="TRACE">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="TRACE"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="ALL">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="ALL"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LoggingComponentType">
<xsd:annotation>
<xsd:documentation>
TODO
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="ALL">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="ALL"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="MODEL">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="MODEL"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="PROVISIONING">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="PROVISIONING"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="REPOSITORY">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="REPOSITORY"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="WEB">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="GUI"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="TASKMANAGER">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="TASKMANAGER"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="RESOURCEOBJECTCHANGELISTENER">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="RESOURCEOBJECTCHANGELISTENER"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="AppenderConfigurationType">
<xsd:annotation>
<xsd:documentation>
Configuration of the logger: the facility that
collects log
messages from the code.

TODO
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="pattern" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="FileAppenderConfigurationType">
<xsd:complexContent>
<xsd:extension base="tns:AppenderConfigurationType">
<xsd:sequence>
<xsd:element name="fileName" type="xsd:string"/>
<xsd:element name="filePattern" type="xsd:string"/>
<xsd:element name="maxHistory" type="xsd:int"/>
<xsd:element name="maxFileSize" type="xsd:string"/>
<xsd:element name="append" type="xsd:boolean"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="SystemObjectsType">
<xsd:annotation>
<xsd:documentation>
OID constants for system objects
</xsd:documentation>
<xsd:appinfo>
<jaxb:typesafeEnumClass/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="00000000-0000-0000-0000-000000000001">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="SYSTEM_CONFIGURATION"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="00000000-0000-0000-0000-000000000002">
<xsd:annotation>
<xsd:appinfo>
<jaxb:typesafeEnumMember name="USER_ADMINISTRATOR"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

This XML schema documentation has been generated with DocFlex/XML RE 1.8.5 using DocFlex/XML XSDDoc 2.5.0 template set.
DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high-quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML.
DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-quality XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future).
A commercial license for "DocFlex/XML XSDDoc" will allow you:
  • To configure the generated documentation so much as you want. Thanks to our template technology, it was possible to support > 400 template parameters, which work the same as "options" of ordinary doc-generators. The parameters are organized in nested groups, which form a parameter tree. Most of them have their default values calculated dynamically from a few primary parameters. So, you'll never need to specify all of them. That will give you swift and effective control over the generated content!
  • To use certain features disabled in the free mode (such as the full documenting of substitution groups).
  • To select only the initial, imported, included, redefined XML schemas to be documented or only those directly specified by name.
  • To include only XML schema components specified by name.
  • To document local element components both globally and locally (similar to attributes).
  • To allow/suppress unification of local elements by type.
  • To enable/disable reproducing of namespace prefixes.
  • To use PlainDoc.tpl main template to generate all the XML schema documentation in a signle-file form as both HTML and incredible quality RTF output.
  • To format your annotations with XHTML tags and reproduce that formatting both in HTML and RTF output.
  • To insert images in your annotations using XHTML <img> tags (supported both in HTML and RTF output).
  • To remove this very advertisement text!
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML (Full Edition) and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required!
But this is not all. In addition to it, a commercial license for "DocFlex/XML SDK" will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own!
Please note that by purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the results of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us!
To purchase a license, please follow this link: http://www.filigris.com/shop/