diff --git a/SDT/schema4.0/build.xml b/SDT/schema4.0/build.xml
index 55bf6408067c37ae017bb263286f05c00bdfc0c3..d4b8f5e8d0b261acbc5ef83daf066a389374fd64 100644
--- a/SDT/schema4.0/build.xml
+++ b/SDT/schema4.0/build.xml
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8" ?>
-<!-- - HGI Device Abstraction Layer - - - - - - - - - - - - - - - - - - - - -->
+<!-- SDT - Smart Device Template Build File -->
<!-- -->
-<!-- Extends the standard build with targets for: -->
-<!-- - generate XML schema the from Relax NG (xml) description -->
-<!-- - validate DAL documents against the XML Schema -->
-<!-- - generate HTML documentation from DAL documents -->
+<!-- Extends the standard build with targets for: -->
+<!-- - generate XML schema the from Relax NG (xml) description -->
+<!-- - validate DAL documents against the XML Schema -->
+<!-- - generate HTML documentation from DAL documents -->
<project name="importing" basedir="." default="schemas">
<import file="etc/common.xml"/>
diff --git a/SDT/schema4.0/docs/Introduction.md b/SDT/schema4.0/docs/Introduction.md
index 7cc260eeea2e59c669eb99b702ceb92139809a2e..99e6e3446508d48d39bf8a2510a017c46eb7c93d 100644
--- a/SDT/schema4.0/docs/Introduction.md
+++ b/SDT/schema4.0/docs/Introduction.md
@@ -1,10 +1,19 @@
-# Introduction to the SDT
+# Introduction to the Smart Device Template
-The SDT (Smart Device Template) is an initiative from HGI to find consensus amongst various SDOs and industry alliances to derive a common approach for device modelling. HGI and partners have the approach to agree on a set of automation commands, following a common syntax, which are sufficient to model most home appliance functions.
+The Smart Device Template (SDT) is an initiative from [oneM2M](http://www.onem2m.org) to find consensus amongst various SDOs and industry alliances to derive a common approach for device modeling. oneM2M and partners have the approach to agree on a set of automation functionalities, following a common syntax, which are sufficient to model most device functions.
-At the time of writing, every software developed for home gateways or internet-of-things gateways needs to be capable of using various different protocols (ZigBee, UPnP, EchonetLite, DECT ULE, etc) to interact with a range of devices designed for the home environment. This adds extreme overheads in integrating, checking and updating code. The purpose of SDT is to describe devices and device services in a way which is independent of the LAN technology, in a format which is convenient and reliable for integration in modern code (Java, C/C++, ...).
+Originally initiated by the [Home Gateway Initiative (HGI)](http://www.homegatewayinitiative.org), oneM2M is now the owner and maintainer of the SDT.
-The key goals of the SDT are: (1) keep it simple, especially for manufacturers to contribute device information; (2) modularity for functions and device types; (3) make it easy for developers to create unified APIs; (4) be independent of underlying home-area network technologies; (4) enable extendibility of the system in place without service interruption; (5) allow a pass-through mechanism to enable use of proprietary or technology-specific functions.
+At the time of writing, every software developed for Internet-of-Things gateways, for example gateways for home automation, needs to be capable of using various different protocols (ZigBee, ZWave, KNX, OPC UA, EchonetLite, DECT ULE, etc) to interact with a range of devices designed for the IoT environment. This adds extreme overheads in integrating, checking and updating code. The purpose of SDT is to describe devices and device services in a way which is independent of the LAN technology and protocols, in a format which is convenient and reliable for integration in modern code (Java, C/C++, Go, Python, ...).
+
+The key goals of the SDT are:
+
+1. keep it simple, especially for manufacturers to contribute device information;
+2. modularity for functions and device types;
+3. make it easy for developers to create unified APIs;
+4. be independent of underlying LAN technologies and protocols;
+5. enable extendibility of the system in place without service interruption;
+6. allow a pass-through mechanism to enable use of proprietary or technology-specific functions.
In general a description of device (or complex appliance) behaviour can be made in many ways, with various kinds of constraints:
@@ -12,56 +21,53 @@ In general a description of device (or complex appliance) behaviour can be made
2. moderate constraints (e.g. using XML and a related extensible XSD template)
3. strict constraints (typical for a device certified to interoperate with a specific LAN protocol)
-HGI chose to use the approach "moderate constraints" (XSD based) because for software development it offers ease of use and a good compromise. In particular, if there are few or no constraints on control parameters then few automatic checks can be made to detect if the software parameters are appropriate for each device integrated. XML and XSD languages were chosen because they are familiar to many developers, can be parsed with common software tools, and can still be created and interpreted by humans if necessary.
+oneM2M chose to use the approach "moderate constraints" (XSD based) because for software development it offers ease of use and a good compromise. In particular, if there are few or no constraints on control parameters then few automatic checks can be made to detect if the software parameters are appropriate for each device integrated. XML and XSD languages were chosen because they are familiar to many developers, can be parsed and validated with common software tools, and can still be created and interpreted by humans if necessary. SDT intended use is for modeling, not as a presentation layer protocol, therefore the size of individual templates is not important.
-HGI believes that Device information models based on XML and extensible XSD need some guidelines. If every possible feature of every existing LAN technology and appliance were allowed to be described in any formally correct way, then the results would be a modern Babel, no better than today's system of widely different and wildly competing automation protocols.
+oneM2M believes that Device information models based on XML and extensible XSD need some guidelines. If every possible feature of every existing LAN technology and appliance were allowed to be described in any formally correct way, then the results would be a modern Babel, no better than today's system of widely different and wildly competing automation protocols.
-Therefore HGI proposes to recommend a certain structure (template) for the information model(s), but to allow extensions. Naturally, the more industry consensus is achieved for a single recommended template, the greater the utility for software developers (and users).
+Therefore oneM2M proposes to recommend a certain structure (or template) for the information model(s), but to allow extensions. Naturally, the more industry consensus is achieved for a single recommended template, the greater the utility for software developers (and in the end users and customers).
-The SDT approach is to define re-usable basic functions (or services), labelled "ModuleClass" in the figure below, which can represent the typical functions found in many home automation systems, such as "on/off", "dim a lamp", "receive events from binary sensor", "read data from sensor", etc. Each ModuleClass is composed of a (small) number of actions, datapoint read/write operations, or asynchronous events. For example, an "on/off" ModuleClass would consist perhaps of just one Action, but a "ReadKeypad" Action might have a number of possible events, each with some data value and (usually) a sequence-ID or timestamp start/stop to indicate when and how long each key was pressed.
-
+The SDT approach is to define re-usable basic functions (or services), labelled "ModuleClass" in the figure below, which can represent the typical functions found in many IoT systems, such as "on/off", "dim a lamp", "receive events from sensor", "read data from sensor", etc. Each ModuleClass is composed of a (preferable small) number of actions, datapoint read/write operations, or asynchronous events. For example, an "on/off" ModuleClass would consist perhaps of just one Action, but a "ReadKeypad" Action might have a number of possible events, each with some data value and (usually) a sequence-ID or timestamp start/stop to indicate when and how long each key was pressed.
-
-**SmartHome Device Template (XSD) for a generic device (simplification)**
+
+**SmartHome Device Template for a generic device (UML, basic entities)**
-The SDT represents the device models introduced in the above figure by using an XSD schema to allow formal checking of compliance for XML device descriptions of specific appliances. The modularity goal in the XSD schema is achieved with re-usable XSD fragments ("ModuleClass" in the figure).
+The SDT represents the device models introduced in the above figure by using an XSD schema to allow formal checking of compliance for XML device descriptions of specific appliances. The modularity goal in the schema is achieved with re-usable XML fragments (for example the "ModuleClass" in the figure).
-Complex devices or appliances can then be described by an appropriate set or collection of the agreed XSD fragments (ModuleClasses), as indicated in the figure, which also shows an optional DeviceInfo XSD fragment to allow noting of static information such as device manufacturer name, device firmware version, etc etc.
+Complex devices or appliances can then be described by an appropriate set or collection of the agreed ModuleClasses, as indicated in the figure, which also shows an optional "Property" fragment to allow noting of static information such as device manufacturer name, device firmware version, etc.
-HGI has discussed with many SDOs to validate these concepts. SDT is designed to take into account the list of "services" compiled by the SAREF project (https://sites.google.com/site/smartappliancesproject/home).
+oneM2M has discussed with many SDOs to validate these concepts. SDT is designed to take into account the list of "services" compiled by the [SAREF project](https://sites.google.com/site/smartappliancesproject/home).
-The SDT supports the use of a set of templates for generic devices or appliances (e.g. for a dimmable lamp, a basic washing machine, etc, which would be specific instances of the "Device" object , which form the basis of APIs used by application developers. These templates can also be referenced by manufacturers creating XML documents to describe their specific products. For example, the SDT enables specification of a generic washing machine template, with on/off, set-wash-temperature, pause and a few other commands, which could be referenced by a manufacturer as the schema for a XML description of a basic model washing machine. The SDT allows for vendor-specific additional commands (ModuleClasses) to suit specific product types.
+The SDT supports the use of a set of templates for generic devices or appliances (e.g. for a *dimmable lamp*, a basic *washing machine*, etc), which would be specific instances of the "DeviceClass", which form the basis of APIs used by application developers. These templates can also be referenced by manufacturers creating XML documents to describe their specific Products. For example, the SDT enables specification of a generic washing machine template, with *on/off*, *set-wash-temperature*, *pause* and a few other commands, which could be referenced and extended by a manufacturer as the schema for an XML description of a specific washing machine product. The SDT allows for vendor-specific additional commands (ModuleClasses) to suit specific product types.
The interoperability benefits can potentially partially be obtained even without a fully complete interoperability of the SDT. For example, the most common functions can be modeled with SDT, and more particular functions can be modeled with technology-specific, proprietary, or seldom-used aspects.
-Various details about the recommended structure for SDTs are described in the next sections. The key point to keep in mind is that HGI sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of any complexity) and, at the other extreme, a rigid structure which could be 100% validated and lead to validated software APIs.
+Various details about the recommended structure for SDTs are described in the next sections. The key point to keep in mind is that oneM2M sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of any complexity) and, at the other extreme, a rigid structure which could be 100% validated and lead to validated software APIs.
## Definitions
-This section provides an overview about the SDT 4.0 definitions and element hierarchy. Terms to be described in detail in this section are:
+This section provides an overview about high-level SDT 4.0 definitions and element hierarchy. Terms to be described in detail in this section are:
| Term | Definition |
|------|------------|
-|Domain | Unique name, or "wrapper" which acts like a namespace, set by the organization creating the SDT, allowing reference to a package of definitions for the contained ModuleClasses and device definitions. Can be referenced when extending ModuleClasses. It has two possible uses: to select the scope of a technology domain, or to set the scope of a use case domain (like Home, SmartGrid, etc) |
-| 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. |
-| Product| A concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a DeviceClass but not yet an device instance. Examples are the shopping items (e.g. a smart watch) in an online digital store that can be ordered (but not necessarily manufactured) by a customer. |
-| 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. |
+|Domain | Unique name, or "wrapper" which acts like a namespace, set by the organization, company, or project creating the template, allowing reference to a package of definitions for the contained ModuleClasses and device definitions. Can be referenced when extending Products, ModuleClasses, and data types. It has two possible uses: to select the scope of a technology domain, or to set the scope of a use case domain (like Home, SmartGrid, etc) |
+|ProductClass | A concrete device model with deterministic device Properties and ModuleClasses, without optionality. It is deemed as a specialized implementation of a DeviceClass that can be manufactured. |
+|DeviceClass | A physical, addressable, identifiable appliance, sensor, or actuator. |
+|Sub-Device | A device (usually one of several) which may be embedded in or attached to a (full) device. It is not designed to be operated as a standalone 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 *DeviceClass* or *ProductClass* definitions. |
-**Definitions of SDT Elements.**
+A major decision, facilitating validation of code and signaling, was to describe services (functionality) of devices in terms of ModuleClasses made up of combinations of three kinds of elements:
-A major decision, facilitating validation of code and signalling, was to describe services (functionality) of devices in terms of ModuleClasses made up of combinations of three kinds of elements:
-
-1. DataPoints which are aspects of the Device that can be read/written,
+1. DataPoints which are aspects of a functionality that can be read and/or written,
2. Actions which consist of more complex sequences of operations;
-3. Events which can be signalled ("published") by devices asynchronously.
+3. Events which can be signaled ("published") by devices asynchronously.
-This ModuleClass structure is shown in the figure below and is a major part of the SDT which is illustrated in detail in the following figure:
+The ModuleClass structure is a major part of the SDT which is illustrated in detail in the following figure:
-
-**UML description of device functionality in terms of Actions, DataPoints and Events**
+
+**UML description of device functionality in terms of DataPoints, Actions, and Events**
## How should SDT work?
@@ -75,9 +81,9 @@ For the convenience of users and developers, it would also be possible to collec
## Related aspects which are out of scope of the SDT
-The SDT defines the structure of all compliant XML descriptions. Each XML description of a specific device is definable at the time of manufacture of the device and can therefore only contain "static" information: (a) manufacturer data in the form of documentation elements and properties, (b) device capability information detailing the firmware operations and types/meanings of input/output variables.
+The SDT defines the structure of all compliant XML descriptions. Each XML description of a specific device is definable at the time of manufacture of the device and can therefore only contain "static" information: (a) manufacturer data in the form of documentation elements and properties, and (b) device capability information detailing the firmware operations and types/meanings of input/output variables.
-NOT directly part of this work is a related but separate aspect of every gateway software development: a "device abstraction layer" which can translate between (1) software APIs written based on a particular SDT and (2) the "commands" expected by several different LAN protocols and their hardware controllers.
+NOT directly part of this work is a related but separate aspect of every gateway software development: a "device abstraction layer" which can translate between (a) software APIs written based on a particular SDT and (b) the "commands" expected by several different LAN protocols and their hardware controllers.
Programmers developing a "device abstraction layer" for software in a gateway need to create run-time representations of all the recognized devices, their operations and their actual states. This internal "information model" needs to be updated in real time as the devices and the users interact. Programmers may be tempted to use the SDT structure to organize their real-time information model, adding additional information elements for the current state of each device, for some kind of "history" of commands sent/acknowledged, the user etc.
@@ -85,6 +91,4 @@ The above is an efficient approach BUT it must be clear that the real-time state
---
-Click [here](SDT_Components.md) for detailed documentation about SDT.
-
-
+The detailed documentation about SDT components can be found [here](SDT_Components.md).
diff --git a/SDT/schema4.0/docs/SDT Build System Components and Licenses.md b/SDT/schema4.0/docs/SDT Build System Components and Licenses.md
index 962b1271297453113611581380691ac86c1758a2..b7763e496d884c5430eb5d1d37b1dc7f2d7f9abe 100644
--- a/SDT/schema4.0/docs/SDT Build System Components and Licenses.md
+++ b/SDT/schema4.0/docs/SDT Build System Components and Licenses.md
@@ -1,4 +1,4 @@
-# Build System Libraries and Licenses
+# SDT Build System Components and Licenses
The following libraries are used in the build system for the SDT.
## trang.jar
diff --git a/SDT/schema4.0/docs/SDT Build System.md b/SDT/schema4.0/docs/SDT Build System.md
index 8a73e2a04cf18cc95d2255e07119bf2e0b34f34e..69db86773ca5312661c8b6d3eccf843e3a3eb808 100644
--- a/SDT/schema4.0/docs/SDT Build System.md
+++ b/SDT/schema4.0/docs/SDT Build System.md
@@ -1,5 +1,5 @@
# SDT Build System
-This document describes the SDT build system and how to build the SDT and validate new contributions.
+This document describes the SDT build system and how to build the SDT and validate new templates and contributions.
The files referenced in this document point to version **4.0** of the SDT.
@@ -7,43 +7,47 @@ The files referenced in this document point to version **4.0** of the SDT.
- [SDT/schema4.0/](../..) : Base directory
- [SDT/schema4.0/src/](../src/) : Source files of the SDT.
- [domain.rng](../src/domain.rng) : RELAX NG file with the SDT schema definition. This is the source file that is converted to the actual schema definition *domain.xsd* during the build. See also [http://en.wikipedia.org/wiki/RELAX_NG](http://en.wikipedia.org/wiki/RELAX_NG).
- **Only edit this file when one wants to make changes to the SDT!**
- - [domain.xsd](../src/domain.xsd) : The SDT schema definition that is generated from *domain.rng*.
+ **Only edit this file when you want to make changes to the SDT!** See also [Editing](#Editing) below.
+ - [domain.xsd](../src/domain.xsd) : The actual SDT schema definition that is generated from *domain.rng*.
- [xml.xsd](../src/xml.xsd) : General schema definitions for the SDT
-- [SDT/schema4.0/test/](../test/) : This directory contains all XML files with SDT definitions that should be validated whether they conform to the SDT schema. This could be example definitions or contributions.
+- [SDT/schema4.0/test/](../test/) : This directory contains XML files with SDT definitions that should be validated whether they conform to the SDT schema.
+This could be example definitions or new templates and contributions. If you want to validate your newly created template put it into this directory and follow the steps descripted in [Validate SDT Templates](#Validate) below.
- [SDT/schema4.0/build.xml](../build.xml) : This is the definition file for the ant build system.
-- [SDT/schema4.0/etc/](../etc/), [SDT/schema4.0/style/](../style/) : internal directories for the build system. Please, don't make unnecessary changes to these files.
-- [SDT/schema4.0/etc/](../etc), [SDT/schema4.0/style/](../style/) : internal directories for the build system. Please, don't make unnecessary changes to these files.
- - [SDT/schema4.0/etc/dal.rnc](../etc/dal.rnc) : This file contains various configuration parameter to convert the file [domain.rng](../src/domain.rng) to schema file. **The important parameter to change when changing the namespace or the version number is**:
-
- default namespace xsl = "http://homegatewayinitiative.org/xml/dal/3.0"
-
- - [SDT/schema4.0/etc/schemas.xml](../etc/schemas.xml) : This file contains the header for the schema file. **This must be changed when changing the namespace or the version number.**
+- [SDT/schema4.0/etc/](../etc/), [SDT/schema4.0/style/](../style/) : internal directories for the build system. Please, don't make changes to these files.
+- [SDT/schema4.0/etc/](../etc), [SDT/schema4.0/style/](../style/) : internal directories for the build system. Only the following files should be changed if necessray. See the section [Editing](#Editing) below.
+ - [SDT/schema4.0/etc/dal.rnc](../etc/dal.rnc) : This file contains various configuration parameter to convert the file [domain.rng](../src/domain.rng) to schema file.
+ - [SDT/schema4.0/etc/schemas.xml](../etc/schemas.xml) : This file contains the header for the schema file.
+ - [SDT/schema4.0/etc/schema.xmlns](../etc/schema.xmlns) : This file defines the target namespace for the schema.
- [SDT/schema4.0/lib/](../lib/) : Tasks for the ant-based build system. See also [SDT Build System Components and Licenses](SDT%20Build%20System%20Components%20and%20Licenses.md).
## Installation
-- Install Java on your computer
-- Download and install Apache ant from [http://ant.apache.org](http://ant.apache.org)
-- Clone the SDT repository from GitHub:
- $ git clone https://github.com/Homegateway/SmartDeviceTemplate.git
+### Prerequisites
+- Java
+- Ant (at least version 1.8). See [http://ant.apache.org](http://ant.apache.org).
+
+### Installing SDT
+- Clone the SDT repository from oneM2M's GitLab:
+
+ $ git clone https://git.onem2m.org/MAS/SDT.git
## How to Use the Build System
-After cloning the repository go to the directory *SDT/schema* and run commands depending on what you want to achieve.
+After cloning the repository go to the directory *SDT/schema4.0* and run commands depending on what you want to achieve.
### Build the Schema
Running *ant* without any parameter builds the schema definition from the rng-definition [SDT/schema4.0/src/domain.rng](../src/domain.rng) and writes it to [SDT/schema4.0/src/domain.xsd](../src/domain.xsd)
- $ cd SDT/schema
+ $ cd SDT/schema4.0
$ ant
-### Validate SDT Definitions
+<a name="Validate"/></a>
+### Validate SDT Templates
You can use the build system to validate new SDT definitions or changes made to existing ones by running the following command:
- $ cd SDT/schema
+ $ cd SDT/schema4.0
$ ant validate
-The output after a successful validation should look like this:
+The output after a successful validation should look similar this:
>[schemavalidate] 2 file(s) have been successfully validated.
>BUILD SUCCESSFUL
@@ -56,18 +60,30 @@ Otherwise you most likely receive a stack trace or some other error messages. Se
---
+<a name="Editing"/></a>
## Editing
-As mentioned above, the actual schema definition is defined in the file [domain.rng](../src/domain.rng) and converted to the XML schema definition [domain.xsd](../src/domain.xsd) during the build process.
+As mentioned above, the actual schema definition is defined in the file [src/domain.rng](../src/domain.rng) and converted to the XML schema definition [src/domain.xsd](../src/domain.xsd) during the build process.
-**All changes to the schema must therefore be made in [domain.rng](../src/domain.rng), NOT [domain.xsd](../src/domain.xsd) !**
+**All changes to the schema must only be made to [src/domain.rng](../src/domain.rng), NOT [src/domain.xsd](../src/domain.xsd) !**
You may need to make additional changes in the following files, e.g. when the name space or the version number need to be adjusted.
-PLEASE ONLY EDIT THESE FILES IF NECESSARY.
+PLEASE EDIT THESE FILES ONLY IF NECESSARY.
- [SDT/schema4.0/build.xml](../build.xml)
-e.g. in the *ant* target "validate"
+e.g. change the *ant* target "validate" when you want to set another directory for the files for validation.
- [SDT/schema4.0/etc/dal.rnc](../etc/dal.rnc)
-e.g. the entry "default namespace xsl"
-- [SDT/schema4.0/etc/schema.xmlns](../etc/schema.xmlns)
-- [SDT/schema4.0/etc/schemas.xml](../etc/schemas.xml)
+The important parameter to update when changing the namespace or the version number is:
+
+ default namespace xsl = "http://www.onem2m.org/xml/sdt/4.0"
+- [SDT/schema4.0/etc/schema.xmlns](../etc/schema.xmlns)
+ This file must be updated when changing the namespace or the version number:
+
+ targetNamespace="http://www.onem2m.org/xml/sdt/4.0"
+ xmlns="http://www.onem2m.org/xml/sdt/4.0"
+ xmlns:xs="http://www.w3.org/2001/XMLSchema"
+- [SDT/schema4.0/etc/schemas.xml](../etc/schemas.xml)
+ Upate the namespace when changing the namespace or the version number:
+
+ <namespace ns="http://www.onem2m.org/xml/sdt/4.0" typeId="DAL"/>
+
diff --git a/SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png b/SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
index 057d2b288cfa5293c782f0106e52b288daf7e59f..67ee56e2689fd24bfb444f281c7bcbc594121fe6 100644
Binary files a/SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png and b/SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_simplified.png b/SDT/schema4.0/docs/images/SDT_simplified.png
index aebda03d0aed3007d010fa2117b2a51254999707..c1295aab52c307f87e3e7cdf0c7ee3a808c19b97 100644
Binary files a/SDT/schema4.0/docs/images/SDT_simplified.png and b/SDT/schema4.0/docs/images/SDT_simplified.png differ