Minor typos and simplifications (#34)

docs/Appendix A - Class ID Format.md

@@ -32,7 +32,7 @@ For example, for a standard class `NcXXX` whose lineage key is **1•2•12•7*
 
 A class not defined by NCA is called a _**non-standard class**_, and its classId is called a _**non-standard classId**_. A non-standard classId contains at least one authority key.
 
-A non-standard classId is constructed by inserting an authority key into the lineage key immediately before the index of the first non-standard class. In the following examples the authority key is indicated by "**A**", as in **{i(1)•i(2)•A•i(3) ...}**.
+A non-standard classId is constructed by inserting an authority key into the lineage key immediately before the index of the first non-standard class. In the following examples the authority key is indicated by "**A**".
 
 The interpretation of a lineage key that includes an authority key **A** is as follows:
 

docs/Components.md

@@ -4,7 +4,7 @@
 
 NCA is based on two interrelated models:
 
-- The [Framework](https://specs.amwa.tv/ms-05-02), which defines the repertoire of NCA control and monitoring functions and the common mechanisms that they use. The Framework has two components:
+- The [Framework](https://specs.amwa.tv/ms-05-02), which defines the NCA control and monitoring models and the common mechanisms that they use. The Framework has two components:
 
   - **Control model:** An inheritance tree of control classes that specify NCA's control and monitoring repertoire. These classes are summarized in the [Control Model](Control%20Model.md) and defined normatively in the framework collection of [model definitions](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html).
 

docs/Control Model.md

@@ -1,26 +1,26 @@
 # Control Model
 
-The NCA Control Model is a singly-inherited tree of classes. Each NCA class defines a particular control or monitoring API that devices implement.
+The Control Model is a singly-inherited tree of classes. Each control class defines a particular control or monitoring API that devices implement.
 
-NCA [control classes](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#control-classes) can have three kinds of elements:
+[Control classes](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#control-classes) can have three kinds of elements:
 
-- **Properties**. These are control and status parameters.
+- **Properties** These are control and status parameters.
 
-- **Methods** **.** Methods represent actions a Controller can perform on the object.
+- **Methods** Represent actions a Controller can perform on the object.
 
-- **Events**. Events are defined conditions that arise inside objects. For example, all objects include the [PropertyChanged](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/NcObject.html#propertychanged-event) event, which is raised (i.e. occurs) when the value of a property of the object has changed.
+- **Events** These are defined conditions that arise inside objects. For example, all objects include the [PropertyChanged](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/NcObject.html#propertychanged-event) event, which is raised (i.e. occurs) when the value of a property of the object has changed.
 
 The event and subscription mechanism is described further in [Events, Notifications and Subscriptions](Core%20Mechanisms.md#events-notifications-and-subscriptions).
 
-NCA 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 NCA class tree, while others can take entirely different approaches. Such choices are outside NCA's scope.
+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](Identification.md).
 
 ## Class inheritance
 
-The NCA 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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject). Thus, a control class is the outcome of a **class inheritance hierarchy**.
+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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject). Thus, a control class is the outcome of a **class inheritance hierarchy**.
 
-When a 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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/NcObject.html#propertychanged-event). All classes in the model inherit directly or indirectly from [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject) ; therefore, they all have **PropertyChanged** events. Consequently, a controller can subscribe to property-value changes for any object in the NCA device.
+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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/NcObject.html#propertychanged-event). All classes in the model inherit directly or indirectly from [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#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._
 
@@ -32,17 +32,17 @@ These rules are:
 
 1. New classes are defined by inheritance from existing ones.
 
-1. A new ("child") class MUST implement all the properties, methods, and events of the class ("parent") from which it inherits.
+1. A new ("child") class implements all the properties, methods, and events of the class ("parent") from which it inherits.
 
 1. A child class can expand its parent's definition by defining additional properties, methods, and/or events.
 
-1. A child class's inherited elements MUST retain the respective element IDs (see [Identification](Identification.md)) from its parent class.
+1. A child class's inherited elements retains the respective element IDs (see [Identification](Identification.md)) 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](https://specs.amwa.tv/ms-05-02). These classes are defined in the NCA control model, via an inheritance hierarchy of control classes that descends from [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject).
+For NCA to meet its interoperability objectives, a repertoire of common control class models are defined in the [NMOS Control Framework](https://specs.amwa.tv/ms-05-02). These classes are defined in the control model, via an inheritance hierarchy of control classes that descends from [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject).
 
-NCA 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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject). All the classes in a category inherit from that category's base class. Thus, each category is a subtree of the overall hierarchy.
+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](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#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.
 

docs/Core Mechanisms.md

@@ -42,7 +42,7 @@ Subscriptions and their implementation are protocol-specific.
 
 A notification message is essentially a callback command whose parameters depend on the type of event. However, unlike actual commands, a notification does not require a response.
 
-The parameters of notifications depend on the type of event. In general, event parameters are designed to give full detail about the event, so that Controllers receiving events can act on them immediately, without having to query the Device further.
+The parameters of notifications depend on the type of event. In general, event parameters are designed to give full details about the event, so that Controllers receiving events can act on them immediately, without having to query the Device further.
 
 ### The PropertyChanged event
 
@@ -60,7 +60,7 @@ We refer to an object contained by a block as a _member_ of that block. [NcBlock
 
 ### Class discovery
 
-If a Controller does not have _a priori_ knowledge of a device's class definitions, it can discover the details of those definitions using the NCA _class discovery_ mechanism. This mechanism returns descriptors to the Controller for each class and datatype the device uses. These descriptors are sufficient for the Controller to construct well-formed API calls to the device; however, they do not describe the semantics of such calls.
+If a Controller does not have _a priori_ knowledge of a device's class definitions, it can discover the details of those definitions using the _class discovery_ mechanism. This mechanism returns descriptors to the Controller for each class and datatype the device uses. These descriptors are sufficient for the Controller to construct well-formed API calls to the device; however, they do not describe the semantics of such calls.
 
 The class discovery mechanism is available through the [NcClassManager](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Managers.html#class-manager).
 

docs/Definitions.md

@@ -1,6 +1,6 @@
 # Definitions
 
-Definitions and abbreviations for this draft
+Definitions and abbreviations used in the architecture, framework and protocol specifications.
 
 **Control** The capability to affect and/or monitor a product's function. In this document, _control_ usually implies _network control_, defined next.
 
@@ -16,29 +16,29 @@ Definitions and abbreviations for this draft
 
 **Control class** Pattern for constructing control objects.
 
-**Control object** Realized instance of a control class.
-
-**Control class** or just **subclass**: a class created by inheritance from another ("parent" ) class. Synonym of "child class".
+**Control object** Instance of a control class.
 
 **Control protocol** Definitions of message formats, data flows, data serializations, and exchange rules for accessing control APIs.
 
-**Framework mechanism** Architectural mechanism essential to NCA operation in any type of device. Conformant Devices implement all of the Framework Mechanisms applicable.
+**Core mechanisms** Architectural mechanisms that are essential to the operation of NCA in all devices.
+
+**Framework** Models (classes and datatypes) and Core Mechanisms essential to NCA operation in any type of device. Conformant Devices implement all of the Framework models and mechanisms applicable.
 
-**Feature-set mechanism** conditional mechanism required when a device implements a specific feature set.
+**Feature set** Conditional models (classes and datatypes) required for devices to expose specific functionality.
 
-**Sequence** Written **sequence\<V\>:** an ordered set of values of datatype **V** that is accessed via an index. **V** can be a simple datatype or an object.
+**Sequence** Written **sequence\<V\>:** An ordered set of values of datatype **V** that is accessed via an index. **V** can be a simple datatype or an object.
 
 **Block** or **block object.** An instance of a block class.
 
-**Block class** Subclass of the class **NcBlock**.
+**Block class** Class which inherits from **NcBlock**.
 
 **Block member** An object contained by a block.
 
 **Nested block** A block contained by another given block, as in "block A is nested inside block B".
 
 **Root block** The single fundamental block in a device that contains all other control objects and blocks.
 
-**Owning block** _or_ **owner** The block that contains a given object.
+**Containing block** _or_ **owner** The block that contains a given object.
 
 **Touchpoint** Linkage item which indicates the association between an NCA item and an identified resource in another control environment (e.g. NMOS IS-xx).
 

docs/Device Model.md

@@ -8,7 +8,7 @@ A block can contain other blocks. A contained block is said to be **nested** ins
 
 As illustrated in the figure `NCA Device` below, the Device model defines a Device as a [root block](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Blocks.html) accompanied by a few control objects. In simple devices, these objects might be contained directly in the root block; in more complex devices, they are contained in a hierarchy of blocks nested inside the root block.
 
-An object contained in a block is called a _**member**_ or _**member object**_ of that block.
+An object contained in a block is called a _**member**_ of that block.
 
 A Device can have certain application functions the designers wish not to be network-controllable. Such functions might not be represented in the root block or its nested blocks, and consequently might not be in the device's control API.
 
@@ -30,6 +30,6 @@ The device model is created by instantiating control model classes as shown in t
 |:--:|
 | _**Device model**_ |
 
-On the left of the figure is the control model with its WebIDL fragment. In this case, only two control model classes are shown: [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject), which is the parent of everything, and [NcBlock](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncblock), which is the abstract base class upon which all block classes are built.
+In this case, only two control model classes are shown: [NcObject](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject), which is the parent class of all control classes, and [NcBlock](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncblock), which is the base class upon which all block classes are built.
 
 On the right is an example Device model showing blocks **X** and **Y**.

docs/Identification.md

@@ -21,7 +21,7 @@ Compact read-only handle that uniquely identifies an object within its device. S
 
 | Datatype                                                                            | Scope    | Lifespan  |
 | ----------------------------------------------------------------------------------- | -------- | --------- |
-| [NcOid](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncoid) | Device   |           |
+| [NcOid](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncoid) | Device   | Constant until reboot          |
 |                                                                                     |          |           |
 
 ### Element ID
@@ -44,7 +44,7 @@ Static, read-only text property that names an object within the block to which i
 
 ### Role path
 
-Unique identifier of an object within a device model. Sequence of strings, consisting of the `role` values of all the object's containing blocks, starting from the root block and ending with the object's own `role` value.  
+Uniquely identifies the location of an object within a device model. Sequence of strings, consisting of the `role` values of all the object's containing blocks, starting from the root block and ending with the object's own `role` value.  
 Role paths are enabled by the existence of [blocks](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncblock) in the device model.
 
 | Datatype                                                                                      | Scope    | Lifespan  |
@@ -72,7 +72,7 @@ UUID that uniquely identifies the particular product that constitutes the Device
 
 ## NCA-NMOS identity mapping
 
-NCA's **Touchpoint** feature allows applications to attach a list of _touchpoints_ to any NCA object. A touchpoint is a defined relation between an entity in NCA and an entity in a different namespace. Stored in property [NcObject.touchpoints](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject).
+NCA's **Touchpoint** feature allows applications to attach a list of _touchpoints_ to any control object. A touchpoint is a defined relation between an entity in NCA and an entity in a different namespace. Stored in property [NcObject.touchpoints](https://specs.amwa.tv/ms-05-02/branches/v1.0-dev/docs/Framework.html#ncobject).
 
 | Datatype                                                                                          | Scope                  | Lifespan  |
 | ------------------------------------------------------------------------------------------------- | ---------------------- | --------  |

docs/Scope.md

@@ -23,7 +23,7 @@ NCA's specification is designed to complement and interoperate with the existing
 
 **NCA is not a device or controller implementation specification.** NCA's features and structures serve to define NCA device Application Programming Interfaces (APIs) that can be used for device control, but the internal programming structures behind those APIs are strictly out of NCA's scope.
 
-**NCA is not a user interface specification.** The NCA control model defines numerous elements with application functions (switches, indicators, gain controls, etcetera), but these elements are embodied only as abstractions in a NCA device control model. How, whether, or when they are represented in a user control interface is out of NCA's scope.
+**NCA is not a user interface specification.** The NCA control model defines numerous elements with application functions (switches, indicators, gain controls etc.), but these elements are embodied only as abstractions in a NCA device control model. How, whether, or when they are represented in a user control interface is out of NCA's scope.
 
 ## NCA Documentation Structure