element <tns:shadow> (local)

Namespace:	http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd
Type:	tns:ResourceObjectShadowType
Content:	complex, 2 attributes, 7 elements, elem. wildcard
Defined:	locally witnin tns:ResourceObjectShadowChangeDescriptionType complexType in common-1.xsd; see XML source

XML Representation Summary

<tns:shadow

oid	=	xsd:string
version	=	xsd:string

Content:

tns:name?, tns:description?, tns:extension?, tns:resourceRef?, tns:resource?, tns:objectClass, (tns:attributes | {any})

</tns:shadow>

Content model elements (7):

tns:attributes (defined in tns:ResourceObjectShadowType complexType), tns:description, tns:extension, tns:name, tns:objectClass (type xsd:QName), tns:resource (type tns:ResourceType), tns:resourceRef (type tns:ObjectReferenceType)

Annotation

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).

XML Source (see within schema source)

<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>

Attribute Detail (all declarations; 2/2)

oid

Type:	xsd:string
Use:	optional
Defined:	locally within 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:	xsd:string
Use:	optional
Defined:	locally within 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; 8/8)

tns:attributes

Type:	anonymous complexType, complex content
Defined:	locally within tns:ResourceObjectShadowType complexType

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.

XML Source (see within schema source)

<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>

tns:description

Type:	xsd:string, simple content
Defined:	by reference within 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:extension

Type:	anonymous complexType, complex content
Defined:	by reference within tns:ExtensibleObjectType complexType

XML Source (see within schema source)

<xsd:element maxOccurs="1" minOccurs="0" ref="tns:extension"/>

tns:name

Type:	xsd:string, simple content
Defined:	by reference within 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>

tns:objectClass

Type:	xsd:QName, simple content
Defined:	locally within tns:ResourceObjectShadowType complexType

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.

XML Source (see within schema source)

<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>

tns:resource

Type:	tns:ResourceType, complex content
Defined:	locally within tns:ResourceObjectShadowType complexType

Resource that this resource object shadow belongs to.

XML Source (see within schema source)

<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>

tns:resourceRef

Type:	tns:ObjectReferenceType, complex content
Defined:	locally within tns:ResourceObjectShadowType complexType

Reference to a resource that this resource object shadow belongs to.

XML Source (see within schema source)

<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>

{any element with non-schema namespace}

Defined:

within tns:ResourceObjectShadowType complexType

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.

XML Source (see within schema source)

<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>

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/