diff --git a/.gitignore b/.gitignore
index e43b0f988953ae3a84b00331d0ccf5f7d51cb3cf..271b138e0f77c43eadd88db4e2ebba2d06fa8489 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
.DS_Store
+/.project
diff --git a/SDT/schema4.0/docs/.gitignore b/SDT/schema4.0/docs/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..098beee23159dafe80282cdcd4fa14d05b253e17
--- /dev/null
+++ b/SDT/schema4.0/docs/.gitignore
@@ -0,0 +1,3 @@
+/.Introduction.md.html
+/.SDT_Components.md.html
+/.SDT_JSON.md.html
diff --git a/SDT/schema4.0/docs/Introduction.md b/SDT/schema4.0/docs/Introduction.md
index 08ad356e43eb82a7356e39e7bed122420ba085d9..194ec39d21235074ae05e1275f465200f062bc5b 100644
--- a/SDT/schema4.0/docs/Introduction.md
+++ b/SDT/schema4.0/docs/Introduction.md
@@ -47,7 +47,7 @@ This section provides an overview about the SDT 4.0 definitions and element hier
| Device | Physical, addressable, identifiable appliance/sensor/actuator. |
| Sub-Device | A device (usually one of several) which may be embedded in a Device and/or is addressed via another Device. |
| ModuleClass | Specification of a single service with one or more service methods, the involved abstracted data model and related events. The expectation is that each separate service which may be used in many kinds of Devices (like PowerON/OFF, Open/Close, ...) will be described by a ModuleClass which can be re-used in many Device definitions. |
-| Module | Instantiation of a ModuleClass for a specific Device or SubDevice|
+
**Definitions of SDT Elements.**
diff --git a/SDT/schema4.0/docs/SDT_Components.md b/SDT/schema4.0/docs/SDT_Components.md
index bac78e0a486bdf17bfa377f36efe0921e021ef8e..a1188edc40575bbb2dfc8c9f737c04a9c055e83e 100644
--- a/SDT/schema4.0/docs/SDT_Components.md
+++ b/SDT/schema4.0/docs/SDT_Components.md
@@ -3,7 +3,7 @@
[Domain](#Domain)
[Device](#Device) | [SubDevice](#SubDevice)
[Property](#Property)
-[Module and ModuleClass](#ModuleClass)
+[ModuleClass](#ModuleClass)
[Action](#Action)
[Arg](#Arg)
[DataPoint](#DataPoint)
@@ -51,7 +51,7 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
#### Elements
- **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
- **Imports** : XML import/include of other XML files. Optional.
-- **[Module](#ModuleClass)** : A list of those *Module* components that are global to the whole domain. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of those *ModuleClass* components that are global to the whole domain. Optional.
- **[Devices](#Device)** : a List of *Devices* components. Optional.
#### Example
@@ -64,9 +64,9 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
<!-- Import other SDTs via XInclude's include mechanism -->
<xi:include href="./dal-core.xml" parse="xml" />
</Imports>
- <Modules>
- <!-- List of Domain global Modules goes here -->
- </Modules>
+ <ModuleClasses>
+ <!-- List of Domain global ModuleClasses goes here -->
+ </ModuleClasses>
<Devices>
<!-- List of Devices goes here -->
</Devices>
@@ -79,13 +79,13 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
-The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [Modules](#ModuleClass).
+The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass).
For each physical device on the network at least one *Device* **must** be defined. If the physical device is a simple device, i.e. it does not contain embedded devices, e.g. a light switch, it does not include further [SubDevices](#SubDevices). On the other hand, if the physical is a compound device, i.e. it does contain embedded devices that can be addressed separately, the *Device* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices.
An example for a compound device is a connected power-strip where each of the sockets can be switched on and off individually. The power-strip itself can provide functions such as "all sockets off" and "overall power consumption".
-*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModulesClasses of the same or another [Domain](Domain).
+*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClasses(#ModuleClass) of the same or another [Domain](#Domain).
#### Attributes
- **id** : The identifier for that *Device*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
@@ -94,7 +94,7 @@ An example for a compound device is a connected power-strip where each of the s
- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
- **[Properties](#Property)** : Further meta-data (or properties) about the *Device*. Optional.
-- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *Device*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *Device*. Optional.
- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
#### Example
@@ -104,9 +104,9 @@ An example for a compound device is a connected power-strip where each of the s
<Properties>
<!-- The list of Properties for the Device goes here-->
</Properties>
- <Modules>
- <!-- List of Modules local to the Device goes here-->
- </Modules>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
<SubDevices>
<!-- List of Sub-Devices of the Device goes here-->
</SubDevices>
@@ -128,7 +128,7 @@ An example for a compound device is a connected power-strip where each of the s
#### Elements
- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
-- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
#### Example
@@ -137,9 +137,9 @@ An example for a compound device is a connected power-strip where each of the s
<Properties>
<!-- The list of Properties for the Device goes here-->
</Properties>
- <Modules>
- <!-- List of Modules local to the Device goes here-->
- </Modules>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
</SubDevice>
---
@@ -173,26 +173,23 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
---
<a name="ModuleClass"/></a>
-### Module and ModuleClass
+### ModuleClass
-**Module**
-
-*Module* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). There could be an infinite number of possible functionalities, however it is recommended to identify a not-too-large selection of them as generic examples (called *"*ModuleClasses*, see below) and allow for additional proprietary extensions. In a particular [Domain](#Domain) there will be one *Module* for each of the agreed *ModuleClasses* plus additional ones for each extension of a *ModuleClass*.
+**ModuleClass**
-The advantage of identifying a subset of generic *ModuleClasses*, described below, is that any suitable high-level software would then be able to "parse" the generic functionality for all compliant appliances, even if the proprietary parts could not be interpreted by the software.
+*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can be extended from another *ModuleClass* with additional functionalities.
-Every [Device](#Device) can then be described by a collection of *Modules* (functionality). In the simplest examples, where there are no extensions needed, each *ModuleClass* has exactly one "child" Module ... in such cases the software developer can consider the two terms to be the same.
+Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).
-The relationship between a *ModuleClass* and a *Module* is very similar to the specification of a class and an instantiated object in an object oriented programming language.
+The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [Device](#Device).
-**ModuleClass**
-
-The set of *ModuleClasses* is defined at the [Domain](#Domain) level. Each one describes some functionality (services). In principle there could be an infinite number of *ModuleClasses* (as noted above), for every kind of functionality found in UPnP, ZigBee and all the other automation protocols ... However that would not simplify the job of software developers at all! Therefore, HGI recommends that a finite and convenient number of prototypical *ModuleClasses* are re-used as much as possible (within a Domain at least).
+In principle there could be an infinite number of *ModuleClasses*, for every kind of functionality found in UPnP, ZigBee and all the other automation protocols ... However that would not simplify the job of software developers at all! Therefore, oneM2M recommends that a finite and convenient number of prototypical *ModuleClasses* are re-used as much as possible (within a Domain at least). oneM2M TS-0023 specifies a set of such standardized ModuleClasses (as well as Device models).
Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "PanUP/DOWN", "ReadTemperature", etc. Those examples make it apparent that various read/write usage of parameters, invoking of actions and waiting for events might be needed in the different *ModuleClasses*, and a guideline for those structures is explained below.
+
#### Attributes
- **name** : Name of the *Module* or *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
- **optional**: Boolean that indicates whether a *Module* or *ModuleClass* is optional or mandatory. Optional, the default is *false*.