Networked Media Open Specifications

Control Model

←Components · Index↑ · Device Model→

The Control Model is a singly-inherited tree of classes. Each control class defines a particular control or monitoring API that devices implement.

Control classes can have three kinds of elements:

The event and subscription mechanism is described further in Events, Notifications and Subscriptions.

Control classes are interface-defining classes that imply nothing about the programming classes inside actual products. Some Device developers can elect to use object-oriented programming environments with software class structures that mirror the Control class tree, while others can take entirely different approaches. Such choices are outside of NCA’s scope.

Each property, method, and event of a class has a unique identifier. These identifiers (element identifiers) are described in the Identification.

Class inheritance

The control model defines a class inheritance mechanism, in which the various classes’ definitions are derived from the definitions of other, more elementary classes, with everything ultimately leading up (if you think of ancestry diagrams) or down (if you think of trees) to a single fundamental base named NcObject. Thus, a control class is the outcome of a class inheritance hierarchy.

When a control class inherits from another class, all of its properties, methods, and events are inherited. A notable example of this mechanism is the PropertyChanged event. PropertyChanged is defined in NcObject. All classes in the model inherit directly or indirectly from NcObject ; therefore, they all have PropertyChanged events. Consequently, a controller can subscribe to property-value changes for any object in the Device model.

This document will visualize the class inheritance hierarchy as a tree in inverted form, with NcObject at the top, and successive refinements of NcObject extending downward. Our tree will be a trailing vine.

Inheritance rules

Over time, the NCA-defined tree of classes will grow. Additionally, product developers will likely extend the public-defined tree with proprietary classes to cover product-specific functions. To cover both of these cases, NCA has expansion rules that ensure the tree expands in a compatible manner, in which new classes, whether arising from NCA growth or proprietary extension, coexist harmoniously with legacy ones.

These rules are:

  1. New classes are defined by inheritance from existing ones.

  2. A new (“child”) class implements all the properties, methods, and events of the class (“parent”) from which it inherits.

  3. A child class can expand its parent’s definition by defining additional properties, methods, and/or events.

  4. A child class’s inherited elements retains the respective element IDs (see Identification) from its parent class.

Class hierarchy

For NCA to meet its interoperability objectives, a repertoire of common control class models are defined in the NMOS Control Framework. These classes are defined in the control model, via an inheritance hierarchy of control classes that descends from NcObject.

Control classes are specified in several categories and subcategories. Each category or subcategory has its own base class that inherits directly or indirectly from NcObject. All the classes in a category inherit from that category’s base class. Thus, each category is a subtree of the overall hierarchy.

Figure NCA Control Model illustrates the NCA class tree, and shows the categories.

NCA Control Model
NCA control model

Class categories

The categories shown in figure NCA Control Model are as follows:

Datatype definitions

To support the class definitions, the control model also contains an extensive set of datatype definitions. These definitions specify the scalar and structural datatypes used to define class properties and method parameters.

←Components · Index↑ · Device Model→