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 arbitary 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 unambigous.

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.