The application schema is the types, attributes, labels, groups, and so on, which define the structure of the information managed in the application.
This schema is shared between:
- The plugins installed in the application
- The users, who are free to rename any of the entities in the schema, and add their own
- Common vocabulary, representing concepts common to all applications, such as People.
Rather than having separate types (roughly equivalent to database tables) for each plugin, the plugins share the fundamental underlying real world types, using the same attributes if possible, or adding their own if not.
This style promotes the platform coding style of many cooperating plugins, and only requires information to be entered once.
Because the user may rename all the schema objects, plugin code refers to them by API code. These are arbitrary strings which are not visible to the user in normal use of their application.
By convention, they’re namespaced, for example:
std is the namespace, in this case, the standard namespace of common concepts defined by the platform. The platform also uses the
dc namespace for the attributes derived from the Dublin Core metadata standard.
type is the kind of schema object. While strictly speaking unnecessary, it’s included to be unambiguous.
person is the name of the schema object. There may be more
: separators if there is hierarchy, for example,
std:type:person:staff where Staff is a sub-type of Person.
Choose your namespaces carefully. Don’t add to the
Plugins describe their minimum requirements to operate in their
Plugin local schema dictionaries
requirements.schema files are also used to define the plugin local schema dictionaries.
These allow you to write, for example,
A.Person instead of
The code examples in this documentation assume you are using a
requirements.schema file which has readable names for the standard schema objects.