# SchemaHandlingType (Complex Type)

### Namespace: http://midpoint.evolveum.com/xml/ns/public/common/common-3

Specification of handling details for resource schema. E.g. read-only or read-write attributes, account object classes, etc. This element belongs to ResourceType and should not be used elsewhere. This is a top-level element to make the implementation (JAXB marshal/unmarshal) easier.

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
objectClass | container ResourceObjectTypeDefinitionType | [0,-1] | Refinement (modification, extension) of definitions of object classes in the "native" resource schema.
objectType | container ResourceObjectTypeDefinitionType | [0,-1] | Definition of types of objects this resource supports: account types, entitlement types, and so on.
associationType | container ShadowAssociationTypeDefinitionType | [0,-1] | Definition of types of associations between resource objects.

- ### Items

  - #### objectClass

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Display order:

    Refinement (modification, extension) of definitions of object classes in the "native" resource schema. This is to specify refinements that should be applied to _all_ objects and operations related to given object class. For example, if we want to specify fetch strategy for specific attribute of groupOfUniqueNames object class, and apply this consistently to all search operations over this object class, we should specify the strategy here. This is something that has been achieved by setting default=true for a selected object type definition. However, the use of object class refinement is more focused and (in a sense) more clear way how to achieve this. Beware: Although the XSD type is formally ResourceObjectTypeDefinitionType (primarily because of implementation reasons), not all elements of ResourceObjectTypeDefinitionType are supported here. For example, it's not possible to specify kind, intent, nor super-type here. Because of a limitation of XSD language we are not able to express these restrictions without changing the order of XML elements in complying documents (because the typical solution: deriving both ResourceObjectTypeDefinitionType and something like "ResourceObjectClassDefinitionType" from a common ancestor would mean that the order of XML elements in resulting documents would be different from what it is now). We also advise avoid specification of pure object-type concepts (like mappings) in these definitions. It is better to create a special (abstract) object type to do this.

  - #### objectType

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Display order:

    Definition of types of objects this resource supports: account types, entitlement types, and so on. Each type has its delineation (specification what resource objects belong to it), focus specification (what focal objects correspond to it), attribute definitions (mappings and other options), association definitions, protected objects specification, capabilities, and so on. Resource object types are used when resource objects are addressed: for example when they are assigned (to roles, orgs, users), targeted by synchronization tasks, searched for using Query API, and so on. Type definitions can form hierarchies, with subtypes inheriting definitions from their supertypes. (And all inheriting definitions from refined object class definitions.)

  - #### associationType

    Flags: RAM,runtime

    Multiplicity: [0,-1]

    Display order:

    Definition of types of associations between resource objects.