element <tns:user> (global)
Namespace:
Type:
Content:
complex, 2 attributes, 20 elements
Subst.Gr:
may substitute for element tns:object
Defined:
globally in common-1.xsd; see XML source
Used:
never
XML Representation Summary
<tns:user
   
 = 
xsd:string
 = 
xsd:string
    >
   
Content: 
tns:name?, tns:description?, tns:extension?, tns:fullName, tns:givenName, tns:familyName, tns:additionalNames*, tns:honorificPrefix?, tns:honorificSuffix?, tns:eMailAddress*, tns:telephoneNumber*, tns:employeeNumber?, tns:employeeType*, tns:organizationalUnit*, tns:locality?, tns:credentials?, tns:activation?, tns:assignment*, tns:account*, tns:accountRef*
</tns:user>
Content model elements (20):
tns:account (type tns:AccountShadowType), tns:accountRef (type tns:ObjectReferenceType), tns:activation (type tns:ActivationType), tns:additionalNames (type xsd:string), tns:assignment (type tns:AssignmentType), tns:credentials (type tns:CredentialsType), tns:description, tns:eMailAddress (type xsd:string), tns:employeeNumber (type xsd:string), tns:employeeType (type xsd:string), tns:extension, tns:familyName (type xsd:string), tns:fullName (type xsd:string), tns:givenName (type xsd:string), tns:honorificPrefix (type xsd:string), tns:honorificSuffix (type xsd:string), tns:locality (type xsd:string), tns:name, tns:organizationalUnit (type xsd:string), tns:telephoneNumber (type xsd:string)
XML Source (see within schema source)
<xsd:element name="user" substitutionGroup="c:object" type="tns:UserType"/>
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; 20/20)
tns:account
Type:
tns:AccountShadowType, complex content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

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

tns:activation
Type:
tns:ActivationType, complex content
Defined:
locally within tns:UserType complexType
User's activation. e.g. enable/disable status, start and end dates, etc.
XML Source (see within schema source)
<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>

tns:additionalNames
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:assignment
Type:
tns:AssignmentType, complex content
Defined:
locally within tns:UserType complexType
Set of user's assignments. Represents objects (such as roles) or accounts directly assigned to a user.
XML Source (see within schema source)
<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>

tns:credentials
Type:
tns:CredentialsType, complex content
Defined:
locally within tns:UserType complexType
The set of user's credentials (such as passwords).
XML Source (see within schema source)
<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>

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:eMailAddress
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:employeeNumber
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:employeeType
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
Employee type specification such as internal employee, external or partner. The specific values are deployment-specific.
XML Source (see within schema source)
<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>

tns:extension
Type:
anonymous complexType, complex content
Defined:
XML Source (see within schema source)
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:extension"/>

tns:familyName
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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
XML Source (see within schema source)
<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>

tns:fullName
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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
XML Source (see within schema source)
<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>

tns:givenName
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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
XML Source (see within schema source)
<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>

tns:honorificPrefix
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:honorificSuffix
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:locality
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

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:organizationalUnit
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

tns:telephoneNumber
Type:
xsd:string, simple content
Defined:
locally within tns:UserType complexType
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.
XML Source (see within schema source)
<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>

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/