Application schema
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.
API codes
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:type:person
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 std
or dc
namespaces.
Requirements files
Plugins describe their minimum requirements to operate in their requirements.schema
file.
Plugin local schema dictionaries
Writing JavaScript full of API codes is ugly, so the requirements.schema
files are also used to define the plugin local schema dictionaries.
These allow you to write, for example, A.Person
instead of ATTR['std:type:person']
, which looks so much nicer. The plugin tool checks that you’ve defined all the local names you use in your JavaScript.
The code examples in this documentation assume you are using a requirements.schema
file which has readable names for the standard schema objects.