element <tns:attribute> (local)
Namespace:
Type:
Content:
complex, 1 attribute, 6 elements
Defined:
XML Representation Summary
<tns:attribute
   
 = 
xsd:QName
    >
   
Content: 
tns:name?, tns:description?, tns:ignore?, tns:access*, tns:outbound?, tns:inbound*
</tns:attribute>
Content model elements (6):
tns:access, tns:description, tns:ignore, tns:inbound (in tns:attribute in tns:accountType), tns:name, tns:outbound (in tns:attribute in tns:accountType)
Included in content model of elements (1):
tns:accountType (in tns:schemaHandling)
Annotation
Specification of handling of an account attribute. This overrides annotations in the resource schema.
XML Source (see within schema source)
<xsd:element maxOccurs="unbounded" minOccurs="0" name="attribute" type="tns:AttributeDescriptionType">
<xsd:annotation>
<xsd:documentation>
Specification of handling of an account
attribute.
This overrides annotations in the resource
schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Attribute Detail (all declarations; 1/1)
ref
Type:
Use:
optional
Defined:
Name of the property attribute (XSD element) that this definition describes. It must point to the first-level attribute in the resource schema that belongs to an object class that is being described here.
XML Source (see within schema source)
<xsd:attribute name="ref" type="xsd:QName">
<xsd:annotation>
<xsd:documentation>
Name of the property attribute (XSD element) that
this
definition describes. It must point to the
first-level
attribute
in the resource schema that belongs to an
object class that is being
described here.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
Content Element Detail (all declarations; 6/6)
tns:access
Type:
tns:AccessType, simple content
Defined:
Access to the attribute as defined by the system administrator or deployer. This can constrain the access defined by resource schema annotations. Specifying broader access that the resource connector can handle is an error. If no access is specified, it defaults to read-write.
XML Source (see within schema source)
<xsd:element maxOccurs="unbounded" minOccurs="0" ref="c:access">
<xsd:annotation>
<xsd:documentation>
Access to the attribute as defined
by the system
administrator or deployer.
This can constrain the
access
defined by
resource schema annotations.
Specifying broader access that the
resource
connector can handle is an
error.

If no
access is specified,
it defaults to
read-write.
</xsd:documentation>
</xsd:annotation>
</xsd:element>

tns:description
Type:
xsd:string, simple content
Defined:
XML Source (see within schema source)
<xsd:element maxOccurs="1" minOccurs="0" ref="tns:description"/>

tns:ignore
Type:
xsd:boolean, simple content
Default:
"true"
Defined:
XML Source (see within schema source)
<xsd:element minOccurs="0" ref="tns:ignore"/>

tns:inbound
Type:
tns:ValueAssignmentType, complex content
Defined:
Defines how the attribute values are used (assigned) in case of information flow from resource to IDM, e.g. in case of synchronization, reconciliation or discovery. In case a source expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account that has been changed (after the change) Explanation: This is not a "value construction" as it is not constructing a new attribute value. It is rather using attribute value that was set be someone else. A simpler way how to express the assignement is needed here, especially a simple way how to express assignment target. Some rules may use that information and we definitelly need that to generate correct relative change descriptions.
XML Source (see within schema source)
<xsd:element maxOccurs="unbounded" minOccurs="0" name="inbound" type="tns:ValueAssignmentType">
<xsd:annotation>
<xsd:documentation>
Defines how the attribute values are used
(assigned) in
case of information flow from resource to
IDM, e.g.
in
case of synchronization, reconciliation or discovery.

In case a
source expression is used, the
expression
variables should
be as
follows:
$user - the user to whom the account belongs
$account - the
account that
has been changed (after the change)

Explanation: This
is not a "value construction" as it
is not constructing a new
attribute value. It is rather
using attribute
value that was set be
someone else.
A simpler way how to express the
assignement is needed
here, especially a simple way how
to express assignment
target.
Some rules may use that
information and we
definitelly need that to
generate correct relative
change descriptions.
</xsd:documentation>
</xsd:annotation>
</xsd:element>

tns:name
Type:
xsd:string, simple content
Defined:
Human readable name for the account attribute. This name may be displayd in tools and GUIs to provide more pleasant user experience, as the native attribute names may look quite frightening (especially in LDAP).
XML Source (see within schema source)
<xsd:element maxOccurs="1" minOccurs="0" ref="c:name">
<xsd:annotation>
<xsd:documentation>
Human readable name for the account attribute.
This name may be displayd in tools and GUIs to
provide more
pleasant user experience, as the
native attribute names may look
quite frightening
(especially in
LDAP).
</xsd:documentation>
</xsd:annotation>
</xsd:element>

tns:outbound
Type:
tns:ValueConstructionType, complex content
Defined:
Defines how the attribute value is constructed in case of information flow from IDM to the resource, e.g. in case of provisioning. This may be a static value or an expression. In case an expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account to be changed Motivation: This is "value construction" type, it is using similar format that is used eleswhere in the system (e.g. in roles) and therefore a common expression processor can be used to process all of that. E.g. a single processor may take into a consideration both schema handling and dynamic attributes set by roles.
XML Source (see within schema source)
<xsd:element maxOccurs="1" minOccurs="0" name="outbound" type="tns:ValueConstructionType">
<xsd:annotation>
<xsd:documentation>
Defines how the attribute value is constructed
in
case of information flow from IDM to the
resource,
e.g. in
case of
provisioning.

This may be a static value or an expression.

In case
an expression is used,
the expression
variables
should be as
follows:
$user - the user to whom the account belongs
$account - the
account to
be changed

Motivation: This is
"value construction" type,
it is
using similar format that is used eleswhere in the
system
(e.g. in roles) and therefore a
common
expression processor can be
used to process all of
that. E.g. a single
processor may take into a
consideration both
schema handling and dynamic
attributes set by
roles.
</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/