complexType "tns:ResourceType"
Namespace:
Content:
complex, 2 attributes, 13 elements
Defined:
globally in common-1.xsd; see XML source
Includes:
definitions of 10 elements
Used:
XML Representation Summary
<...
   
 = 
xsd:string
 = 
xsd:string
    >
   
Content: 
tns:name?, tns:description?, tns:extension?, tns:connector?, tns:connectorRef?, tns:namespace, tns:configuration, tns:schema?, tns:schemaHandling?, tns:nativeCapabilities?, tns:capabilities?, tns:scripts?, tns:synchronization?
</...>
Content Model Elements (13):
tns:capabilities (type tns:CapabilitiesType), tns:configuration, tns:connector (type tns:ConnectorType), tns:connectorRef (type tns:ObjectReferenceType), tns:description, tns:extension, tns:name, tns:namespace (type xsd:anyURI), tns:nativeCapabilities (type tns:CapabilitiesType), tns:schema, tns:schemaHandling, tns:scripts, tns:synchronization
All Direct / Indirect Based Elements (2):
tns:resource, tns:resource (type tns:ResourceType)
Known Usage Locations
Annotation
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).
Type Definition Detail
Type Derivation Tree
tns:ObjectType (extension)
  tns:ExtensibleObjectType (extension)
      tns:ResourceType
XML Source (see within schema source)
<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>
Attribute Detail (all declarations; 2/2)
oid
Type:
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:
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; 13/13)
tns:capabilities
Type:
tns:CapabilitiesType, complex content
Defined:
locally within (this) tns:ResourceType complexType
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.
XML Source (see within schema source)
<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>

tns:configuration
Type:
anonymous complexType, complex content
Defined:
by reference within (this) tns:ResourceType complexType
XML Source (see within schema source)
<xsd:element ref="tns:configuration"/>

tns:connector
Type:
tns:ConnectorType, complex content
Defined:
locally within (this) tns:ResourceType complexType
"Composite" version of the ConnectorType reference. See below for more details.
XML Source (see within schema source)
<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>

tns:connectorRef
Type:
tns:ObjectReferenceType, complex content
Defined:
locally within (this) tns:ResourceType complexType
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.
XML Source (see within schema source)
<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>

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:
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:namespace
Type:
xsd:anyURI, simple content
Defined:
locally within (this) tns:ResourceType complexType
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.
XML Source (see within schema source)
<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>

tns:nativeCapabilities
Type:
tns:CapabilitiesType, complex content
Defined:
locally within (this) tns:ResourceType complexType
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.
XML Source (see within schema source)
<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>

tns:schema
Type:
tns:XmlSchemaType, complex content
Defined:
by reference within (this) tns:ResourceType complexType
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
XML Source (see within schema source)
<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>

tns:schemaHandling
Type:
tns:SchemaHandlingType, complex content
Defined:
by reference within (this) tns:ResourceType complexType
XML Source (see within schema source)
<xsd:element minOccurs="0" ref="tns:schemaHandling"/>

tns:scripts
Type:
tns:ScriptsType, complex content
Defined:
by reference within (this) tns:ResourceType complexType
XML Source (see within schema source)
<xsd:element minOccurs="0" ref="tns:scripts"/>

tns:synchronization
Type:
tns:SynchronizationType, complex content
Defined:
by reference within (this) tns:ResourceType complexType
XML Source (see within schema source)
<xsd:element minOccurs="0" ref="tns:synchronization"/>

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/