Show the content of the object intended for diagnostics by system administrator. The out
put should be suitable to use in system logs at "debug" level. It may be multi-line, but in
that case it should be well indented and quite terse.
As it is intended to be used by system administrator, it should not use any developer terms
such as class names, exceptions or stack traces.
Returns a name of the type for this definition.
The type can be part of the compile-time schema or it can be defined at run time.
Examples of the former case are types like c:UserType, xsd:string, or even flexible
ones like c:ExtensionType or c:ShadowAttributesType.
Examples of the latter case are types used in
- custom extensions, like ext:LocationsType (where ext = e.g. http://example.com/extension),
- resource schema, like ri:inetOrgPerson (ri = http://.../resource/instance-3),
- connector schema, like TODO
In XML representation that corresponds to the name of the XSD type. Although beware, the
run-time types do not have statically defined structure. And the resource and connector-related
types may even represent different kinds of objects within different contexts (e.g. two
distinct resources both with ri:AccountObjectClass types).
Also note that for complex type definitions, the type name serves as a unique identifier.
On the other hand, for item definitions, it is just one of its attributes; primary key
is item name in that case.
The type name should be fully qualified. (TODO reconsider this)
This means that this particular definition (of an item or of a type) is part of the runtime schema, e.g.
extension schema, resource schema or connector schema or something like that. I.e. it is not defined statically.
Version of data model in which the item is likely to be removed.
This annotation is used for deprecated item to indicate imminent incompatibility in future versions of data model.
Elaborate items are complicated data structure that may deviate from
normal principles of the system. For example elaborate items may not
be supported in user interface and may only be manageable by raw edits
or a special-purpose tools. Elaborate items may be not fully supported
by authorizations, schema tools and so on.
True for definitions that are more important than others and that should be emphasized
during presentation. E.g. the emphasized definitions will always be displayed in the user
interfaces (even if they are empty), they will always be included in the dumps, etc.
TODO probably deprecated, isn't it?
Returns display name.
Specifies the printable name of the object class or attribute. It must
contain a printable string. It may also contain a key to catalog file.
Returns null if no display name is set.
Corresponds to "displayName" XSD annotation.
Specifies an order in which the item should be displayed relative to other items
at the same level. The items will be displayed by sorting them by the
values of displayOrder annotation (ascending). Items that do not have
any displayOrder annotation will be displayed last. The ordering of
values with the same displayOrder is undefined and it may be arbitrary.
Returns help string.
Specifies the help text or a key to catalog file for a help text. The
help text may be displayed in any suitable way by the GUI. It should
explain the meaning of an attribute or object class.
Returns null if no help string is set.
Corresponds to "help" XSD annotation.
Returns generic definition annotation. Annotations are a method to
extend schema definitions.
This may be annotation stored in the schema definition file (e.g. XSD)
or it may be a dynamic annotation determined at run-time.
Annotation value should be a prism-supported object. E.g. a prims "bean"
(JAXB annotated class), prism item, prism value or something like that.
EXPERIMENTAL. Hic sunt leones. This may change at any moment.
Note: annotations are only partially supported now (3.8).
They are somehow transient. E.g. they are not serialized to
XSD schema definitions (yet).