-
Notifications
You must be signed in to change notification settings - Fork 10
Object Interfaces
Object interfaces are defined in YAML files (*.yml) within the defs/objects/data directory, linked as obj/data. Object interface define the core object structures used within the system and in particular the special class of persisted objects called resources.
An example object is:
# Base type for all events in the system Event: origin: "" # the origin of the event (content specific to subtype). Mostly a resource id origin_type: "" # the type of origin (e.g. resource type, etc) or empty description: "" # readable description of the event (not required) ts_created: "" # timestamp of event created in millis in UNIX epoch base_types: [] # List of event super types sub_type: "" # A specialization of the event_type expressed by this object type (or empty) actor_id: "" # The actor ID requesting the action causing the event
This defines a single object type (Event), provides a description comment, defines object fields, types and default values. Default values and types are conflated, e.g. "foo" is type string. Objects can have description comments and decorators
New object types can inherit from base types using the following syntax:
# Event indicating that a resource changed its life cycle or was created. ResourceLifecycleEvent: !Extends_Event lcstate: "" lcstate_before: "" availability: "" availability_before: "" transition_event: ""
This defines a strict tree of types. Subtypes inherit all fields (attributes) of all their base types and are only allowed to add new fields and must not change the definition of fields of their base types.
The interface parser is one pass and therefore depends on the order in which the yml files are processed. Except for a select set of system files, directories are processed in alphabetical order and within the files. If objects use other types with the same file, a line with only three dashes (---) need to be added between the two types.
Resources are objects that inherit from the Resource object. These objects are managed by the Resource Registry and in particular are persisted within the system's database. Every resource has a unique identifier and can be referenced and updated thereby. Resources have attributes.
Resources have a lifecycle state (lcstate attribute), availability state and visibility.
Associations are separate objects with their own identity that reference a subject resource and an object resource by ID and have a predicate, e.g. hasOwner. Because associations are separate objects, they belong to neither subject nor object, they can be added and removed without modifying the referenced resource objects.
The system Resource Registry enables flexible query of resources through their associations, similar to a graph database (e.g. neo4j) or an RDF triple store.