Administration of schemata

The schemata administration is the tool of information architects. It is used to define object types and their content models. In doing so, information architects define which objects types are available and if and where they can be created in the content administration of the structure area. They also define which data can contain object types and how they are structured. In the content administration, components of the onion.net editor use this information to generate progressive forms for data recording from the content models.

The workingspace of the schemata administration also consists of object structure window and a object detail window.

Information architects can create objects of the type schema, user profile and module configuration in the schema administration. New schema types are created via the context menu; further schemas can be created below each schema. If a schema is clicked on, then it is displayed in the object detail window.

User profiles and module configurations extend the type “schema” to include instance names. The workspace of the schema administration consists of an object structure window and the object detail window. The object detail window contains, alongside schema definition, extensive configuration options.

• Defintion
  The definition of a schema is captured in the language XML Schema. This is a complex schema language for the description of XML object types.
• Child schemas
  If it should be possible to create other object types underneath an object type in the content administration, these object types must be linked in the field Child schemas.
• Settings
  The settings are subdivided into the tabs “General” and “Localization”.
  Under “General”, fundamental settings for the schema can be made. The schema can be marked as abstract, so that no instances can be created for this schema. Furthermore, it can be decided whether the data objects of this type can be versioned and whether the data objects (child schemas) located underneath them are to be sorted alphabetically. If the schema is located in the administration directly beneath the point “Schemas”, the superordinate schema that is not located in the module will also be configured.
  In the tab “localization”, the display name and icons for the schema can be assigned. If the display name is configured, then this will be displayed in the editor as a matter of priority, before the system name of the schema. The same goes for the icons. These are displayed in the structure tree or in the tabs for example.
• Child schemas
  If it is to be possible to create other object types below an object type in the content administration, then these must be linked in the tab “Child schemas”. Further schema can be added by dragging and dropping or via the schema selection that can be reached by a right-click of the mouse. Schemas are deleted via the context menu of the respective schema.
• Structure references
  The structure references list is the counterpart to the list in the tab “Child schemas”. All schemas are listed with instances under which further instances of the current schema may be created. As in the tab “Child schemas”, further schema can be added or existing schema deleted.
• Interface implementation
  In this tab, the interfaces are administrated which this schema is to implement. For this purpose, interfaces can either be added to the list by dragging and dropping or by right-clicking. Interfaces are deleted on the respective interface via the context menu.

Further objects can be created in the object structure window.

• Component binding
  Based on the schema definition, the form is generated in the content management system. The default components in the form can be replaced with own components using the component binding.
• Localization
  The form components are configured via the localization objects. This means that both language-independent settings, such as the width of a selection menu, and language-dependent settings, such as the naming of a label, can be made in these objects.
• Update script
  The use of update scripts is necessary if the module is already in use on other systems and the current schema has changed meaning that any data there may be must be revised. If the module is to now be updated on the other systems, then the script “upgrade” is executed. If the update of the module fails at a later time, then the script “downgrade” must be executed in order to restore the previous data status.

Name conventions

A schema is identified via its address. This must be unique across the system. It has proven successful to name schemas in the URI format.

A schema is renamed via the button “Rename” in the toolbar of the object detail window or the context menu of the schema.

Module configuration Data objects