complexType "tns:ObjectType"
Namespace:
Content:
complex, 2 attributes, 2 elements
Abstract:
(cannot be assigned directly to elements used in instance XML documents)
Defined:
globally in common-1.xsd; see XML source
Includes:
definitions of 2 attributes, 2 elements
Used:
XML Representation Summary
<...
   
 = 
xsd:string
 = 
xsd:string
    >
   
Content: 
tns:name?, tns:description?
</...>
Content Model Elements (2):
tns:description, tns:name
Known Direct Subtypes (2):
tns:ExtensibleObjectType, tns:PasswordPolicyType
Known Indirect Subtypes (12):
tns:AccountShadowType, tns:ConnectorHostType, tns:ConnectorType, tns:GenericObjectType, tns:ProtoStructureType, tns:ResourceObjectShadowType, tns:ResourceType, tns:RoleType, tns:SystemConfigurationType, tns:TaskType, tns:UserTemplateType, tns:UserType
All Direct / Indirect Based Elements (24):
tns:account, tns:account (type tns:AccountShadowType), tns:connector, tns:connector (type tns:ConnectorType), tns:connectorHost, tns:connectorHost (type tns:ConnectorHostType), tns:containedObject (type tns:ObjectType), tns:defaultUserTemplate (in tns:systemConfiguration), tns:genericObject, tns:object, tns:object (type tns:ObjectType), tns:object (type tns:ResourceObjectShadowType), tns:passwordPolicy, tns:resource, tns:resource (type tns:ResourceType), tns:resourceObjectShadow, tns:role, tns:shadow (type tns:ResourceObjectShadowType), tns:systemConfiguration, tns:target (in tns:assignment), tns:task, tns:user, tns:user (type tns:UserType), tns:userTemplate
Known Usage Locations
Annotation
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): <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 <extension> 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.
XML Source (see within schema source)
<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>
Attribute Detail (all declarations; 2/2)
oid
Type:
Use:
optional
Defined:
locally within (this) tns:ObjectType complexType
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.
XML Source (see within schema source)
<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>

version
Type:
Use:
optional
Defined:
locally within (this) tns:ObjectType complexType
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.
XML Source (see within schema source)
<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>
Content Element Detail (all declarations; 2/2)
tns:description
Type:
xsd:string, simple content
Defined:
by reference within (this) tns:ObjectType complexType
Free-form textual description of the object.
XML Source (see within schema source)
<xsd:element minOccurs="0" ref="tns:description">
<xsd:annotation>
<xsd:documentation>
Free-form textual description of the object.
</xsd:documentation>
</xsd:annotation>
</xsd:element>

tns:name
Type:
xsd:string, simple content
Defined:
by reference within (this) tns:ObjectType complexType
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.
XML Source (see within schema source)
<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>

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/