diff --git a/LICENSE b/LICENSE
index 92666deff26cda52d05622288597d1dbd00e42a8..05bae5b61e70d4b745f34f61d88d56d7c31baf42 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,4 +1,4 @@
-Copyright 2018, oneM2M Partners Type 1
+Copyright 2019, oneM2M Partners Type 1
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
@@ -8,4 +8,4 @@ Redistribution and use in source and binary forms, with or without modification,
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
\ No newline at end of file
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/README.md b/README.md
index 90624122e355d98755329d6f6483823d23f37e5d..b1ea592c54f2fc0cd3e3770a9eec10283946b771 100644
--- a/README.md
+++ b/README.md
@@ -1,35 +1,41 @@
# Smart Device Template
-Repository for the Smart Device Template (SDT).
+Repository and documentation for the Smart Device Template (SDT).
**Version 4.0**
-Note that this project runs under the 3-Clause BSD License. Read the [LICENSE](LICENSE) in this repository, or refer to [https://opensource.org/licenses/BSD-3-Clause](https://opensource.org/licenses/BSD-3-Clause).
+The Smart Device Template is available under the 3-Clause BSD License. Read the [LICENSE](LICENSE) in this repository, or refer to [https://opensource.org/licenses/BSD-3-Clause](https://opensource.org/licenses/BSD-3-Clause).
-Any contributions made to this project must comply with the aforementioned license.
+Any contributions made to the Smart Device Template format must comply with the aforementioned license. Models defined by using the Smart Device Template can be published under different licenses.
## Quick Introduction
-The Smart Device Template (SDT) is a template which is used to model the capabilities, actions and events of connected devices. The intent of the SDT is to be able to model any type of connected device using a well accepted and standardised format. The main application of SDT is to enable a uniformly structured Application Programmer's Interface (API) to applications that need to interact with connected devices. Usually, these applications would communicate to devices using an Abstraction Layer as an intermediary logic. The Abstraction Layer "hides" the technology-specific, native language format of devices of different technology type from the applications.
+
+
+The Smart Device Template (SDT) is a template which is used to model the capabilities, actions and events of connected devices. The intent of the SDT is to be able to model any type of connected device using a well accepted and standardised format. The main application of SDT is to enable a uniformly structured Application Programmer's Interface (API) to applications that need to interact with connected devices. Usually, these applications would communicate to devices using an abstraction layer as an intermediary logic. The abstraction layer "hides" the technology-specific, native language format of devices of different technology type from the applications.
[Read the full Introduction.](SDT/schema4.0/docs/Introduction.md)
## Quick Links
-- ['domain.xsd' Version 4.0](SDT/schema4.0/src/domain.xsd)
-- [UML Diagram of the SDT 4.0](SDT/schema4.0/docs/UML%20Diagram.md) ([source](SDT/schema4.0/docs/SDT_UML.uxf))
+- [UML Diagram of the SDT 4.0](SDT/schema4.0/docs/UML%20Diagram.md) ([Umlet source](SDT/schema4.0/docs/SDT_UML.uxf)) : This UML diagram describes the various components of the SDT and their relations.
+- ['domain.xsd' Version 4.0](SDT/schema4.0/src/domain.xsd) : This is the XSD schema file that defines the SDT XML Schema.
-## Content
+## Documentation
You can find further Information here:
- [Introduction to the SDT](SDT/schema4.0/docs/Introduction.md)
- [SDT Components](SDT/schema4.0/docs/SDT_Components.md)
-- [JSON Serializatoin](SDT/schema4.0/docs/SDT_JSON.md)
-- [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md)
+- [JSON Serialization](SDT/schema4.0/docs/SDT_JSON.md)
- [Examples](SDT/schema4.0/docs/Examples.md)
+- [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md)
+
+## Further Readings
- [Links & References](SDT/schema4.0/docs/Links.md)
+- [FAQ](SDT/schema4.0/docs/FAQ.md)
- [Changelog](SDT/schema4.0/docs/Changelog.md)
+- [SDT Build System Components and Licenses](SDT/schema4.0/docs/SDT%20Build%20System%20Components%20and%20Licenses.md)
- [LICENSE](LICENSE)
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/Changelog.md b/SDT/schema4.0/docs/Changelog.md
index 6f3031a5ed332f7c9b700ba1f9dafe1b226aaa44..1ebec20041c53ff11b43dec07abca099b98d0cfe 100644
--- a/SDT/schema4.0/docs/Changelog.md
+++ b/SDT/schema4.0/docs/Changelog.md
@@ -1,16 +1,23 @@
# Changelog
## Changes in 4.0
-- Rename 'Device' to 'DeviceClass' [(issue#2)](https://git.onem2m.org/MAS/SDT/issues/2)
-- Remove 'Module' to simplify the SDT model [(issue#1)](https://git.onem2m.org/MAS/SDT/issues/1)
-- Introduced 'Product' for concrete model definition of real products. [(issue#6)](https://git.onem2m.org/MAS/SDT/issues/6)
-- Support JSON serialization [(issue#5)](https://git.onem2m.org/MAS/SDT/issues/5)
-- Support inheritance of 'DeviceClass' [(issue#3)](https://git.onem2m.org/MAS/SDT/issues/3)
-- Enum type ...
-- Data Type Facets ... [(issue#4)](https://git.onem2m.org/MAS/SDT/issues/4)
-- ...
-
-*Editor's note: the current change log is just an examplary list (a projection), which lists some initial thoughts that the group is working on based on previous discussion. It needs to be revisited according to all implemented features before SDT4.0 publication.*
+- Renamed ``<Device>`` to ``<DeviceClass``>.
+- Removed ``<Module>`` to simplify the SDT model.
+- Introduced ``<ProductClass`` for concrete model definition of real products.
+- Introduced complex ``<EnumType>`` data type. Removed ``enum`` data type from ``BasicTypes``.
+- Added ``void`` from ``BasicTypes``.
+- Introduced inheritance / extending of ``<DataType>``.
+- Added support for defining ``<DataType>`` on ``<Domain>`` level.
+- Changed ``<Extend>`` mechanism. Now one can explicitly include or exclude certain sub-components from the parent.
+- Added support of ``semanticURL`` attribute for all components.
+- Added ``optional`` attribute to ``<Arg>``.
+- Added ``default`` attribute to ``<Arg>``.
+- Added ``default`` attribute to ``<DataPoint``.
+- Unified all component identifiers, names etc to XSD type ``name``.
+- Introduced JSON serialization guidelines.
+- Changed case of ``<Imports>`` element.
+- Added more test cases and example templates to the [test](../test) directory.
+- Changed the license to [3-Clause BSD License](https://opensource.org/licenses/BSD-3-Clause).
## Changes in 3.0
- Renamed ``<RootDevice>``to ``<Device>`` and ``<Device>`` to ``<SubDevice>``,
diff --git a/SDT/schema4.0/docs/Examples.md b/SDT/schema4.0/docs/Examples.md
index 5cdf3f82eee2879fc45c93928c0b25c1e11e1218..182255574361e8247f3eda30b3b8df62df25b992 100644
--- a/SDT/schema4.0/docs/Examples.md
+++ b/SDT/schema4.0/docs/Examples.md
@@ -1,159 +1,438 @@
# Examples and Contributions
-[A simple example](#simpleExample)
-[Multi Socket Electrical-Extension-Block](#mseeb)
+
+## Table of Contents
+
+1. [A simple SDT example](#simpleExample)
+2. [A more sophisticated example](#echonetExample)
+ 1. [ModuleClasses Definition](#echonetExampleMC)
+ 2. [DeviceClass Definition](#echonetExampleDC)
+ 3. [The full SDT](#echonetExampleFull)
+
<a name="simpleExample"></a>
-## A very simple SDT example
-In the ideal case, a large organization or SDO would define a widely-applicable set of [ModuleClasses](SDT_Components.md#ModuleClass), each of which could be used as needed to compose the description of a complex device. In order to show the appoach, this section will create a few example ModuleClasses based on - or inspired by - featues in the Echonet Lite protocol. Please note that the examples shown in this document are very "cut down" and by no means represent a true representation of Echonet Lite.
+## A simple SDT example
+
+The following example shows a very simple device that represents a light that can be switched on and off. It contains just a single ModuleClass "Switch", which contains a single boolean data point "status" to control the on/off status of the device.
+
+It is a stand-alone definition without using previously defined ModuleClasses. A more sophisticated use is presented in the next example.
+
+The structure and the according SDT looks like this:
+
+|SimpleExample.xml | |
+|:--------------|-|
+|Namespace information | SimpleExample |
+|DeviceClasses |<ul><li>Light</li><ul><li>Switch<ul><li>status</li></ul></li></ul></ul>|
-The Echonet Consortium has standardized their specifications within IEC/ISO (IEC62394, ISO/IEC24767-1, ISO/IEC24767-2, IEC62480, ISO/IEC14543-4-1, ISO/IEC14543-4-2, IEC62457) and they provide a comprehensive collection of various types of home appliances relevant to SmartGrid applications as ECHONET Device objects (see [https://echonet.jp/spec_object_rf_en/](https://echonet.jp/spec_object_rf_en/) ).
+The following code section shows the fully integrated template. The source code can be found in [SimpleExample.xml](../test/SimpleExample.xml) in the "test" directory.
-For the example in this document, to show re-use of ModuleClass definitions, two complex devices are chosen which have some common features and hence could be expected to both use some of the same ModuleClasses: an air conditioner and a washing machine.
+```xml
+<?xml version="1.0" encoding="iso-8859-1"?>
+<Domain xmlns="http://www.onem2m.org/xml/sdt/4.0" id="SimpleExample" >
+ <DeviceClasses>
+ <DeviceClass id="Light">
+ <Doc>This is a very simple device representing a light.</Doc>
+ <ModuleClasses>
+ <ModuleClass name="Switch">
+ <Data>
+ <DataPoint name="status" readable="true" writable="true">
+ <Doc>This property indicates the ON/OFF status.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ </ModuleClasses>
+ </DeviceClass>
+ </DeviceClasses>
+</Domain>
+```
-<table>
-<tr><th>Funtionality</th><th>Air Conditioner</th><th>Washing Machine</th></tr>
-<tr><td>operationStatus</td><td>operates on/off</td><td>operates on/off</td></tr>
-<tr><td>measuredCumulativePowerConsumption</td><td>the cumulative power consumption</td><td>the cumulative power consumption</td></tr>
-<tr><td>installationLocation</td><td>this sets/reads a string text describing the location (room) of the air-conditioner.</td><td>this sets/reads a string text describing the location (room) of the washing machine.</td></tr>
-<tr><td>setTimer</td><td>(not applicable. there is no preset start for an air-conditioner)</td><td>This sets/reads use the on/off timer</td></tr>
-</table>
+<a name="echonetExample"></a>
+## A more sophisticated example
+
+In the ideal case, a large organization or SDO would define a widely-applicable set of [ModuleClasses](SDT_Components.md#ModuleClass), each of which could be used as needed to compose the description of a complex device. In order to show the approach, this section will create a few example ModuleClasses based on - or inspired by - features in the Echonet Lite protocol. Please note that the examples shown in this document are very "cut down" and by no means represent a true representation of Echonet Lite[^echonet].
+
+[^echonet]: The Echonet Consortium has standardized their specifications within IEC/ISO (IEC62394, ISO/IEC24767-1, ISO/IEC24767-2, IEC62480, ISO/IEC14543-4-1, ISO/IEC14543-4-2, IEC62457) and they provide a comprehensive collection of various types of home appliances relevant to SmartGrid applications as ECHONET Device objects (see [https://echonet.jp/spec_object_rf_en/](https://echonet.jp/spec_object_rf_en/) ).
+
+The source code can be found in [EchonetLiteExamples.xml](../test/EchonetLiteExamples.xml) in the "test" directory.
+
+<a name="echonetExampleMC"></a>
+### ModuleClasses
+For the example in this section, to show re-use of ModuleClass definitions, two complex devices are chosen which have some common features and hence could be expected to both use some of the same ModuleClasses: an air conditioner and a washing machine.
+
+|Functionality | Air Conditioner | Washing Machine |
+|:------------|:----------------|:----------------|
+|operationStatus |operates on/off |operates on/off |
+|measuredCumulativePowerConsumption |the cumulative power consumption |the cumulative power consumption |
+|installationLocation |this sets/reads a string text describing the location (room) of the air-conditioner |this sets/reads a string text describing the location (room) of the washing machine |
+|setTimer |(not applicable. there is no preset start for an air-conditioner) |This sets/reads use the on/off timer |
+|temperatureSensorDataPoints | this reads the measured temperature | this reads the measured temperature |
Based on the simplified example above, the two appliances will need the ModuleClasses below:
- *air-conditioner*: operationStatus, measuredCumulativePowerConsumption, installationLocation;
-- *washing-machine*: operationStatus, measuredCumulativePowerConsumption, and setTimer.
+- *washing-machine*: operationStatus, measuredCumulativePowerConsumption, setTimer, temperatureSensorDataPoints.
+
+```xml
+<ModuleClass name="operationStatus">
+ <Data>
+ <DataPoint name="operationStatus" writable="true">
+ <Doc>This property sets/reads the ON/OFF status.</Doc>
+ <DataType>
+ <SimpleType type="boolean"/>
+ </DataType>
+ </DataPoint>
+ </Data>
+ <Events>
+ <Event name="operationStatus">
+ <!-- Event payload not shown here -->
+ </Event>
+ </Events>
+</ModuleClass>
+
+<ModuleClass name="measuredCumulativePowerConsumption">
+ <Data>
+ <DataPoint name="measuredCumulativePowerConsumption" writable="false">
+ <Doc>This indicates cumulative power consumption of the device in increments of 0.001kWh.</Doc>
+ <DataType>
+ <SimpleType type="integer"/>
+ </DataType>
+ </DataPoint>
+ </Data>
+</ModuleClass>
+
+<ModuleClass name="installationLocation">
+ <Data>
+ <DataPoint name="installationLocation" writable="true">
+ <Doc>This property indicates the installation location</Doc>
+ <DataType>
+ <SimpleType type="string"/>
+ </DataType>
+ </DataPoint>
+ </Data>
+ <Events>
+ <Event name="installationLocation"> </Event>
+ </Events>
+</ModuleClass>
+
+<ModuleClass name="temperatureSensorDataPoints">
+ <Data>
+ <DataPoint name="measuredTemperatureValue" readable="true" writable="false">
+ <Doc>This property indicates the measured temperature value in units of 0.1C.</Doc>
+ <DataType unitOfMeasure="celsius">
+ <SimpleType type="integer" />
+ </DataType>
+ </DataPoint>
+ </Data>
+</ModuleClass>
+
+```
+
+<a name="echonetExampleDC"></a>
+### DeviceClass
+To define a device one would now reference those ModuleClass definitions in a new DeviceClass. For the sake of simplicity only the "SimpleWashingMachine" is implemented here.
+
+In addition to the previously defined ModuleClasses this "SimpleWashingMachine" DeviceClass extends the existing ModuleClass "operationStatus" with an event. It also adds a new ModuleClass "washingMachineDataPoints" with model-specific DataPoints.
+
+At the beginning of the definition some device Properties are defined.
+
+```xml
+<DeviceClass id="SimpleWaschingMachine">
+
+ <!-- Device Properties -->
+
+ <Properties>
+ <Property name="Name" value="washing machine">
+ <SimpleType type="string" />
+ </Property>
+ <Property name="Vendor" value="ACME">
+ <SimpleType type="string" />
+ </Property>
+ </Properties>
+
+ <ModuleClasses>
+
+ <!-- Inheriting ModuleClasses from the global generic ModuleClasses -->
+
+ <ModuleClass name="installationLocation">
+ <Extend domain="example.based.on.echonetLite" entity="installationLocation"/>
+ </ModuleClass>
+
+ <ModuleClass name="measuredInstantaneousPowerConsumption">
+ <Extend domain="example.based.on.echonetLite" entity="measuredInstantaneousPowerConsumption"/>
+ </ModuleClass>
+
+ <ModuleClass name="temperatureSensorDataPoints">
+ <Extend domain="example.based.on.echonetLite" entity="temperatureSensorDataPoints"/>
+ </ModuleClass>
+
+
+ <!-- The following Module inherits and extends a global generic ModuleClass with an event. Therefore, it is renamed to express the change of name. -->
+
+ <ModuleClass name="washingMachineOperationStatus">
+ <Extend domain="example.based.on.echonetLite" entity="operationStatus"/>
+
+ <!-- This Module extends the global one with an event. -->
- <ModuleClass name="operationStatus">
- <Data>
- <DataPoint name="operationStatus" writable="true">
- <Doc>This property sets/reads the ON/OFF status.</Doc>
- <DataType>
- <SimpleType type="boolean"/>
- </DataType>
- </DataPoint>
- </Data>
<Events>
- <Event name="operationStatus">
+ <Event name="washingMachineOperationStatus">
+ <!-- Event payload not shown here -->
</Event>
</Events>
</ModuleClass>
- <ModuleClass name="measuredCumulativePowerConsumption">
+
+ <!-- Data points local to the washing machine device -->
+
+ <ModuleClass name="washingMachineDataPoints">
<Data>
- <DataPoint name="measuredCumulativePowerConsumption" writable="false">
- <Doc>This indicates cumulative power consumption of the device in increments of 0.001kWh.</Doc>
+ <DataPoint name="door_CoverOpen_CloseStatus" readable="true" writable="false">
+ <Doc>This property indicates whether the door/cover is open or closed.</Doc>
<DataType>
- <SimpleType type="integer"/>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="washingMachineSetting" readable="true" writable="true">
+ <Doc>Washing machine setting</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="currentStageOfWashingCycle" readable="true" writable="false">
+ <Doc>This property indicates the current stage of the washing cycle.</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="timeRemainingToCompleteWashingCycle" readable="true" writable="false">
+ <Doc>This property indicates the time remaining to complete the current washing cycle in the HH:MM:SS format.</Doc>
+ <DataType>
+ <SimpleType type="time" />
</DataType>
</DataPoint>
- </Data>
- </ModuleClass>
- <ModuleClass name="installationLocation">
- <Data>
- <DataPoint name="installationLocation" writable="true">
- <Doc>This property indicates the installation location</Doc>
+ <!-- These three data points actually would make a good
+ example to be moved to a separate ModuleClass for
+ generalization so that they can be used by any device
+ that would make use of a timer. -->
+
+ <DataPoint name="onTimerReservationSetting" readable="true" writable="true">
+ <Doc>Reservation ON/OFF</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="onTimerSetting" readable="true" writable="true">
+ <Doc>Timer value (HH:MM)</Doc>
+ <DataType>
+ <SimpleType type="time" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="relativeTimeBasedOnTimerSetting" readable="true" writable="true">
+ <Doc>Timer value (HH:MM)</Doc>
<DataType>
- <SimpleType type="string"/>
+ <SimpleType type="time" />
</DataType>
</DataPoint>
</Data>
- <Events>
- <Event name="installationLocation"> </Event>
- </Events>
</ModuleClass>
- <ModuleClass name="onTimerSetting">
- <DataPoint name="onTimer" writable="true">
- <Doc>Timer value (HH:MM)</Doc>
- <DataType>
- <SimpleType type="time"/>
- </DataType>
- </DataPoint>
- </ModuleClass>
+ </ModuleClasses>
+</DeviceClass>
+```
+<a name="echonetExampleFull"></a>
+### The full SDT
The structure and the according SDT now looks like this:
-<table>
-<tr><td colspan="2" width="50%"><b>Example1.SDT</b></td></tr>
-<tr><td> </td><td>Namespace information</td></tr>
-<tr><td> </td><td>Modules (contains ModuleClasses)</td></tr>
-<tr><td> </td><td>operationStatus<ul>
- <li>measuredCumulativePowerConsumption</li>
- <li>installationLocation</li>
- <li>onTimerSetting</li></ul></td></tr>
-</table>
-
- <?xml version="1.0" encoding="iso-8859-1"?>
- <!-- Example1 SDT inspired by some Echonet Lite examples -->
- <Domain xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
- xmlns:xi="http://www.w3.org/2001/XInclude"
- id="example1.SDT">
-
- <Modules>
- <!-- Various examples for module classes -->
+|EchonetLiteExamples.xml | |
+|:--------------|-|
+|Namespace information | example.based.on.echonetLite |
+|ModuleClasses |<ul><li>operationStatus<ul><li>operationStatus</li></ul></li><li>measuredCumulativePowerConsumption<ul><li>measuredInstantaneousPowerConsumption</li></ul></li><li>installationLocation<ul><li>installationLocation</li></ul></li><li>temperatureSensorDataPoints<ul><li>measuredTemperatureValue</li></ul></li></ul>|
+|DeviceClasses |<ul><li>SimpleWaschingMachine</li><ul><li>installationLocation --> installationLocation</li><li>measuredCumulativePowerConsumption --> measuredCumulativePowerConsumption</li><li>temperatureSensorDataPoints --> temperatureSensorDataPoints</li><li>operationStatus --> washingMachineOperationStatus</li><li>washingMachineDataPoints</li><ul><li>door_CoverOpen_CloseStatus</li><li>washingMachineSetting</li><li>currentStageOfWashingCycle</li><li>timeRemainingToCompleteWashingCycle</li><li>onTimerReservationSetting</li><li>onTimerSetting</li><li>relativeTimeBasedOnTimerSetting</li></ul></ul></ul>|
+
+The following code section shows the fully integrated template.
+
+```xml
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!-- Example1 SDT inspired by some Echonet Lite examples -->
+<?xml version="1.0" encoding="iso-8859-1"?>
+
+<!-- Example SDT definition taken from EchonetLite https://github.com/ECHONET-Consortium -->
+
+
+<Domain xmlns="http://www.onem2m.org/xml/sdt/4.0"
+ xmlns:xi="http://www.w3.org/2001/XInclude"
+ id="example.based.on.echonetLite">
+
+ <!-- Various examples for module classes -->
+
+ <ModuleClasses>
<ModuleClass name="operationStatus">
<Data>
- <DataPoint name="operationStatus" writable="true">
- <Doc>This property sets the ON/OFF status.</Doc>
- <DataType>
- <SimpleType type="boolean"/>
- </DataType>
+ <DataPoint name="operationStatus" readable="true" writable="true">
+ <Doc>This property indicates the ON/OFF status.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
</DataPoint>
</Data>
- <Events>
- <Event name="operationStatus">
- </Event>
- </Events>
</ModuleClass>
+ <!-- runtime property -->
+
<ModuleClass name="installationLocation">
<Data>
- <DataPoint name="installationLocation" writable="true">
+ <DataPoint name="installationLocation" readable="true" writable="true">
<Doc>This property indicates the installation location</Doc>
<DataType>
- <SimpleType type="string"/>
+ <SimpleType type="string" />
</DataType>
</DataPoint>
</Data>
<Events>
- <Event name="installationLocation"> </Event>
+ <Event name="installationLocation">
+ <!-- Event payload not shown here -->
+ </Event>
</Events>
</ModuleClass>
- <ModuleClass name="measuredCumulativePowerConsumption">
+ <!-- sensor readout -->
+
+ <ModuleClass name="measuredInstantaneousPowerConsumption">
<Data>
- <DataPoint name="measuredCumulativePowerConsumption" writable="false">
- <Doc>This indicates cumulative power consumption of the device in increments of 0.001kWh.</Doc>
- <DataType>
- <SimpleType type="integer"/>
+ <DataPoint name="measuredInstantaneousPowerConsumption" readable="true" writable="false">
+ <Doc>This property indicates the instantaneous power consumption of the device in watts.</Doc>
+ <DataType unitOfMeasure="watts">
+ <SimpleType type="integer" />
</DataType>
</DataPoint>
</Data>
</ModuleClass>
- <ModuleClass name="onTimerSetting">
- <DataPoint name="onTimer" writable="true">
- <Doc>Timer value (HH:MM)</Doc>
- <DataType>
- <SimpleType type="time"/>
- </DataType>
- </DataPoint>
+ <ModuleClass name="temperatureSensorDataPoints">
+ <Data>
+ <DataPoint name="measuredTemperatureValue" readable="true" writable="false">
+ <Doc>This property indicates the measured temperature value in units of 0.1C.</Doc>
+ <DataType unitOfMeasure="celsius">
+ <SimpleType type="integer" />
+ </DataType>
+ </DataPoint>
+ </Data>
</ModuleClass>
- </Modules>
- </Domain>
+ </ModuleClasses>
+
+
+ <!-- Very simple example for a washing machine definition -->
+
+ <DeviceClasses>
+ <DeviceClass id="SimpleWaschingMachine">
+
+ <!-- Device Properties -->
+
+ <Properties>
+ <Property name="Name" value="washing machine">
+ <SimpleType type="string" />
+ </Property>
+ <Property name="Vendor" value="ACME">
+ <SimpleType type="string" />
+ </Property>
+ </Properties>
+
+ <ModuleClasses>
+
+ <!-- Inheriting ModuleClasses from the global generic ModuleClasses -->
+
+ <ModuleClass name="installationLocation">
+ <Extend domain="example.based.on.echonetLite" entity="installationLocation"/>
+ </ModuleClass>
+
+ <ModuleClass name="measuredInstantaneousPowerConsumption">
+ <Extend domain="example.based.on.echonetLite" entity="measuredInstantaneousPowerConsumption"/>
+ </ModuleClass>
+
+ <ModuleClass name="temperatureSensorDataPoints">
+ <Extend domain="example.based.on.echonetLite" entity="temperatureSensorDataPoints"/>
+ </ModuleClass>
+
+
+ <!-- The following Module inherits and extends a global generic ModuleClass with an event. Therefore, it is renamed to express
+ the change of name. -->
+
+ <ModuleClass name="washingMachineOperationStatus">
+ <Extend domain="example.based.on.echonetLite" entity="operationStatus"/>
+
+ <!-- This Module extends the global one with an event. -->
+
+ <Events>
+ <Event name="washingMachineOperationStatus">
+ <!-- Event payload not shown here -->
+ </Event>
+ </Events>
+
+ </ModuleClass>
----
+ <!-- Data points local to the washing machine device -->
-<a name="mseeb"></a>
-### Multi Socket Electrical-Extension-Block
+ <ModuleClass name="washingMachineDataPoints">
+ <Data>
+ <DataPoint name="door_CoverOpen_CloseStatus" readable="true" writable="false">
+ <Doc>This property indicates whether the door/cover is open or closed.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="washingMachineSetting" readable="true" writable="true">
+ <Doc>Washing machine setting</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="currentStageOfWashingCycle" readable="true" writable="false">
+ <Doc>This property indicates the current stage of the washing cycle.</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="timeRemainingToCompleteWashingCycle" readable="true" writable="false">
+ <Doc>This property indicates the time remaining to complete the current washing cycle in the HH:MM:SS format.</Doc>
+ <DataType>
+ <SimpleType type="time" />
+ </DataType>
+ </DataPoint>
-This example is a specification for an imaginged device, a connected extension block with multiple power socket where each of the sockets are modeled as a
-separate *SubDevice*.
+ <!-- These three data points actually would make a good
+ example to be moved to a separate ModuleClass for
+ generalization so that they can be used by any device
+ that would make use of a timer. -->
-[mseeb.xml](../test/mseeb.xml)
+ <DataPoint name="onTimerReservationSetting" readable="true" writable="true">
+ <Doc>Reservation ON/OFF</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="onTimerSetting" readable="true" writable="true">
+ <Doc>Timer value (HH:MM)</Doc>
+ <DataType>
+ <SimpleType type="time" />
+ </DataType>
+ </DataPoint>
+ <DataPoint name="relativeTimeBasedOnTimerSetting" readable="true" writable="true">
+ <Doc>Timer value (HH:MM)</Doc>
+ <DataType>
+ <SimpleType type="time" />
+ </DataType>
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ </ModuleClasses>
+ </DeviceClass>
+ </DeviceClasses>
+</Domain>
----
+```
diff --git a/SDT/schema4.0/docs/FAQ.md b/SDT/schema4.0/docs/FAQ.md
index 77c4fb4e2c1fbda17077241d0a41365c4be7888d..fa9430d1b1fd9e3c335597a4d688868352990ab9 100644
--- a/SDT/schema4.0/docs/FAQ.md
+++ b/SDT/schema4.0/docs/FAQ.md
@@ -1,7 +1,73 @@
# Frequently Asked Questions
-## What is the HGI?
-tbd
-## What is the SDT?
-tbd
+1. [General](#general)
+ 1. [What is the SDT?](#WhatistheSDT)
+ 2. [What is oneM2M?](#echonetExampleMC)
+2. [Working with the SDT](#working)
+ 1. [What is the SDT?](#build)
+ 2. [How to validate own templates](#validate)
+ 3. [Are there tools to work with the SDT?](#tools)
+
+<a name="general"></a>
+## General
+
+<a name="WhatistheSDT"></a>
+### What is the SDT?
+The Smart Device Template (SDT) is a template which is used to model the capabilities, actions and events of connected devices. The intent of the SDT is to be able to model any type of connected device using a well accepted and standardised format. The main application of SDT is to enable a uniformly structured Application Programmer’s Interface (API) to applications that need to interact with connected devices.
+
+<a name="WhatisoneM2M"></a>
+### What is oneM2M?
+oneM2M is a global organization that creates requirements, architecture, API specifications, security solutions and interoperability for Machine-to-Machine and IoT technologies.
+
+The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. A critical objective of oneM2M is to attract and actively involve organizations from M2M-related business domains such as: telematics and intelligent transportation, healthcare, utilities, industrial automation, smart homes, etc. Initially, oneM2M shall prepare, approve and maintain the necessary set of Technical Specifications and Technical Reports for:
+
+- Use cases and requirements for a common set of Service Layer capabilities;
+Service Layer aspects with high level and detailed service architecture, in light of an access independent view of end-to-end services;
+- Protocols/APIs/standard objects based on this architecture (open interfaces & protocols);
+- Security and privacy aspects (authentication, encryption, integrity verification);
+- Reachability and discovery of applications;
+- Interoperability, including test and conformance specifications;
+- Collection of data for charging records (to be used for billing and statistical purposes);
+- Identification and naming of devices and applications;
+- Information models and data management (including store and subscribe/notify functionality);
+- Management aspects (including remote management of entities); and
+- Common use cases, terminal/module aspects, including Service Layer interfaces/APIs between:
+- Application and Service Layers;
+- Service Layer and communication functions
+
+[http://www.onem2m.org](http://www.onem2m.org)
+
+<a name="working"></a>
+## Working with the SDT
+
+<a name="working"></a>
+### How to build the SDT
+Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md).
+
+In short:
+
+- In a terminal, go to the directoy *SDT/schema4.0*
+- Run the command:
+```sh
+$ ant
+```
+
+<a name="validate"></a>
+### How to validate own templates
+Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md).
+
+In short:
+
+- Copy your template to the directory *SDT/schema4.0/test*
+- In a terminal, go to the directoy *SDT/schema4.0*
+- Run the command:
+```sh
+$ ant validate
+```
+
+<a name="tools"></a>
+### Are there tools to work with the SDT?
+You can use the SDTTool to read and convert templates in SDT format to various output formats, e.g. XSD, SVG, markdown, Java code, etc.
+
+[https://github.com/Homegateway/SDTTool](https://github.com/Homegateway/SDTTool)
diff --git a/SDT/schema4.0/docs/Introduction.md b/SDT/schema4.0/docs/Introduction.md
index 7cc260eeea2e59c669eb99b702ceb92139809a2e..11795083d3abf72218187af724ee739b62f336d5 100644
--- a/SDT/schema4.0/docs/Introduction.md
+++ b/SDT/schema4.0/docs/Introduction.md
@@ -1,10 +1,28 @@
-# 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.
+## Table of Contents
+1. [Introduction](#Introduction)
+2. [Definitions](#Definitions)
+3. [How should SDT work?](#Work)
+4. [Related aspects which are out of scope of the SDT](#related)
-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++, ...).
+<a name="Introduction"/></a>
+## Introduction
-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.
+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.
+
+Originally initiated by the [Home Gateway Initiative (HGI)](http://www.homegatewayinitiative.org), oneM2M is now the owner and maintainer of the SDT.
+
+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,57 +30,55 @@ 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.
+<a name="Definitions"/></a>
## 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 signalling, 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 signaling, 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**
+<a name="Work"/></a>
## How should SDT work?
The basic concept is that a manufacturer, organisation or global SDO would define its preferred Smart Device Template, in XML, specified by and based on an XSD. Using that XSD, manufacturers or indeed hobbyists could "describe" existing or new devices by means of XML files, specifying the capabilities and the parameters needed to control the devices.
@@ -73,11 +89,12 @@ The key to making software reliably interoperate with various technologies is to
For the convenience of users and developers, it would also be possible to collect the device descriptions of common "modules" (types of) appliances so that the operations of "a generic air-conditioner" could be agreed and re-used often, adapting descriptions of special models with just some special features added as local extensions. Agreeing on the definition of "a generic XYZ appliance" is rather time-consuming, so such "repository" may not become standardised, however the basic approach has huge benefits even if such an archive (also known as a "hierarchical ontology") is never formally agreed.
+<a name="related"/></a>
## 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 +102,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/Links.md b/SDT/schema4.0/docs/Links.md
index 3116385617704f49a4ba246ab9934f2131aadc3c..15f0c688c73fd570fddda5343f1e48583cffe4b9 100644
--- a/SDT/schema4.0/docs/Links.md
+++ b/SDT/schema4.0/docs/Links.md
@@ -1,13 +1,27 @@
# Links & References
+
+
+## Smart Device Template
+- **SDT Repository** : [https://git.onem2m.org/MAS/SDT](https://git.onem2m.org/MAS/SDT)
+
+## Further Information
+
+- **TR-0039 Introduction to IPE and SDT** : [http://www.onem2m.org/tr-0039/ipe-and-sdt](http://www.onem2m.org/tr-0039/ipe-and-sdt)
+- **The oneM2M Smart Device Template (SDT)** (BrightTALK) : [https://www.brighttalk.com/webcast/11949/340004/the-onem2m-smart-device-template-sdt](https://www.brighttalk.com/webcast/11949/340004/the-onem2m-smart-device-template-sdt)
+
+
+## Organisations
+
+- **oneM2M** : [http://www.onem2m.org](http://www.onem2m.org)
- **HGI** : [http://www.homegatewayinitiative.org](http://www.homegatewayinitiative.org)
-## XML
+## Tools
+- **SDTTool** : [https://github.com/Homegateway/SDTTool](https://github.com/Homegateway/SDTTool)
+SDTTool is a utility to read and convert SDT definitions.
- **RELAX NG** : [http://relaxng.org](http://relaxng.org)
- **RELAX NG Tutorial** : [http://relaxng.org/tutorial-20011203.html](http://relaxng.org/tutorial-20011203.html)
-
-## Tools
- **UMLet** : [http://www.umlet.com](http://www.umlet.com)
-The free UML drawing tool used to draw the UML file.
+A free UML drawing tool used to draw the UML file.
- **Apache Ant** : [http://ant.apache.org](http://ant.apache.org)
Build tool
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..e67f6e645bac4b5d67625725f8819f5055ca99e8 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,9 +1,17 @@
-# Build System Libraries and Licenses
-The following libraries are used in the build system for the SDT.
+# SDT Build System Components and Licenses
+The following third-party libraries and components are used in the build system for the Smart Device Template.
+## Table of Contents
+1. [trang.jar](#trang)
+2. [Ant-Contrib Tasks](#antcontrib)
+3. [antSetLogLevel.JAR](#antSetLogLevel)
+
+
+<a name="trang"/></a>
## trang.jar
-[http://www.thaiopensource.com/relaxng/trang-manual.html](http://www.thaiopensource.com/relaxng/trang-manual.html)
+[https://relaxng.org/jclark/trang.html](https://relaxng.org/jclark/trang.html)
+[https://github.com/relaxng/jing-trang](https://github.com/relaxng/jing-trang)
*Trang* takes as input a schema written in any of the following formats:
@@ -45,6 +53,7 @@ LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+<a name="antcontrib"/></a>
## Ant-Contrib Tasks
[http://ant-contrib.sourceforge.net](http://ant-contrib.sourceforge.net)
@@ -55,6 +64,7 @@ The *Ant-Contrib* project is a collection of tasks (and at one point maybe types
This Software is distributed under the Apache Software License.
+<a name="antSetLogLevel"/></a>
## antSetLogLevel.jar
GUI dialog for Ant tasks.
diff --git a/SDT/schema4.0/docs/SDT Build System.md b/SDT/schema4.0/docs/SDT Build System.md
index 8a73e2a04cf18cc95d2255e07119bf2e0b34f34e..a5d19a9788108047fe931e6b5907d60fbfd2c3dd 100644
--- a/SDT/schema4.0/docs/SDT Build System.md
+++ b/SDT/schema4.0/docs/SDT Build System.md
@@ -1,49 +1,65 @@
# 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.
+## Table of Contents
+1. [Directory Structure and Important Files](#Structure)
+2. [Installation](#Installation)
+3. [Building](#Building)
+ 1. [Building the Schema](#BuildingSchema)
+ 2. [Validating SDT Templates](#BuildingValidate)
+4. [Editing the Schema](#Editing)
+
+<a name="Structure"/></a>
## Directory Structure and Important Files
- [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 the Schema](#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 [Validating SDT Templates](#BuildingValidate) 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 the Schema](#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).
+<a name="Installation"/></a>
## 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
+
+<a name="Building"/></a>
## 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
+<a name="BuildingSchema"/></a>
+### Building 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="BuildingValidate"/></a>
+### Validating 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
@@ -54,20 +70,30 @@ Otherwise you most likely receive a stack trace or some other error messages. Se
>[schemavalidate] /Users/someone/Sources/git/SmartDeviceTemplate/SDT/schema/test/mseeb.xml:66:18: cvc-elt.1: Cannot find the declaration of element 'Domain'.
>BUILD FAILED
----
+<a name="Editing"/></a>
+## Editing the Schema
+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.
-## 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.
-
-**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/SDT_Components.md b/SDT/schema4.0/docs/SDT_Components.md
index 2619a9124a735b2f2c2d90c1f38f5a76e5f49eaf..411ac6be7f4c846a935ed0674f50f61618ff5bb5 100644
--- a/SDT/schema4.0/docs/SDT_Components.md
+++ b/SDT/schema4.0/docs/SDT_Components.md
@@ -1,499 +1,496 @@
# SDT Components
-[Domain](#Domain)
-[Device](#Device) | [SubDevice](#SubDevice)
-[Product](#Product)
-[Property](#Property)
-[ModuleClass](#ModuleClass)
- [Action](#Action)
- [Arg](#Arg)
- [DataPoint](#DataPoint)
- [Event](#Event)
-[Data Types](#Data_Types)
- [DataType](#DataType)
- [Constraint](#Constraint)
- [SimpleType](#SimpleType)
- [StructType](#StructType)
- [ArrayType](#ArrayType)
-[Doc](#Documentation)
+## Table of Contents
+
+1. [Basic Components](#BasicComponents)
+ 1. [Domain](#Domain)
+ 2. [ModuleClass](#ModuleClass)
+ 1. [DataPoint](#DataPoint)
+ 2. [Action](#Action)
+ 1. [Arg](#Arg)
+ 3. [Event](#Event)
+ 4. [DeviceClass](#DeviceClass)
+ 1. [SubDevice](#SubDevice)
+ 5. [ProductClass](#ProductClass)
+ 6. [Property](#Property)
+2. [Data Types](#DataTypes)
+ 1. [DataType](#DataType)
+ 1. [Constraint](#Constraint)
+ 2. [TypeChoice](#TypeChoice)
+ 2. [SimpleType](#SimpleType)
+ 3. [StructType](#StructType)
+ 4. [ArrayType](#ArrayType)
+ 5. [EnumType](#EnumType)
+ 1. [ExtendExclude](#ExtendExclude)
+3. [Extending (Inheriting)](#Extending)
+ 1. [Extend](#Extend)
+ 1. [Include](#ExtendInclude)
+ 2. [Exclude](#ExtendExclude)
+ 3. [ExtendType](#ExtendType)
+4. [Documentation (Doc)](#Documentation)
---
-**Editor's Note**: TS-0023 needs to be updated to remove "Module", and change the column name of "Module Instance Name" of all device models to "ModuleClass Specialization Name".
## SDT Overview
-The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of the details of a SDT, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software to be adapted accordingly.
+The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of SDT details, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software to be adapted accordingly.
-
+The key to the diagram elements of the UML diagrams and the snippets in the following sections follow this figure:
-The key to the diagram elements of the UML diagrams above and the snippets in the following sections:
-<a name="Domain"></a>
+The syntax used in the diagrams to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
-The syntax used in the diagram to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
- [Design XML schemas using UML](http://www.ibm.com/developerworks/library/x-umlschem/)
- [UML For W3C XML Schema Design](http://www.xml.com/pub/a/2002/08/07/wxs_uml.html)
+
+<a name="BasicComponents"></a>
+## Basic Elements
+
+
+
+<a name="Domain"></a>
### Domain
The *Domain* element allows labeling of different SDT templates for different technologies and/or industry segments ("verticals"): for example eHealth and Building Management might prefer quite different detailed structures/templates. This also helps keep information in human-friendly and manageable blocks. It is assumed that there will be multiple "SDT Templates" and some of them may be completely proprietary.
-It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
- and [Devices](#Devices) in one referencable logical group.
+It can also be used to collect all specified [ModuleClasses](#ModuleClasses), [DeviceClasses](#DeviceClasss), [DataTypes](#DataTypes) and [ProductClasses](#ProductClasses) in one referencable logical group.
#### Attributes
- **id** : The identifier for that *Domain*. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
- **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
-- **Imports** : XML import/include of other XML files. Optional.
+- **Imports** : XML import/include of other XML files / SDT templates. Optional.
+Note, that when using **Imports** one must include the following namespace in the Domain-Element definition, as shown in the example below: ```xmlns:xi="http://www.w3.org/2001/XInclude"```
+- **[DataTypes](#DataType)** : A list of *DataTypes* that are global to the whole domain. They can be referenced from other definitions by the [Extend](#Extend) element. 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.
+- **[DeviceClasses](#DeviceClass)** : a List of *DeviceClass* components. Optional.
+- **[ProductClasses](#ProductClass)** : a List of *ProductClass* components. Optional.
#### Example
-
- <Domain xmlns:xi="http://www.w3.org/2001/XInclude"
- xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
- id="org.homegatewayinitiative">
- <Doc>Some documentation</Doc>
- <Imports>
- <!-- Import other SDTs via XInclude's include mechanism -->
- <xi:include href="./dal-core.xml" parse="xml" />
- </Imports>
- <ModuleClasses>
- <!-- List of Domain global ModuleClasses goes here -->
- </ModuleClasses>
- <Devices>
- <!-- List of Devices goes here -->
- </Devices>
- </Domain>
+```xml
+<Domain xmlns:xi="http://www.w3.org/2001/XInclude"
+ xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
+ id="org.homegatewayinitiative">
+ <Doc>Some documentation</Doc>
+ <Imports>
+ <!-- Import other SDTs via XInclude's include mechanism -->
+ <xi:include href="anotherSDT.xml" parse="xml" />
+ </Imports>
+ <ModuleClasses>
+ <!-- List of Domain global ModuleClasses goes here -->
+ </ModuleClasses>
+ <DeviceClasses>
+ <!-- List of Devices goes here -->
+ </DeviceClasses>
+</Domain>
+```
---
-<a name="Device"/></a>
+<a name="ModuleClass"/></a>
+### ModuleClass
+Element of [Domain](#Domain) and [Product](#Product).
+
+
-### Device
+*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can extend another *ModuleClass* with additional functionalities.
-
+Every [DeviceClass](#DeviceClass) can be described by a collection of *ModuleClasses* (functionality).
-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).
+The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [DeviceClass](#DeviceClass).
-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.
+In principle there could be an infinite number of *ModuleClasses*, for every kind of functionality found in automation protocol ... 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 specification defines a rich set of such standardized *ModuleClasses* (as well as *DeviceClass* models).
-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".
+Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "PanUP/DOWN", "Temperature", 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.
-*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.
+- **name** : Name of the *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
+- **optional**: Boolean that indicates whether a *ModuleClass* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about 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.
+- **[Doc](#Documentation)** : Documentation for the *ModuleClass*. Optional.
+- **[Extend](#Extend)** : Reference to a another *ModuleClass* which is extended by this *ModuleClass*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *ModuleClass*. Optional.
+- **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
+- **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
+- **[Events](#Event)** : A list of *Event* components. Optional.
#### Example
-
- <Device id="aDevice">
- <Doc>Some documentation</Doc>
- <Properties>
- <!-- The list of Properties for the Device goes here-->
- </Properties>
- <ModuleClasses>
- <!-- List of ModuleClasses local to the Device goes here-->
- </ModuleClasses>
- <SubDevices>
- <!-- List of Sub-Devices of the Device goes here-->
- </SubDevices>
- </Device>
+```xml
+<ModuleClass name="BooleanState">
+ <Doc>Some documentation</Doc>
+ <Actions>
+ <!-- List of Actions goes here-->
+ </Actions>
+ <Events>
+ <!-- List of Events goes here-->
+ </Events>
+ <Data>
+ <!-- List of DataPoints goes here-->
+ </Data>
+</ModuleClass>
+```
---
-<a name="SubDevice"/></a>
+<a name="DataPoint"/></a>
+### DataPoint
+Element of [ModuleClass](#ModuleClass) and [Event](#Event).
-### SubDevice
-*SubDevices* are optional components of a [Device](#Device). They represent physical sub-devices and services inside another device (the *Device*).
+
-*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain).
+A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *[DataType](#DataType)* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof, or an enumeration) which facillitates data integrity.
-
+Note, that all RESTful systems (e.g. CoAP) use only *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
+
+However, *DataPoints* are not the only way of controlling and monitoring devices, so further [Actions](#Action) and [Events](#Event) are described below.
+
+Though *DataPoints* only refer to single data points of a physical device it is possible to describe hierarchies by model the path to the data point in the hierarchy by a path-like structure like to the pathname of a UNIX file system. Here, the root node of the hierarchy is a slash (/ 0x2F) and the segments or nodes along the path are also separated by slashes. The actual datapoint is the last leaf at the path.
+
+In EBNF:
+
+```ebnf
+name = dataPointName | "/" path ;
+path = segment "/" path | dataPointName ;
+segment = string ;
+dataPointName = string ;
+string = (* character string excluding the character "/" *) ;
+```
#### Attributes
-- **id** : The identifier for that *SubDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether a *DataPoint* is optional or mandatory. Optional, the default is *false*.
+- **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Optional. Default: true.
+- **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Optional. Default: true.
+- **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Optional. Default: false.
+- **default** : A default value for the *DataPoint*.
+- - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
-- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
+- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
+- **[DataType](#DataType)** : The type of the *DataPoint*. It must comply to the *DataType* definition. Required.
#### Example
-
- <SubDevice id="aSubDevice">
- <Doc>Some documentation</Doc>
- <Properties>
- <!-- The list of Properties for the Device goes here-->
- </Properties>
- <ModuleClasses>
- <!-- List of ModuleClasses local to the Device goes here-->
- </ModuleClasses>
- </SubDevice>
+```xml
+<Data>
+ <DataPoint name="attributeName" writable="false">
+ <Doc>Some documentation for the DataPoint</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType
+ </DataPoint>
+</Data>
+```
---
-<a name="Product"/></a>
-
-### Product
-
+<a name="Action"/></a>
+### Action
-In real life of device manufacturing, there is an important concept of *Product* under a certain *DeviceClass*. For example, oneM2M may specify a generic *DeviceClass* called 'deviceSmartBracelt' with many fancy features (*ModuleClasses*). Based on the same *DeviceClass*, company A may design a *Product* called 'X-Fit' with only the *ModuleClass* of 'stepCounter' and the instantiated *Property* value of 'Manufacturer = Company A', while company B may design a *Product* called 'Y-Wristband' with the *ModuleClasses* of 'stepCounter' and 'heartRateMonitor' and the instantiated *Property* value of 'Manufacturer = Company B'. Those two *Products* are different but follow the same *DeviceClass*.
+Element of [ModuleClass](#ModuleClass).
-On the other hand, a *Product* is **NOT** yet a real device instance of that *DeviceClass*. It may not have an instantiated *Properties* like device-id, date-of-manufacturing, and the firmware/software-version, etc. It can be ordered by the customers, but not necessarily instantiated or manufactured.
+
-In short, a *Product* is 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 in an online digital store that can be ordered (but not necessarily manufactured) by a customer.
+*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ([Args](#Arg), see next section) with the method which checks and executes them, in one step.
-A *Product* can be defined by implementing the functionalities of an existing *DeviceClass* (while removing unimplemented optional *Properties* and *ModuleClasses*), extending from an existing *DeviceClass* (adding new *Properties* and *ModuleClasses*), or from scratch (without basing on any *DeviceClass*).
+Note, that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
#### Attributes
-- **id** : The identifier for that *Product*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-All elements of *DeviceClass* can be reused in *Product*, but the *optional* attribute of those elements is not applicable (ignored if present).
+- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
+- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
+- **[Args](#Arg)** : Zero or more occurances of argument definitions for an *Action*. Optional.
-- **[Doc](#Documentation)** : Documentation for the *Product*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *Product*. Optional.
-- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *Product*. Optional.
-- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
+<a name="ActionExample"/></a>
+#### Example
+The following are two examples for actions implementing a getter and a setter for boolean values.
+```xml
+<Action name="get" type="boolean">
+ <Doc>Obtain the current associated state. Example of a getter.</Doc>
+</Action>
+
+<Action name="setTarget">
+ <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
+ <Args>
+ <Arg name="value">
+ <Doc>The desired value of the associated state.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </Arg>
+ </Args>
+</Action>
+```
-- **[DeviceClass](#DeviceClass)** : Reference to a *DeviceClass* which is implemented by this *Product*. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the implemented *DeviceClass*. Optional if in the same domain.
- - **class** : Name of the *DeviceClass* in the [Domain](#Domain) that is extended. Required for this element.
-The element has the following child elements:
- - **ImplementedModuleClasses** : A list of names of the implemented optional [ModuleClasses](#ModuleClass) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [ModuleClasses](#ModuleClass) are implemented. If present, both the listed optional [ModuleClasses](#ModuleClass) and the mandatory [ModuleClass](#ModuleClass) are implemented.
- - **ImplementedProperties** : A list of name-value pairs of the implemented optional device [Properties](#Property) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [Properties](#Property) are implemented. If present, both the listed optional [Properties](#Property) and the mandatory [Properties](#Property) are implemented, and the values of those [Properties](#Property) are initiated as provided. In the case that the value of the [Properties](#Property) should not be initiated, the value can be omitted.
+---
-- **Extends** : Reference to a parent *Product* from which this *Product* is extended. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *Product*. Optional if in the same domain.
- - **class** : *id* of the *Product* in the [Domain](#Domain) that is extended. Required for this element.
+<a name="Arg"/></a>
+### Arg
+Element of [Action](#Action).
-**Note**: New extended *Properties* and *ModuleClasses* **shall** have different names from those in the implemented *DeviceClass* if they're defined in the same *Domain*.
+
+
+The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
-**Editor's Note**: the description of the optionality of the datapoints, properties, actions, events in the implemented ModuleClass is FFS.
+The *Arg* has the following attributes and elements:
-#### XML Example
-```
-<Product id="myMseebProduct">
- <DeviceClass domain="org.exampleDomain" class="MSEEB.root">
- <ImplementedPropertyies>
- <Property name="name" value="product-abc"/>
- <Property name="vendor" value="xyz"/>
- <Property name="SerialNumber"/>
- </ImplementedProperties>
- <ImplementedModuleClasses>
- <MoudleClass name="rootPowerOnOff"/>
- <MoudleClass name="power" />
- </ImplementedModuleClasses>
- </DeviceClass>
- <Properties name="someNewProperty" value="someValue">
- <Doc>...</Doc>
- <SimpleType type="string" />
- </Properties>
- <ModuleClasses name="someNewModuleClass">
- <Actions>
- <!-- List of Actions goes here-->
- </Actions>
- <Events>
- <!-- List of Events goes here-->
- </Events>
- <DataPoints>
- <!-- List of DataPoints goes here-->
- </DataPoints>
- </ModuleClasses>
-</Product>
-```
+#### Attributes
+- **name** : The name of the *Arg* attribute. Required.
+- **optional**: Boolean that indicates whether an *Arg* is optional or mandatory. Optional, the default is *false*.
+- **default** : A default value for the *Arg*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
-#### JSON Example
-```
-{
- "Product": {
- "id": "myMseebProduct",
- "DeviceClass": {
- "domain": "org.exampleDomain",
- "class": "MSEEB.root",
- "ImplementedProperties": [{
- "name": "name",
- "value": "product-abc"
- },
- {
- "name": "Vendor",
- "value": "xyz"
- },
- {
- "name": "SerialNumber"
- }],
- "ImplementedModuleClasses": ["rootPowerOnOff","power"]
- },
- "Properties": [{
- "name": "someNewProperty",
- "value": "someValue",
- "Doc": "...",
- "DataType": "..."
- }],
- "ModuleClasses": [{
- "name": "someNewModuleClass",
- "Actions": [],
- "DataPoints": [],
- "Events": []
- }]
- }
-}
-```
----
-<a name="Property"/></a>
+#### Elements
+- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
+- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
-### Property : Element of a *Device* or *ModuleClass*
+#### Example
+See [example above](#ActionExample).
-
+---
-*Property* elements are used to append to [Devices](#Device) and their [ModuleClass](ModuleClass) elements with arbitrary additional information. For [Devices](#Device) it would be very common for a manufacturer to want to add into the XML file which is describing the device such information as "Manufacturing Site", "Date of Manufacture", "Certification Code", "Energy Label Code", "compatible LAN technology", "URL for the device handbook", "physical limits of operation environments", etc.
+<a name="Event"/></a>
+### Event
+Element of [ModuleClass](#ModuleClass).
-Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specify these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
+
-Since the *Properties* are highly varied, depending on industry segment, no attempt is made in the SDT to constrain the options: however it is highly recommended to provide software-developer-friendly information in the [Doc](#Documentation) field of each Property.
+*Event* elements are needed for automation protocols which "push" information, instead of relying on polling by the software application. A typical example would be a "SensorAlert" where a window sensor immediately transmits a change of its state from "closed" to "open", which could be used in a burglar alarm application, needs to be ready to accept such information immediately, and not wait for a regular polling of the device.
#### Attributes
-- **name**: Name or identifier of a *Property*.
-- **optional**: Boolean that indicates whether a *Property* is optional or mandatory. Optional, the default is *false*.
-- **value**: Text representation of value of a *Property*. Optional.
+- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether an *Event* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Property*. Optional.
-- **DataType** : The data type of the property. This must be a [SimpleType](#SimpleType).
+- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
+- **[Data](#DataPoint)** : A list of *DataPoint* components for an event's payload. Optional.
#### Example
-
- <Property name="ManufacturedDate" value="2015.10.30 10:06">
- <SimpleType type="datetime" />
- </Property>
-
+```xml
+<Event name="stateChanged">
+ <Doc>Some documentation for the Event</Doc>
+ <Data>
+ <DataPoint name="state">
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ </Data>
+</Event>
+```
---
-<a name="ModuleClass"/></a>
-
-### Module and ModuleClass
-
-
+<a name="DeviceClass"/></a>
+### DeviceClass
+Element of [Domain](#Domain) and [Product](#Product).
-**ModuleClass**
+
-*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.
+The *DeviceClass* 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.
-Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).
+Note, that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass).
-The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [Device](#Device).
+For each physical device on the network at least one *DeviceClass* **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 *DeviceClass* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices.
-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.
+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".
+*DeviceClasses* may define their own [ModuleClasses](#ModuleClass) or refer to predefined [ModuleClasses](#ModuleClass) of the same or another [Domain](#Domain).
#### 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*.
+- **id** : The identifier for that *DeviceClass*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Module* or *ModuleClass*. Optional.
-- **Extends** : Reference to a another *ModuleClass* or *Module* which is extended with this *ModuleClass*. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *ModuleClass*. Required for this element.
- - **class** : Name of the *ModuleClass* in the [Domain](#Domain) that is extended. Required for this element.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *Module* or *ModuleClass*. Optional.
-- **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
-- **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
-- **[Events](#Event)** : A list of *Event* components. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about 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
-
- <ModuleClass name="BooleanState">
- <Doc>Some documentation</Doc>
- <Actions>
- <!-- List of Actions goes here-->
- </Actions>
- <Events>
- <!-- List of Events goes here-->
- </Events
- <Data>
- <!-- List of DataPoints goes here-->
- </Data>
- </ModuleClass>
+```xml
+<Device id="aDevice">
+ <Doc>Some documentation</Doc>
+ <Properties>
+ <!-- The list of Properties for the Device goes here-->
+ </Properties>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
+ <SubDevices>
+ <!-- List of Sub-Devices of the Device goes here-->
+ </SubDevices>
+</Device>
+```
---
-<a name="DataPoint"/></a>
-
-### DataPoint : Element of *ModuleClass* and *Event*
-
-
-
-A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *type* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof) which facillitates data integrity. Note that all RESTful systems (e.g. CoAP) use only *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
-
-However, *DataPoints* are not the only way of controlling devices, so further [Actions](#Action) and [Events](#Event) are described below.
-
-Though *DataPoints* only refer to single data points of a physical device it is possible to describe hierarchies by model the path to the data point in the hierarchy by a path-like structure like to the pathname of a UNIX file system. Here, the root node of the hierarchy is a slash (/ 0x2F) and the segments or nodes along the path are also separated by slashes. The actual datapoint is the last leaf at the path.
+<a name="SubDevice"/></a>
+### SubDevice
+Element of [DeviceClass](#DeviceClass) and [Product](#Product).
-In EBNF:
+*SubDevices* are optional components of a [DeviceClass](#DeviceClass). They represent physical sub-devices and services inside another device (the *DeviceClass*).
- name = dataPointName | "/" path ;
- path = segment "/" path | dataPointName ;
- segment = string ;
- dataPointName = string ;
- string = (* character string excluding the character "/" *) ;
+*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain).
+
#### Attributes
-- **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether a *DataPoint* is optional or mandatory. Optional, the default is *false*.
-- **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Optional. Default: true.
-- **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Optional. Default: true.
-- **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Optional. Default: false.
+- **id** : The identifier for that *SubDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
-- **[DataType](#DataType)** : The type of the *DataPoint*. It must comply to the *DataType* definition. Required.
+- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
#### Example
-
- <Data>
- <DataPoint name="attributeName" writable="false">
- <Doc>Some documentation for the DataPoint</Doc>
- <DataType>
- <SimpleType type="string" />
- </DataType
- </DataPoint>
- </Data>
+```xml
+<SubDevice id="aSubDevice">
+ <Doc>Some documentation</Doc>
+ <Properties>
+ <!-- The list of Properties for the Device goes here-->
+ </Properties>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
+</SubDevice>
+```
---
+<a name="ProductClass"/></a>
+### ProductClass
+Element of [Domain](#Domain).
-<a name="Action"/></a>
+
-### Action : Element of *ModuleClass*
+In real life of device manufacturing, there is the important concept of a *ProductClass* for a certain [DeviceClass](#DeviceClass). For example, oneM2M may specify a generic [DeviceClass](#DeviceClass) called *deviceSmartBracelt* with many fancy features (ie. a [ModuleClasses](#ModuleClass). Based on the same [DeviceClass](#DeviceClass), company A may design a *ProductClass* called "X-Fit" with only the [ModuleClass](#ModuleClass) of "stepCounter" and the instantiated [Property](#Property) value of "Manufacturer = Company A", while company B may design a *ProductClass* called "Y-Wristband" with the [ModuleClasseses](#ModuleClass) of "stepCounter" and "heartRateMonitor" and the instantiated [Property](#Property) value of "Manufacturer = Company B". Those two *ProductClasses* are different but follow the same [DeviceClass](#DeviceClass).
-
+On the other hand, a *ProductClass* is **NOT** yet a real device instance of that [DeviceClass](#DeviceClass). It may not have an instantiated [Properties](#Property) like device-id, date-of-manufacturing, and the firmware/software-version, etc. It can be ordered by the customers, but not necessarily instantiated or manufactured.
-*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ("args", see next section) with the method which checks and executes them, in one step.
+In short, a *ProductClass* is a concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a [DeviceClass](#DeviceClass) but not yet an device instance. Examples are the shopping items in an online digital store that can be ordered (but not necessarily manufactured) by a customer.
-Note that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
+A *ProductClass* can be defined by implementing the functionalities of an existing [DeviceClass](#DeviceClass) (while removing unimplemented optional *Properties* and [ModuleClasses](#ModuleClass)), extending from an existing [DeviceClass](#DeviceClass) (adding new [Properties](#Property) and [ModuleClasses](#ModuleClass)), or from scratch (without basing on any [DeviceClass](#DeviceClass)).
#### Attributes
-- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
+- **id** : The identifier for that *ProductClass*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by the manufacturer or implementation domain. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
-- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
-- **Args** : Zero or more occurances of [argument](#Arg) definitions for an *Action*. Optional.
+All elements of [DeviceClass](#DeviceClass) can be reused in *ProductClass*, but the *optional* attribute of those elements is not applicable (ignored if present).
-<a name="ActionExample"/></a>
+- **[Doc](#Documentation)** : Documentation for the *ProductClass*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *ProductClass*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *ProductClass*. Optional.
+- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
+- **[DeviceClass](#DeviceClass)** : Reference to a *DeviceClass* which is implemented by this *ProductClass*. Optional.
+- **Extends** : Reference to a parent *ProductClass* from which this *ProductClass* is extended. Optional.
+**Note**: New extended *Properties* and *ModuleClasses* **shall** have different names from those in the implemented *DeviceClass* if they're defined in the same *Domain*. Also, when extending a *ProductClass* that has a [DeviceClass](#DeviceClass) defined (or in any other parent in the inheritance hierarchy) then the child *ProductClass* **must not** define another [DeviceClass](#DeviceClass).
#### Example
-The following are two examples for actions implementing a getter and a setter for boolean values.
-
- <Action name="get" type="boolean">
- <Doc>Obtain the current associated state. Example of a getter.</Doc>
- </Action>
-
- <Action name="setTarget">
- <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
- <Args>
- <Arg name="value">
- <Doc>The desired value of the associated state.</Doc>
- <DataType>
- <SimpleType type="boolean" />
- </DataType>
- </Arg>
- </Args>
- </Action>
+```xml
+<ProductClass id="TestProductClass">
+ <Doc>This is a new product</Doc>
+ <Properties>
+ <Property name="name" value="product-abc">
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ <Property name="vendor" value="xyz"/>
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ <Property name="SerialNumber"/>
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ </Properties>
+ <ModuleClasses>
+ <ModuleClass name="aModuleClass">
+ <Extend domain="adomain" entity="aModuleClass" />
+ </ModuleClass>
+ <ModuleClass name="newModuleClass">
+ <!-- List of Actions, Events and DataPoints goes here-->
+ </ModuleClass>
+ </ModuleClasses>
+ <DeviceClass>
+ <Extend domain="adomain" entity="aDeviceClass" />
+ </DeviceClass>
+</ProductClass>
+```
---
-<a name="Event"/></a>
+<a name="Property"/></a>
+### Property
+Element of a [ProductClass](#ProductClass), [DeviceClass](#DeviceClass), [SubDevice](#SubDevice), and [ModuleClass](#ModuleClass).
+
+
-### Event : Element of *ModuleClass*
+*Property* elements are used to append to [ProductClasses](#ProductClass) [DevicesClasses](#DeviceClass) and their [ModuleClass](ModuleClass) elements with arbitrary additional information. For example, for a [ProductClass](#DeviceClass) it would be very common for a manufacturer to want to add into the XML file which is describing the manufacturer appliance such information as "Manufacturing Site", "Date of Manufacture", "Certification Code", "Energy Label Code", "compatible LAN technology", "URL for the device handbook", "physical limits of operation environments", etc.
-
+Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specify these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
-*Event* elements are needed for automation protocols which "push" information, instead of relying on polling by the software application. A typical example would be a "SensorAlert" where a window sensor immediately transmits a change of its state from "closed" to "open", which could be used in a burglar alarm application, needs to be ready to accept such information immediately, and not wait for a regular polling of the device.
+Since the *Properties* are highly varied, depending on industry segment, no attempt is made in the SDT to constrain the options: however it is highly recommended to provide software-developer-friendly information in the [Doc](#Documentation) field of each Property.
#### Attributes
-- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether an *Event* is optional or mandatory. Optional, the default is *false*.
+- **name**: Name or identifier of a *Property*.
+- **optional**: Boolean that indicates whether a *Property* is optional or mandatory. Optional, the default is *false*.
+- **value**: Text representation of value of a *Property*. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
-- **[Data](#DataPoint)** : A list of *DataPoint* components for an event's payload. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Property*. Optional.
+- **DataType** : The data type of the property. This must be a [SimpleType](#SimpleType).
#### Example
-
- <Event name="stateChanged">
- <Doc>Some documentation for the Event</Doc>
- <Data>
- <DataPoint name="state">
- <DataType>
- <SimpleType type="boolean" />
- </DataType>
- </DataPoint>
- </Data>
- </Event>
+```xml
+<Property name="ManufacturedDate" value="2015.10.30 10:06">
+ <SimpleType type="datetime" />
+</Property>
+```
---
-<a name="Arg"/></a>
+<a name="DataTypes"/></a>
+## Data Types
-### Arg : Element of *Action*
-
-
-The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
+A data type can be simple integers or string text, or rather complex, as shown in the following diagram:
-The *Arg* has the following attributes and elements:
-
-#### Attributes
-- **name** : The name of the *Arg* attribute. Required.
-
-#### Elements
-- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
-- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
+
-#### Example
-See [example above](#ActionExample).
+The various elements of *DataType* are described in the following sections.
----
+*DataTypes* can be rather complex and it might be reasonable to define them on the [Domain](#Domain) level. This way the only need to be defined once and can be references through the [Extend](#Extend) element later, and also across [Domains](#Domain).
-<a name="Data_Types"/></a>
+<a name="DataType"/></a>
### DataType
-The data type can be simple integers or string text, or rather complex, as shown below:
-
-
-The various elements are described in the sections below.
+Element of a [Domain](#Domain), [Property](#Property), [Action](#Action), [Arg](#Arg), [DataPoint](#DataPoint), [Event](#Event), [StructType](#StructType), and [ArrayType](#ArrayType).
The *DataType* element is a "container" for the various aspects of a type.
#### Attributes
-- **name** : The name of the *DataType*. The name must be set for the [Struct](#Struct) types to distinguish individual fields in that structure. It can be used in other cases. Optional.
+- **name** : The name of the *DataType*. Optional, with the exception that the name must be set for fields in a [Struct](#Struct) to distinguish individual fields in that structure.
- **unitOfMeasure** : Before considering the type of data in detail, there is the option to label the data with the units of measurement. A "Temperature" measurement is meaningless until the units Kelvin, Celcius, Fahrenheit etc are known. Because of the extreme variety of units, a string field is the default annotation method, although of course a SDO could decide to reference a standardized list of units. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
- **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional.
@@ -501,39 +498,42 @@ The *DataType* element is a "container" for the various aspects of a type.
- **[SimpleType](#SimpleType)**
- **[Struct](#StructType)**
- **[Array](#ArrayType)**
+ - **[EnumType](#EnumType)**
- **[Constraint](#Constraint)** : A list of *Constraint* elements. Optional.
---
<a name="Constraint"/></a>
-
-### Constraint : Element of DataType
+### Constraint
+Element of [DataType](#DataType).
-The *Constraint* element is an optional element allowing the manufacturer to provide constraints on the permitted values of measured data or input parameters. It can significantly improve the reliability of software and validation of transmitted data.
+The *Constraint* element is an optional element allowing the manufacturer or organization to provide constraints on the permitted values of measured data or input parameters. It can significantly improve the reliability of software and validation of transmitted data.
#### Attributes
- **name** : The name or ID that identifies the *Constraint*. Required.
- **type** : The basic data type of the constraint. Note that this may be different from the type of the [DataType](#DataType) that this *Constraint* is assigned to. For example, a *Constraint* that specifies a maximum length of a string is of type *integer*. Optional.
- **value** : A pre-assigned value for the constraint, for example the maximum number of characters in a string. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Cosntraint* Element. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Constraint* Element. Optional.
---
-### TypeChoice : Construct of *DataType*
+### TypeChoice
+Construct of [DataType](#DataType).
- 
+
-The *TypeChoice* construct is required for syntactic reasons in the UML diagram and the choice from the enumerated list simply designates the complexity of the following DataType.
+The *TypeChoice* construct is required for syntactic reasons in the UML diagram and the choice from the enumerated list simply designates the complexity of the following DataType. It is not directly instantiated or addressed.
---
<a name="SimpleType"/></a>
-
-### SimpleType : Element of *TypeChoice*
+### SimpleType
+Element of [DataType](#DataType).
@@ -545,12 +545,13 @@ The *SimpleType* element is required in order for software to understand the for
If not stated otherwise datatypes should comply to the equivalent datatypes defined in [XML Schema Part 2: Datatypes Second Edition](http://www.w3.org/TR/xmlschema-2/#boolean):
+
+
- **boolean** : A boolean value as defined in [http://www.w3.org/TR/xmlschema-2/#boolean](http://www.w3.org/TR/xmlschema-2/#boolean) .
- **byte** : An integer datatype with the range of [0 - 255] as defined in [http://www.w3.org/TR/xmlschema-2/#unsignedByte](http://www.w3.org/TR/xmlschema-2/#unsignedByte) .
- **integer** : An integer value as defined in [http://www.w3.org/TR/xmlschema-2/#integer](http://www.w3.org/TR/xmlschema-2/#integer) .
- **float** : An IEEE single-precision 32-bit floating point type as defined in [http://www.w3.org/TR/xmlschema-2/#float](http://www.w3.org/TR/xmlschema-2/#float) .
- **string** : The string datatype represents character strings as defined in [http://www.w3.org/TR/xmlschema-2/#string](http://www.w3.org/TR/xmlschema-2/#string) .
-- **enum** : A complete and orderd list of items in a collection. Items in an enumeration are separated by commas (, 0x2c) and must be of one of the datatypes defined here. Commas (, 0x2c) and backslashes (\ 0x5c) in enumaration items must be escaped by backslash.
- **date** : A date value as defined in [http://www.w3.org/TR/xmlschema-2/#date](http://www.w3.org/TR/xmlschema-2/#date) .
- **time** : A time value as defined in [http://www.w3.org/TR/xmlschema-2/#time](http://www.w3.org/TR/xmlschema-2/#time) .
- **datetime** : A time value as defined in [http://www.w3.org/TR/xmlschema-2/#dateTime](http://www.w3.org/TR/xmlschema-2/#dateTime) .
@@ -558,38 +559,225 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi
- **uri** : A URI that represents a Uniform Resource Identifier Reference (URI) as defined by as defined in [RFC 2396](http://www.ietf.org/rfc/rfc2396.txt) and amended in [RFC 2732](http://www.ietf.org/rfc/rfc2732.txt) .
- **void** : The data type *void* represents the absence of a value. This data type can be used for [Actions](#Action) that don't return any value.
+
+### Example
+```xml
+<DataPoint name="simpleDataPoint">
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+</DataPoint>
+```
---
<a name="StructType"/></a>
-
-### StructType : Element of *TypeChoice*
+### StructType
+Element of [DataType](#DataType).
The *StructType* element can be used to represent an ordered list of diverse DataTypes, which are represented by the *name* attribute of each [DataType](#DataType), and can be used recursively.
#### Elements
-- **[DataType](#DataType)** : A list of DataTypes elements representing the elements of a structure.
-
+- **[DataType](#DataType)** : A list of *DataTypes* elements representing the elements of a structure.
+
+### Example
+```xml
+<DataPoint name="structDataPoint">
+ <DataType name="structured">
+ <Struct>
+ <DataType name="aString">
+ <SimpleType type="string" />
+ </DataType>
+ <DataType name="anInteger">
+ <SimpleType type="integer" />
+ </DataType>
+ </Struct>
+ </DataType>
+</DataPoint>
+```
---
<a name="ArrayType"/></a>
-
-### ArrayType : Element of *TypeChoice*
+### ArrayType
+Element of [DataType](#DataType).
The *ArrayType* element is provided for defining lists of data; the definition is recursive so that multi-dimensional arrays can be described. Note that a Constraint can be used to provide limits on Array size.
#### Elements
-- **[DataType](#DataType)** : A single DataType element that specifies the data type for the elements of the array.
+- **[DataType](#DataType)** : A single *DataType* element that specifies the data type for the elements of the array.
+
+### Example
+```xml
+<DataPoint name="arrayDataPoint">
+ <DataType name="arrayOfInteger">
+ <Array>
+ <DataType>
+ <SimpleType type="integer" />
+ </DataType>
+ </Array>
+ </DataType>
+</DataPoint>
+```
---
-<a name="Documentation"/></a>
+<a name="EnumType"/></a>
+### EnumType
+Element of [DataType](#DataType).
-### Doc : Element for all Documentation
+
+
+The *EnumType* element is provided for defining an enumeration data type; it defines a (possibly mixed) typed set of [EnumValues](#EnumValue).
+
+#### Elements
+- **[EnumValue](#EnumValue)** : A list of *EnumValue" element that specifies the data type for the elements of the array.
+
+<a name="EnumTypeExample"/></a>
+#### Example
+```xml
+<DataPoint name="enumDataPoint">
+ <DataType name="enumOfInteger">
+ <Enum>
+ <EnumValue name="red" value="1" type="integer" />
+ <EnumValue name="green" value="2" />
+ <EnumValue name="blue" value="3" />
+ </Enum>
+ </DataType>
+</DataPoint>
+```
+
+---
+
+<a name="EnumValue"/></a>
+### EnumValue
+Element of [EnumType](#EnumType).
+
+
+
+The *EnumType* element is provided for defining an enumeration data type; it defines a (possibly mixed) typed set of [EnumValues](#EnumValue).
+
+#### Attributes
+- **name** : The name that identifies the *EnumValue*. Required.
+- **value** : An assigned value for the *EnumValue*. Required.
+- **type** : The *BasicType* of the *EnumValue*. An [EnumType](#EnumType) may have *EnumValues* of mixed type. Optional, the default is *integer*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
+
+#### Elements
+- **[Doc](#Documentation)** : Documentation for the *EnumValue* Element. Optional.
+
+#### Example
+See [example in *EnumType*](#EnumTypeExample).
+
+---
+
+<a name="Extending"/></a>
+## Extending (Inheriting)
+
+The SDT supports inhering for certain element types. This is done by extending a parent element definition.
+
+By default, this method can be used in a simple way by just extending a whole parent element, but it is also possible to explicitly include or exclude certain elements from the derived element.
+
+Extension across [Domains](#Domain) is supported and encouraged.
+
+
+
+<a name="ExtendExample"/></a>
+#### Example
+The following example defines two [ModuleClasses](#ModuleClass), where the second definition extends to first one, but explicitly excludes one of the [DataPoints](#DataPoint).
+
+```xml
+<ModuleClasses>
+ <ModuleClass name="aModuleClass">
+ <Data>
+ <DataPoint name="dataPoint1">
+ <!-- type definition -->
+ </DataPoint>
+ <DataPoint name="dataPoint2">
+ <!-- type definition -->
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ <ModuleClass name="anotherModuleClass">
+ <Extend domain="aDomain" entity="aModuleClass">
+ <Exclude name="dataPoint2" type="datapoint" />
+ </Extend>
+ <!-- more local definitions, such as Actions, DataPoints etc -->
+ </ModuleClass>
+</ModuleClasses>
+```
+
+---
+
+<a name="Extend"/></a>
+### Extend
+Element of [ProductClass](#ProductClass), [ModuleClass](#ModuleClass) and [DataType](#DataType).
+
+
+
+The *Extend* element specifies which element to extend. As a simple element it can be used to fully include the referenced element into the derived element, but it is also possible to explicitly include or exclude certain elements.
+
+Please note, that it is only possible to either [Include](#ExtendInclude) or [Exclude](#ExtendExclude) elements. When specifying *Include* elements, then all elements that should be included must be specified explicitly; all other elements are *not* included. When specifying *Exclude* elements, then all elements that should be excluded must be specified explicitly; all other elements are automatically included.
+
+#### Attributes
+- **domain** : Identifier / Reference of the [Domain](#Domain) of the extended element. Required.
+- **entity** : Name of the element in the [Domain](#Domain) that is extended. Required.
+
+#### Elements
+- **ExtendChoice** : This element is actual a list of elements from the following list of extend choices. Please note, that it is only possible to either **Include** or **Exclude** elements.
+ - **[Include](#ExtendInclude)**
+ - **[Exclude](#ExtendExclude)**
+
+#### Example
+See [example in *Extending (Inheriting)*](#ExtendExample).
+
+---
+
+<a name="ExtendInclude"/></a>
+### Include
+Element of [Extend](#Extend).
+
+
+
+This element specifies a single element from the parent that will be included while extending.
+
+#### Attributes
+- **name** : The name that identifies the element to be included. Required.
+- **type** : The [ExtendType](#ExtendType) of the element that is included. Optional, the default is *datapoint*.
+
+
+---
+
+<a name="ExtendExclude"/></a>
+### Exclude
+Element of [Extend](#Extend).
+
+
+
+This element specifies a single element from the parent that will be excluded while extending.
+
+#### Attributes
+- **name** : The name that identifies the element to be exclued. Required.
+- **type** : The [ExtendType](#ExtendType) of the element that is excluded. Optional, the default is *datapoint*.
+
+---
+
+<a name="ExtendType"/></a>
+### ExendType
+Element of [ExtendInclude](#ExtendInclude) and [ExtendExclude](#ExtendExclude).
+
+
+
+This is an enumeration of element types for inclusion or exclusion while extending an element.
+
+---
+
+<a name="Documentation"/></a>
+## Documentation (Doc)
+Element for documentation in all elements.
@@ -597,18 +785,18 @@ The *ArrayType* element is provided for defining lists of data; the definition i
The text inside the *Doc* element can be structure using a very limited subset of HTML elements. The possible structuring is defined in EBNF as follows:
-
- Doc = "<Doc>" docContent "</Doc" ;
- docContent = docText | { paragraph | image } ;
- docText = { text | emphasizedText | boldText | monotypeText } ;
- emphasizedText = "<em>" text "</em>" ;
- boldText = "<b>" text "</b>" ;
- monotypeText = "<tt>" text "</tt>" ;
- paragraph = "<p>" docText "</p>" ;
- image = "<img src=" url ">" "<caption>" text "</caption>" "</img>" ;
- url = "\"" (* valid URL *) "\"" ;
- text = (* XML text element *) ;
-
+```ebnf
+Doc = "<Doc>" docContent "</Doc" ;
+docContent = docText | { paragraph | image } ;
+docText = { text | emphasizedText | boldText | monotypeText } ;
+emphasizedText = "<em>" text "</em>" ;
+boldText = "<b>" text "</b>" ;
+monotypeText = "<tt>" text "</tt>" ;
+paragraph = "<p>" docText "</p>" ;
+image = "<img src=" url ">" "<caption>" text "</caption>" "</img>" ;
+url = "\"" (* valid URL *) "\"" ;
+text = (* XML text element *) ;
+```
The intended use for each element is:
@@ -618,3 +806,7 @@ The intended use for each element is:
- **paragraph** : Structure the text in paragraphs.
- **image** : Include an image in the text. The image is loaded from the specified URL and must include a caption text.
+
+
+
+
diff --git a/SDT/schema4.0/docs/SDT_JSON.md b/SDT/schema4.0/docs/SDT_JSON.md
index 0b6c66bf7933db906f71224ea4013b2b11af4ad7..ade2d189ca75694089d6f18b266e37bc81d700e5 100644
--- a/SDT/schema4.0/docs/SDT_JSON.md
+++ b/SDT/schema4.0/docs/SDT_JSON.md
@@ -1,88 +1,428 @@
+# JSON Serialization
+
+## Table of Contents
+
+1. [Introduction](#introduction)
+2. [SDT mapping to JSON](#mappings)
+ 1. [Elements](#elements)
+ 2. [Attributes](#attributes)
+ 1. [ExtendType](#ExtendType)
+ 3. [Imports](#imports)
+ 4. [Data Types](#dataTypes)
+ 1. [SimpleType](#SimpleType)
+ 2. [ArrayType](#ArrayType)
+ 3. [StructType](#StructType)
+ 4. [EnumType](#EnumType)
+ 5. [Extending DataTypes](#extendingDatatypes)
+
+
+
+<a name="introduction"/></a>
+## Introduction
+
When SDT was introduced, XML was the favorite encoding format for schemas. Since then, JSON became more popular in the developers' communities, especially in the context of RESTful implementation.
-JSON is more concise and human-readable comparing to XML, but has less capability of formal schema definition and validation (such as the XML Schema as defined in [domain.xsd](SDT/schema4.0/src/domain.xsd)).
+JSON is more concise and human-readable comparing to XML, but has less capability of formal schema definition and validation (such as the XML Schema as defined in [domain.xsd](../src/domain.xsd)).
-For these reasons, JSON serialization is supported since SDT4.0.
+For these reasons, JSON serialization is supported since SDT version 4.0.
There are some open tools such as [JSON Schema](http://json-schema.org/) that might be useful for describing and validating the JSON serialization of SDT, but it's not yet a formal standard and is still under development.
-In this release, we chose to define the JSON serialization by the documentation below, while borrowing some valuable aspects from JSON Schema (e.g. data types and validation keywords). Full endorsement of [JSON Schema](http://json-schema.org/) may be considered in future.
+In this release, we chose to define the JSON serialization by the documentation below, while borrowing some valuable aspects from JSON Schema (e.g. data types and validation keywords). Full endorsement of [JSON Schema](http://json-schema.org/) may be considered in the future.
+
+The general JSON structure follows the general SDT structure presented in [SDT_UML.md](SDT_UML.md) and described in [SDT_Components.md](SDT_Components.md).
+
+<a name="mappings"/></a>
+## SDT mapping to JSON
+
+<a name="elements"/></a>
+### Elements mapping
+
+| SDT XML Elements | JSON Key Words | Remark |
+|------------------|----------------|--------|
+|Action | Action | |
+|Actions | Actions | This element is an array of *Action* structures. |
+|Arg | Arg | |
+|Args | Args | This element is an array of *Arg* structures. |
+|Constraint | Constraint | |
+|Constraints | Constraints | This element is an array of *Constraint* structures. |
+|Data | Data | This element is an array of *DataPoint* structures. |
+|DataPoint | DataPoint | |
+|DataType | DataType | |
+|DataTypes | DataTypes | This element is an array of *DataType* structures. |
+|DeviceClass | DeviceClass | |
+|DeviceClasses | DeviceClasses | This element is an array of *DeviceClass* structures. |
+|Doc |Doc | |
+|Domain | Domain | |
+|Event | Event | |
+|Events | Events | This element is an array of *Event* structures. |
+|Exclude | Exclude | |
+|Extend | Extend | |
+|Imports |Imports| This element is an array of *Include* structures. |
+|Include | Include | |
+|ModuleClass | ModuleClass | |
+|ModuleClasses | ModuleClasses | This element is an array of *ModuleClass* structures. |
+|ProductClass | ProductClass | |
+|ProductClasses | ProductClasses | This element is an array of *ProductClasses* structures. |
+|Properties | Properties | This element is an array of *Property* structures. |
+|Property | Property | |
+|SubDevice | SubDevice | |
+|SubDevices | SubDevices | This element is an array of *SubDevice* structures. |
-Some JSON examples can be found in [SDT Components](SDT/schema4.0/docs/SDT_Components.md) and a full exmaple can be found in [JSON Example](SDT/schema4.0/docs/JSON_Example.md)
+#### Example
-*Editor's note: a full JSON example will be developed later when the solution is complete*
+The following example defines a simple *Light* device.
-# SDT Elements mapping to JSON
+**XML**:
-| SDT Elements | JSON Key Word |
-|--------------|------------|
-| Domain | Domain |
-|Imports (*capitalization is not consistent in XML)|Imports (*FFS)|
-|Doc |Doc |
-|extends (why it's de-capitalized in XML?) |Extends |
-|ImplementedModuleClasses |ImplementedModuleClasses |
-|ImplementedProperties |ImplementedProperties |
-|DeviceClasses | DeviceClasses|
-|SubDevice | SubDevice|
-|Product | Product|
-|Properties |Properties |
-|ModuleClasses | ModuleClasses|
-|Data| DataPoints|
-|Actions| Actions|
-| Args | Args|
-|Events | Events|
-|DataType| | DataType|
+```xml
+<Domain xmlns="http://www.onem2m.org/xml/sdt/4.0" id="SimpleExample" >
+ <DeviceClasses>
+ <DeviceClass id="Light">
+ <Doc>This is a very simple device representing a light.</Doc>
+ <ModuleClasses>
+ <ModuleClass name="Switch">
+ <Data>
+ <DataPoint name="status" readable="true" writable="true">
+ <Doc>This property indicates the ON/OFF status.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ </ModuleClasses>
+ </DeviceClass>
+ </DeviceClasses>
+</Domain>
+```
-*Editor's note: In XML schema, data-point is tagged as 'Data'. Should we change it to 'DataPoints' to be consistent?*
+**JSON**:
-# SDT Attributes mapping to JSON
-There are common attributes (e.g. *@id, @name, @optional*) used in several SDT components (e.g. *DeviceClass, ModuleClass*) as well as attributes used only in certain components (e.g. *@class* in *Extends*). The mapping of those attributes to JSON follows the same rule as below.
+```javascript
+{
+ "Domain": {
+ "id": "SimpleExample",
+ "DeviceClasses": [
+ {
+ "DeviceClass": {
+ "id": "Light",
+ "Doc": "This is a very simple device representing a light.",
+ "ModuleClasses": [
+ {
+ "ModuleClass": {
+ "Data": [
+ {
+ "DataPoint": {
+ "name": "status",
+ "readable": "true",
+ "writable": "true",
+ "Doc": "This property indicates the ON/OFF status.",
+ "DataType": "boolean"
+ }
+ }
+ ]
+ }
+ }
+ ]
+ }
+ }
+ ]
+ }
+}
+```
-| SDT Attributes | JSON Key Word |
+<a name="attributes"/></a>
+### Attributes mapping
+There are common attributes (e.g. *@id, @name, @optional*) used in several SDT components (e.g. in *DeviceClass, ModuleClass*) as well as attributes used only in certain components (e.g. *@entity* in *Extend*). The mapping of those attributes to JSON follows the rules as below.
+
+| SDT XML Attributes | JSON Key Word |
|----------------|-------------|
-| @id |id |
-| @name |name |
-| @value |value |
-| @optional | optional|
-| @readable | readable|
-| @writable | writable|
-| @eventable | eventable|
-| @domain |domain |
-| @class |class |
-
-
-
-# SDT data types and constraints mapping to JSON
-*Editor's note: defining standardized SDT data type constraints as listed below in the main spec - SDT_Components.md and domain.xsd is ffs*
-
-| SDT Data Types | Values | Constrains | JSON Key Word | Note |
-|----------------|-----------|------|------|----|
-| SimpleType | || - | For simplicity, the type value of *SimpleType* is directly put as the value of parent *DataType* key, e.g. "DataType":"String".|
-| | boolean || boolean | JSON Schema |
-| | byte || byte | An integer datatype with the range of [0 - 255] |
-| | integer | | integer | JSON Schema |
-| | | multipleOf | multipleOf | JSON Schema |
-| | | maximum | maximum | JSON Schema |
-| | | exclusiveMaximum | exclusiveMaximum | JSON Schema |
-| | | minimum | minimum | JSON Schema |
-| | | exclusiveMinimum | exclusiveMinimum | JSON Schema |
-| | float || number | JSON Schema |
-| | | multipleOf | multipleOf | JSON Schema |
-| | | maximum | maximum | JSON Schema |
-| | | exclusiveMaximum | exclusiveMaximum | JSON Schema |
-| | | minimum | minimum | JSON Schema |
-| | | exclusiveMinimum | exclusiveMinimum | JSON Schema |
-| | string || string | JSON Schema |
-| | | maxLength | maxLength | JSON Schema |
-| | | minLength | minLength | JSON Schema |
-| | | pattern | pattern | JSON Schema |
-| | enum || enum | JSON Schema |
-| | date || date | JSON Schema |
-| | time || time | JSON Schema |
-| | datetime || date-time | JSON Schema |
-| | blob || blob | A **base64Binary** encoded string according to [RFC 2045](https://www.w3.org/TR/xmlschema-2/#RFC2045) |
-| | uri || uri | JSON Schema |
-| StructType || | Struct | |
-| ArrayType || | Array | |
+|@default | default |
+|@domain |domain |
+|@entity |entity |
+|@eventable | eventable|
+|@href | href |
+|@id |id |
+|@name |name |
+|@optional | optional|
+|@parse | parse |
+|@readable | readable|
+|@semanticURI | semanticURI |
+|@value |value |
+|@writable | writable|
+|@type | type |
+|@unitOfMeasure | unitOfMeasure |
+
+
+<a name="imports"/></a>
+### Import mapping
+
+The imports are mapped to an array of *Include* structures. Each *Include* structure contains a *href* and a *parse* element.
+
+#### Example
+
+**XML**:
+
+```xml
+<Imports>
+ <xi:include href="anotherSDT.xml" parse="xml" />
+</Imports>
+```
+
+
+**JSON**:
+
+```javascript
+"Imports" : [
+ { "Include" : { "href" : "anotherSDT.xml", "parse" : "json" } }
+]
+```
+<a name="ExtendType"/></a>
+### ExtendType mapping
+In the *Include* and *Exclude* elements one may specify the type of the element to be included or excluded. The following table shows the mapping of *ExtendType*.
+
+| SDT ExtendType | JSON Key Word |
+|----------------|---------------|
+|action | action |
+|datapoint | datapoint |
+|event | event |
+|moduleclass | moduleclass |
+|property | property |
+|device | device |
+|subdevice |subdevice |
+
+
+<a name="dataTypes"/></a>
+### Data Type mapping
+Data types are defined in [SDT_Components.md](SDT_Components.md).
+
+The mapping of the different kind of data types to JSON happens directly to JSON structures. The identifier for the data type kind is the name of that structure. This means that the data type definition is not wrapped by a *DataType* structure.
+
+
+<a name="SimpleType"/></a>
+### SimpleType
+
+Note for *SimpelType*: For simplicity, if there is no other attribute present then the type value of *SimpleType* can be directly put as the value of parent *DataType* key, e.g. ```"DataType":"string"```
+
+| SDT Data Types | Note |
+|----------------|-----------|
+| boolean | boolean (JSON Schema) |
+| string | string (JSON Schema) |
+| byte | An integer datatype with the range of [0 - 255] |
+| integer | integer (JSON Schema) |
+| float | number (JSON Schema) |
+| date | date (JSON Schema) |
+| time | time (JSON Schema) |
+| datetime | date-time (JSON Schema) |
+| blob | A *base64Binary* encoded string according to [RFC 2045](https://www.w3.org/TR/xmlschema-2/#RFC2045) |
+| uri | A string following the URI format (JSON Schema) |
+| void | null (JSON Schema) |
+
+#### Examples
+
+Simple data type:
+
+**XML**:
+
+```xml
+<DataType>
+ <SimpleType type="string"/>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"SimpleType" : "string"
+```
+
+A simple data type with additional attributes:
+
+**XML**:
+
+```xml
+<DataType name="temperatureType" unitOfMeasure="C">
+ <SimpleType type="float"/>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"SimpleType" : {
+ "name" : "temperatureType",
+ "unitOfMeasure" : "C",
+ "type" : "number"
+}
+```
+
+<a name="ArrayType"/></a>
+### ArrayType
+
+An *ArrayType* definition is mapped to an *Array* JSON structure. The content of the structure is only one element that defines the type of the array. This could be any *SimpleType*, *ArrayType*, *StructType*, or *EnumType*.
+
+#### Example
+
+A simple data type with additional attributes:
+
+**XML**:
+
+```xml
+<DataType>
+ <Array>
+ <DataType>
+ <SimpleType type="float" />
+ </DataType>
+ </Array>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"Array" : {
+ "SimpleType" : "float"
+}
+```
+
+<a name="StructType"/></a>
+### StructType
+
+A *StructType* definition is mapped to a *Struct* JSON array. The content of the array are the individual data types for the structure. These could be any *SimpleType*, *ArrayType*, *StructType*, or *EnumType*.
+
+A *StructType* definition must contain a *name* attribute.
+
+#### Example
+
+A simple structured data type (a structure that contains an *indentifier* variable of type *string* and a *count* variable of type *integer*).
+
+**XML**:
+
+```xml
+<DataType>
+ <Struct>
+ <DataType name="identifier">
+ <SimpleType type="string" />
+ </DataType>
+ <DataType name="count">
+ <SimpleType type="integer" />
+ </DataType>
+ </Struct>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"Struct": [
+ {
+ "SimpleType": {
+ "name": "identifier",
+ "type": "string"
+ },
+ "SimpleType": {
+ "name": "count",
+ "type": "integer"
+ }
+ }
+]
+```
+
+A more complex structured data type (a structure that contains an indentifier variable of type *string* and an *integer* array named *items*).
+
+
+**XML**:
+
+```xml
+<DataType>
+ <Struct>
+ <DataType name="identifier">
+ <SimpleType type="string" />
+ </DataType>
+ <DataType name="items">
+ <Array>
+ <DataType>
+ <SimpleType type="integer" />
+ </DataType>
+ </Array>
+ </DataType>
+ </Struct>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"Struct": [
+ {
+ "SimpleType": {
+ "name": "identifier",
+ "type": "string"
+ },
+ "Array": {
+ "name": "items",
+ "SimpleType" : "float"
+ }
+ }
+]
+```
+
+<a name="EnumType"/></a>
+### EnumType
+
+A *EnumType* definition is mapped to an *Enum* JSON structure. The content of the structure are the individual enum values of the enum.
+
+A *EnumType* definition must contain a *name* attribute.
+
+#### Example
+
+An *Enum* that defines three *EnumValues*. The first definition explicitly specifies the type of the *EnumValue*.
+
+**XML**:
+
+```xml
+<DataType>
+ <Enum>
+ <EnumValue name="red" value="1" type="integer"/>
+ <EnumValue name="green" value="2" />
+ <EnumValue name="blue" value="3" />
+ </Enum>
+</DataType>
+```
+
+**JSON**:
+
+```javascript
+"Enum": [
+ { "EnumValue" : { "name" : "red", "value" : 1, "type" : "integer" } },
+ { "EnumValue" : { "name" : "green", "value" : 2 } },
+ { "EnumValue" : { "name" : "blue", "value" : 3 } }
+]
+```
+
+<a name="extendingDatatypes"/></a>
+### Extending Data Types
+
+Extending *DataTypes* are mapped the same way as extending, for example, *ModuleClasses*. However, since the *DataType* is open, the generic form *DataType* must be used for JSON serialization. It maps to a structure that contains a single *Extend* structure. This structure contains the two attributes *domain* and *entity*.
+
+#### Example
+
+
+An *Enum* that defines three *EnumValues*. The first definition explicitly specifies the type of the *EnumValue*.
+
+**XML**:
+
+```xml
+<DataType>
+ <Extend domain="aDomain" entity="temperatureType" />
+</DataType>
+```
+**JSON**:
+```javascript
+"DataType": {
+ "Extend": { "domain": "aDomain", "entity": "temperatureType" }
+}
+```
\ No newline at end of file
diff --git a/SDT/schema4.0/docs/SDT_UML.uxf b/SDT/schema4.0/docs/SDT_UML.uxf
index 0d433b919323237446748e2de11ea920aa3a4f4c..3346d4985df1e8896a66f06be011ece45a171ed5 100644
--- a/SDT/schema4.0/docs/SDT_UML.uxf
+++ b/SDT/schema4.0/docs/SDT_UML.uxf
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.3.0">
<help_text/>
- <zoom_level>10</zoom_level>
+ <zoom_level>8</zoom_level>
<element>
<id>UMLNote</id>
<coordinates>
- <x>1390</x>
- <y>650</y>
- <w>310</w>
- <h>260</h>
+ <x>1168</x>
+ <y>1352</y>
+ <w>232</w>
+ <h>208</h>
</coordinates>
<panel_attributes>bg=#FAF8C8
fontsize=12
@@ -27,8 +27,8 @@ Subclassing
Cardinalities:
0,1 : zero or one
1 : exact one
-0..* : zero or many
-1..* : at least one or many
+0..n : zero or many
+1..n : at least one or many
group=1</panel_attributes>
<additional_attributes/>
@@ -36,14 +36,14 @@ group=1</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1520</x>
- <y>750</y>
- <w>110</w>
- <h>40</h>
+ <x>1272</x>
+ <y>1432</y>
+ <w>88</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
fontsize=10
-m1=0..*
+0..n
group=1</panel_attributes>
<additional_attributes>90.0;20.0;10.0;20.0</additional_attributes>
@@ -51,10 +51,10 @@ group=1</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1520</x>
- <y>790</y>
- <w>110</w>
- <h>30</h>
+ <x>1272</x>
+ <y>1464</y>
+ <w>88</w>
+ <h>24</h>
</coordinates>
<panel_attributes>lt=<<-
fontsize=10
@@ -64,10 +64,10 @@ group=1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1580</x>
- <y>1090</y>
- <w>150</w>
- <h>220</h>
+ <x>1280</x>
+ <y>984</y>
+ <w>120</w>
+ <h>176</h>
</coordinates>
<panel_attributes><<enumeration>>
BasicType
@@ -88,45 +88,45 @@ void</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>960</x>
- <y>1170</y>
- <w>140</w>
- <h>80</h>
+ <x>784</x>
+ <y>1048</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<.
m1= 0..1
-</panel_attributes>
+fontsize=12</panel_attributes>
<additional_attributes>120.0;50.0;60.0;50.0;60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>960</x>
- <y>1090</y>
- <w>140</w>
- <h>80</h>
+ <x>784</x>
+ <y>984</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<.
m1=0..1
-</panel_attributes>
+fontsize=12</panel_attributes>
<additional_attributes>120.0;10.0;40.0;10.0;40.0;60.0;10.0;60.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>480</x>
- <y>1090</y>
- <w>190</w>
- <h>150</h>
+ <x>400</x>
+ <y>984</y>
+ <w>152</w>
+ <h>120</h>
</coordinates>
<panel_attributes>DataType
--
-/@ name : text/
+/@ name : Name/
/@ unitOfMeasure : text/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
-/- extends : Extends/
-/- TypeChoice/
+- TypeChoice
+/- Extend : Extend/
/* Constraints : Constraint/
fg=blue</panel_attributes>
<additional_attributes/>
@@ -134,36 +134,36 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>1030</y>
- <w>710</w>
- <h>130</h>
+ <x>544</x>
+ <y>944</y>
+ <w>544</w>
+ <h>96</h>
</coordinates>
<panel_attributes>lt=<<.
m2=1..n
-</panel_attributes>
- <additional_attributes>10.0;60.0;10.0;20.0;690.0;20.0;690.0;100.0;640.0;100.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;60.0;40.0;60.0;40.0;10.0;660.0;10.0;660.0;90.0;610.0;90.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>1030</y>
- <w>710</w>
- <h>190</h>
+ <x>544</x>
+ <y>944</y>
+ <w>544</w>
+ <h>144</h>
</coordinates>
<panel_attributes>lt=<<.
m2=1
-</panel_attributes>
- <additional_attributes>10.0;60.0;10.0;20.0;690.0;20.0;690.0;160.0;640.0;160.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;60.0;40.0;60.0;40.0;10.0;660.0;10.0;660.0;150.0;610.0;150.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1080</x>
- <y>1210</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>1080</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>SimpleType
--
@@ -174,67 +174,67 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1260</x>
- <y>1230</y>
- <w>340</w>
- <h>50</h>
+ <x>1024</x>
+ <y>1104</y>
+ <w>272</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<<-
m1= 1
-</panel_attributes>
- <additional_attributes>320.0;20.0;10.0;20.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>320.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1080</x>
- <y>1330</y>
- <w>190</w>
- <h>110</h>
+ <x>880</x>
+ <y>1176</y>
+ <w>152</w>
+ <h>88</h>
</coordinates>
<panel_attributes>Constraint
--
-*@ name : text*
+*@ name : Name*
/@ type : BasicType/
/@ value : text/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>660</x>
- <y>1190</y>
- <w>440</w>
- <h>180</h>
+ <x>544</x>
+ <y>1064</y>
+ <w>352</w>
+ <h>144</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
-</panel_attributes>
+fontsize=12</panel_attributes>
<additional_attributes>420.0;150.0;80.0;150.0;80.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1260</x>
- <y>1300</y>
- <w>420</w>
- <h>140</h>
+ <x>1024</x>
+ <y>1152</y>
+ <w>336</w>
+ <h>112</h>
</coordinates>
<panel_attributes>lt=<<-
m1=1
-</panel_attributes>
+fontsize=12</panel_attributes>
<additional_attributes>390.0;10.0;390.0;120.0;10.0;120.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1080</x>
- <y>1090</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>984</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>StructType
--
@@ -245,10 +245,10 @@ fg=blue</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1080</x>
- <y>1150</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>1032</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>ArrayType
--
@@ -259,24 +259,24 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>960</x>
- <y>1140</y>
- <w>140</w>
- <h>50</h>
+ <x>784</x>
+ <y>1024</y>
+ <w>112</w>
+ <h>40</h>
</coordinates>
<panel_attributes>lt=<<.
m1= 0..1
-
+fontsize=12
</panel_attributes>
<additional_attributes>120.0;20.0;10.0;20.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>480</x>
- <y>950</y>
- <w>1250</w>
- <h>40</h>
+ <x>400</x>
+ <y>872</y>
+ <w>1000</w>
+ <h>32</h>
</coordinates>
<panel_attributes>halign=center
SDT 4.0 - DataType
@@ -288,10 +288,10 @@ lw=0.1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>100</x>
+ <x>112</x>
<y>0</y>
- <w>1590</w>
- <h>40</h>
+ <w>1288</w>
+ <h>32</h>
</coordinates>
<panel_attributes>SDT 4.0 - Basic Elements
halign=center
@@ -303,18 +303,18 @@ lw=0.1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>830</x>
- <y>130</y>
- <w>220</w>
- <h>180</h>
+ <x>680</x>
+ <y>104</y>
+ <w>192</w>
+ <h>144</h>
</coordinates>
<panel_attributes>ModuleClass
--
-*@ name : text*
+*@ name : Name*
/@ optional : boolean = false/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
-/- extends : Extends/
+/- Extend : Extend/
/* Properties : Property/
/* Actions : Action/
/* Data : DataPoint/
@@ -326,17 +326,17 @@ fg=blue
<element>
<id>UMLClass</id>
<coordinates>
- <x>1170</x>
- <y>130</y>
- <w>220</w>
- <h>130</h>
+ <x>960</x>
+ <y>104</y>
+ <w>176</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Action
--
-*@ name : text*
+*@ name : Name*
/@ optional : boolean = false/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
/- DataType : DataType/
/* Args : Arg/
fg=blue</panel_attributes>
@@ -345,16 +345,18 @@ fg=blue</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1520</x>
- <y>220</y>
- <w>170</w>
- <h>100</h>
+ <x>1232</x>
+ <y>176</y>
+ <w>168</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Arg
--
-*@ name ; text*
+*@ name : Name*
+/@ optional : boolean = false/
+/@ default : text/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
- DataType : DataType
fg=blue</panel_attributes>
<additional_attributes/>
@@ -362,60 +364,63 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1380</x>
- <y>220</y>
- <w>160</w>
- <h>40</h>
+ <x>1128</x>
+ <y>176</y>
+ <w>120</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>140.0;10.0;10.0;10.0</additional_attributes>
+m1= 0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>130.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>490</x>
- <y>130</y>
- <w>220</w>
- <h>150</h>
+ <x>128</x>
+ <y>104</y>
+ <w>184</w>
+ <h>128</h>
</coordinates>
<panel_attributes>Domain
--
-*@ id : ID*
+*@ id : Name*
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
-/* imports/
+/* Imports/
/* DataTypes : DataType/
/* ModuleClasses : ModuleClass/
/* DeviceClasses : DeviceClass/
+/* ProductClasses : ProductClass/
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>130</y>
- <w>150</w>
- <h>100</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>130.0;10.0;50.0;10.0;50.0;80.0;10.0;80.0</additional_attributes>
+m1=0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>150.0;10.0;60.0;10.0;60.0;60.0;10.0;60.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>490</x>
- <y>440</y>
- <w>220</w>
- <h>110</h>
+ <x>392</x>
+ <y>352</y>
+ <w>176</w>
+ <h>88</h>
</coordinates>
<panel_attributes>SubDevice
--
*@ id : Name*
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
/* Properties : Property/
/* ModuleClasses : ModuleClass/
fg=blue</panel_attributes>
@@ -424,35 +429,36 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>220</y>
- <w>70</w>
- <h>120</h>
+ <x>560</x>
+ <y>200</y>
+ <w>56</w>
+ <h>72</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
-</panel_attributes>
- <additional_attributes>10.0;90.0;50.0;90.0;50.0;10.0;10.0;10.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;60.0;40.0;60.0;40.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>440</y>
- <w>150</w>
- <h>70</h>
+ <x>560</x>
+ <y>256</y>
+ <w>136</w>
+ <h>152</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>130.0;10.0;60.0;10.0;60.0;50.0;10.0;50.0</additional_attributes>
+m1= 0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>150.0;10.0;80.0;10.0;80.0;170.0;10.0;170.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1520</x>
- <y>500</y>
- <w>170</w>
- <h>50</h>
+ <x>1232</x>
+ <y>400</y>
+ <w>168</w>
+ <h>40</h>
</coordinates>
<panel_attributes>Doc
--
@@ -462,58 +468,60 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1040</x>
- <y>130</y>
- <w>150</w>
- <h>70</h>
+ <x>864</x>
+ <y>104</y>
+ <w>112</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
-</panel_attributes>
- <additional_attributes>130.0;10.0;50.0;10.0;50.0;50.0;10.0;50.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;10.0;40.0;10.0;40.0;50.0;10.0;50.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1440</x>
- <y>500</y>
- <w>100</w>
- <h>40</h>
+ <x>1184</x>
+ <y>400</y>
+ <w>64</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
-m1=0..1</panel_attributes>
- <additional_attributes>80.0;10.0;10.0;10.0</additional_attributes>
+m1=0..1
+fontsize=12</panel_attributes>
+ <additional_attributes>60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1040</x>
- <y>190</y>
- <w>150</w>
- <h>120</h>
+ <x>864</x>
+ <y>152</y>
+ <w>112</w>
+ <h>96</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
-</panel_attributes>
- <additional_attributes>130.0;90.0;50.0;90.0;50.0;10.0;10.0;10.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;90.0;40.0;90.0;40.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1170</x>
- <y>270</y>
- <w>220</w>
- <h>160</h>
+ <x>960</x>
+ <y>216</y>
+ <w>176</w>
+ <h>144</h>
</coordinates>
<panel_attributes>DataPoint
--
-*@ name : text*
+*@ name : Name*
/@ optional : boolean = false/
/@ writable : boolean = true/
/@ readable : boolean = true/
/@ eventable : boolean = false/
+/@ default : text/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
- DataType : DataType
fg=blue
@@ -523,61 +531,60 @@ fg=blue
<element>
<id>UMLClass</id>
<coordinates>
- <x>1170</x>
- <y>440</y>
- <w>220</w>
- <h>110</h>
+ <x>960</x>
+ <y>368</y>
+ <w>176</w>
+ <h>88</h>
</coordinates>
<panel_attributes>Event
--
-*@ name : text*
+*@ name : Name*
/@ optional : boolean = false/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
/* Data : DataPoint/
-
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1040</x>
- <y>290</y>
- <w>150</w>
- <h>190</h>
+ <x>864</x>
+ <y>232</y>
+ <w>112</w>
+ <h>168</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
-</panel_attributes>
- <additional_attributes>130.0;160.0;80.0;160.0;80.0;10.0;10.0;10.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;180.0;80.0;180.0;80.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>290</y>
- <w>150</w>
- <h>240</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>336</h>
</coordinates>
<panel_attributes>lt=<.
</panel_attributes>
- <additional_attributes>130.0;10.0;80.0;10.0;80.0;220.0;10.0;220.0</additional_attributes>
+ <additional_attributes>150.0;10.0;100.0;10.0;100.0;400.0;10.0;400.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>490</x>
- <y>300</y>
- <w>220</w>
- <h>130</h>
+ <x>392</x>
+ <y>240</y>
+ <w>176</w>
+ <h>104</h>
</coordinates>
<panel_attributes>DeviceClass
--
*@ id : Name*
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
/* Properties : Property/
/* ModuleClasses : ModuleClass/
/* SubDevices : SubDevice/
@@ -587,53 +594,54 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>390</y>
- <w>70</w>
- <h>100</h>
+ <x>560</x>
+ <y>320</y>
+ <w>64</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<.
-m1=0..n</panel_attributes>
- <additional_attributes>10.0;70.0;40.0;70.0;40.0;10.0;10.0;10.0</additional_attributes>
+m1=0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;50.0;60.0;50.0;60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>290</y>
- <w>150</w>
- <h>90</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>224</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>130.0;10.0;80.0;10.0;80.0;70.0;10.0;70.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>150.0;10.0;100.0;10.0;100.0;260.0;10.0;260.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>370</y>
- <w>150</w>
- <h>100</h>
+ <x>560</x>
+ <y>256</y>
+ <w>136</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.</panel_attributes>
- <additional_attributes>130.0;80.0;60.0;80.0;60.0;10.0;10.0;10.0</additional_attributes>
+ <additional_attributes>150.0;10.0;80.0;10.0;80.0;50.0;10.0;50.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>830</x>
- <y>420</y>
- <w>220</w>
- <h>130</h>
+ <x>680</x>
+ <y>256</y>
+ <w>192</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Property
--
-*@ name : text*
+*@ name : Name*
/@ optional : boolean = false/
/@ value : text/
+/@ semanticURI : uri/
/- Doc : Doc/
-/- semanticURI : uri/
- DataType : SimpleType
fg=blue
transparency=80</panel_attributes>
@@ -642,35 +650,36 @@ transparency=80</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1380</x>
- <y>250</y>
- <w>80</w>
- <h>260</h>
+ <x>1128</x>
+ <y>104</y>
+ <w>56</w>
+ <h>320</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
-</panel_attributes>
- <additional_attributes>10.0;10.0;60.0;10.0;60.0;240.0;10.0;240.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;10.0;40.0;10.0;40.0;380.0;10.0;380.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1040</x>
- <y>290</y>
- <w>70</w>
- <h>190</h>
+ <x>864</x>
+ <y>232</y>
+ <w>56</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
-m1=0..n</panel_attributes>
- <additional_attributes>10.0;160.0;40.0;160.0;40.0;10.0;10.0;10.0</additional_attributes>
+m1=0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;40.0;40.0;40.0;40.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>780</x>
- <y>1100</y>
- <w>190</w>
- <h>110</h>
+ <x>640</x>
+ <y>992</y>
+ <w>152</w>
+ <h>88</h>
</coordinates>
<panel_attributes><<enumeration>>
TypeChoice
@@ -686,215 +695,351 @@ Enum : EnumType
<element>
<id>Relation</id>
<coordinates>
- <x>660</x>
- <y>1110</y>
- <w>140</w>
- <h>80</h>
+ <x>544</x>
+ <y>1000</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<-
m1= 1
-</panel_attributes>
+fontsize=12</panel_attributes>
<additional_attributes>120.0;10.0;80.0;10.0;80.0;60.0;10.0;60.0</additional_attributes>
</element>
+ <element>
+ <id>Relation</id>
+ <coordinates>
+ <x>560</x>
+ <y>168</y>
+ <w>136</w>
+ <h>112</h>
+ </coordinates>
+ <panel_attributes>lt=<.
+fontsize=12</panel_attributes>
+ <additional_attributes>150.0;120.0;80.0;120.0;80.0;10.0;10.0;10.0</additional_attributes>
+ </element>
+ <element>
+ <id>Relation</id>
+ <coordinates>
+ <x>304</x>
+ <y>72</y>
+ <w>392</w>
+ <h>88</h>
+ </coordinates>
+ <panel_attributes>lt=<.
+</panel_attributes>
+ <additional_attributes>470.0;50.0;380.0;50.0;380.0;20.0;50.0;20.0;50.0;90.0;10.0;90.0</additional_attributes>
+ </element>
+ <element>
+ <id>Relation</id>
+ <coordinates>
+ <x>560</x>
+ <y>184</y>
+ <w>64</w>
+ <h>192</h>
+ </coordinates>
+ <panel_attributes>lt=<.
+
+fontsize=12</panel_attributes>
+ <additional_attributes>10.0;220.0;60.0;220.0;60.0;10.0;10.0;10.0</additional_attributes>
+ </element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>100</x>
- <y>320</y>
- <w>330</w>
- <h>230</h>
+ <x>880</x>
+ <y>1128</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
- <panel_attributes>Product
+ <panel_attributes>EnumType
--
-*@ id : Name*
-/- Doc : Doc/
-/- semanticURI : uri/
-/* Properties : Property/
-/* ModuleClasses : ModuleClass/
-/* SubDevices : SubDevice/
-/- DeviceClass/
-/ @domain : IDRF/
-/ @class : id /
-/ -ImplementedProperties : Property /
-/ -ImplementedModuleClasses : ModuleClass /
-/- extends : Extends/
+*- EnumValue : EnumValue*
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>420</x>
- <y>310</y>
- <w>90</w>
- <h>50</h>
+ <x>784</x>
+ <y>1056</y>
+ <w>112</w>
+ <h>104</h>
</coordinates>
- <panel_attributes>lt=<.
+ <panel_attributes>lt=<<.
m1=0..1
-</panel_attributes>
- <additional_attributes>70.0;20.0;10.0;20.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;100.0;40.0;100.0;40.0;10.0;10.0;10.0</additional_attributes>
+ </element>
+ <element>
+ <id>UMLClass</id>
+ <coordinates>
+ <x>1080</x>
+ <y>1144</y>
+ <w>168</w>
+ <h>88</h>
+ </coordinates>
+ <panel_attributes>EnumValue
+--
+*@ name : Name*
+*@ value : text*
+/@ type : BasicType = integer/
+/@ semanticURI : uri/
+/- Doc : Doc/
+fg=blue</panel_attributes>
+ <additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>280</x>
- <y>100</y>
- <w>570</w>
- <h>240</h>
+ <x>1024</x>
+ <y>1144</y>
+ <w>72</w>
+ <h>32</h>
</coordinates>
- <panel_attributes>lt=<.
+ <panel_attributes>lt=<<.
+m1=1..n
+fontsize=12</panel_attributes>
+ <additional_attributes>70.0;10.0;10.0;10.0</additional_attributes>
+ </element>
+ <element>
+ <id>Relation</id>
+ <coordinates>
+ <x>1240</x>
+ <y>1152</y>
+ <w>88</w>
+ <h>64</h>
+ </coordinates>
+ <panel_attributes>lt=<<-
+m1=0..1
+fontsize=12</panel_attributes>
+ <additional_attributes>70.0;10.0;70.0;60.0;10.0;60.0</additional_attributes>
+ </element>
+ <element>
+ <id>UMLClass</id>
+ <coordinates>
+ <x>448</x>
+ <y>624</y>
+ <w>176</w>
+ <h>64</h>
+ </coordinates>
+ <panel_attributes>Extend
+--
+*@domain : Name*
+*@entity : Name*
+/- ExtendChoice/
+fg=blue
</panel_attributes>
- <additional_attributes>550.0;40.0;470.0;40.0;470.0;10.0;10.0;10.0;10.0;220.0</additional_attributes>
+ <additional_attributes/>
+ </element>
+ <element>
+ <id>UMLClass</id>
+ <coordinates>
+ <x>944</x>
+ <y>624</y>
+ <w>192</w>
+ <h>56</h>
+ </coordinates>
+ <panel_attributes>Exclude
+--
+*@name : Name*
+/@type : ExtendType = datapoint/
+fg=blue</panel_attributes>
+ <additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>280</x>
- <y>520</y>
- <w>570</w>
- <h>90</h>
+ <x>872</x>
+ <y>624</y>
+ <w>88</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>550.0;10.0;460.0;10.0;460.0;70.0;10.0;70.0;10.0;30.0</additional_attributes>
+m1= 1..n
+fontsize=12
+</panel_attributes>
+ <additional_attributes>90.0;10.0;30.0;10.0;30.0;50.0;10.0;50.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>420</x>
- <y>440</y>
- <w>90</w>
- <h>40</h>
+ <x>400</x>
+ <y>624</y>
+ <w>64</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
-m1=0..n</panel_attributes>
- <additional_attributes>70.0;10.0;10.0;10.0</additional_attributes>
+m1=0..1
+fontsize=12</panel_attributes>
+ <additional_attributes>60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1080</x>
- <y>1270</y>
- <w>190</w>
- <h>50</h>
+ <x>1224</x>
+ <y>624</y>
+ <w>176</w>
+ <h>128</h>
</coordinates>
- <panel_attributes>EnumType
+ <panel_attributes><<enumeration>>
+ExtendType
--
-*- enumValue : EnumValue*
-fg=blue</panel_attributes>
+action
+datapoint
+event
+moduleclass
+property
+device
+subdevice
+</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>960</x>
- <y>1180</y>
- <w>140</w>
- <h>130</h>
+ <x>1128</x>
+ <y>624</y>
+ <w>112</w>
+ <h>56</h>
</coordinates>
- <panel_attributes>lt=<<.
+ <panel_attributes>lt=<<-
m1=0..1
-</panel_attributes>
- <additional_attributes>120.0;100.0;50.0;100.0;50.0;10.0;10.0;10.0</additional_attributes>
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;10.0;40.0;10.0;40.0;50.0;10.0;50.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1330</x>
- <y>1290</y>
- <w>210</w>
- <h>110</h>
+ <x>944</x>
+ <y>688</y>
+ <w>192</w>
+ <h>56</h>
</coordinates>
- <panel_attributes>EnumValue
+ <panel_attributes>Include
--
-*@ name : text*
-*@ value : value*
-/@ type : BasicType = integer/
-/- Doc : Doc/
-/- semanticURI : uri/
+*@name : Name*
+/@type : ExtendType = datapoint/
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1260</x>
- <y>1280</y>
- <w>90</w>
- <h>50</h>
+ <x>872</x>
+ <y>672</y>
+ <w>88</w>
+ <h>48</h>
</coordinates>
- <panel_attributes>lt=<<.
-m1=1..n
+ <panel_attributes>lt=<.
+m1= 1..n
+fontsize=12
</panel_attributes>
- <additional_attributes>70.0;20.0;10.0;20.0</additional_attributes>
+ <additional_attributes>90.0;30.0;30.0;30.0;30.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>1530</x>
- <y>1300</y>
- <w>120</w>
- <h>80</h>
+ <x>1128</x>
+ <y>624</y>
+ <w>112</w>
+ <h>120</h>
</coordinates>
- <panel_attributes>lt=<<-
-m1=0..1</panel_attributes>
- <additional_attributes>70.0;10.0;70.0;60.0;10.0;60.0</additional_attributes>
+ <panel_attributes>lt=-
+
+fontsize=12</panel_attributes>
+ <additional_attributes>120.0;10.0;40.0;10.0;40.0;130.0;10.0;130.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>490</x>
- <y>630</y>
- <w>220</w>
- <h>80</h>
+ <x>704</x>
+ <y>624</y>
+ <w>176</w>
+ <h>64</h>
</coordinates>
- <panel_attributes>Extends
+ <panel_attributes><<enumeration>>
+ExtendChoice
--
-*@domain : IDRF*
-*@class : id*
-/- exclude : Exclude/
+Excludes : Exclude
+Includes : Include
-fg=blue</panel_attributes>
+
+</panel_attributes>
<additional_attributes/>
</element>
+ <element>
+ <id>Relation</id>
+ <coordinates>
+ <x>616</x>
+ <y>632</y>
+ <w>104</w>
+ <h>56</h>
+ </coordinates>
+ <panel_attributes>lt=<<-
+m1=0..1
+fontsize=12
+</panel_attributes>
+ <additional_attributes>110.0;10.0;40.0;10.0;40.0;50.0;10.0;50.0</additional_attributes>
+ </element>
<element>
<id>UMLClass</id>
<coordinates>
- <x>830</x>
- <y>630</y>
- <w>220</w>
- <h>70</h>
+ <x>392</x>
+ <y>104</y>
+ <w>176</w>
+ <h>128</h>
</coordinates>
- <panel_attributes>Exclude
+ <panel_attributes>ProductClass
--
-*@name : text*
-/@type : text = datapoint/
+*@ id : Name*
+/@ semanticURI : uri/
+/- Doc : Doc/
+/* Properties : Property/
+/* ModuleClasses : ModuleClass/
+/* SubDevices : SubDevice/
+/- DeviceClass : Extend/
+/- Extend : Extend/
fg=blue</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>630</y>
- <w>150</w>
- <h>80</h>
+ <x>304</x>
+ <y>216</y>
+ <w>104</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
-m1= 0..n</panel_attributes>
- <additional_attributes>130.0;10.0;40.0;10.0;40.0;60.0;10.0;60.0</additional_attributes>
+m1=0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>110.0;40.0;60.0;40.0;60.0;10.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
- <x>410</x>
- <y>620</y>
- <w>100</w>
- <h>50</h>
+ <x>304</x>
+ <y>104</y>
+ <w>104</w>
+ <h>104</h>
</coordinates>
<panel_attributes>lt=<.
-m1=0..1
-</panel_attributes>
- <additional_attributes>80.0;20.0;10.0;20.0</additional_attributes>
+m1=0..n
+fontsize=12</panel_attributes>
+ <additional_attributes>110.0;10.0;60.0;10.0;60.0;110.0;10.0;110.0</additional_attributes>
+ </element>
+ <element>
+ <id>UMLClass</id>
+ <coordinates>
+ <x>400</x>
+ <y>536</y>
+ <w>1000</w>
+ <h>32</h>
+ </coordinates>
+ <panel_attributes>halign=center
+SDT 4.0 - Extend
+fontsize=24
+bg=gray
+lw=0.1</panel_attributes>
+ <additional_attributes/>
</element>
</diagram>
diff --git a/SDT/schema4.0/docs/UML Diagram.md b/SDT/schema4.0/docs/UML Diagram.md
index 15a0f0b5cf5bc944ed25fb07b925157e027fc1aa..653717445648c072f09c1149924bb1c736e41da5 100644
--- a/SDT/schema4.0/docs/UML Diagram.md
+++ b/SDT/schema4.0/docs/UML Diagram.md
@@ -1,6 +1,11 @@
# UML Diagram of the SDT 4.0
-The source for the diagrams below is [here](SDT_UML.uxf).
+The source for the diagrams below can be found [here (SDT_UML.uxf)](SDT_UML.uxf).
+
+## Key
+
+
+
## Basic Elements
@@ -9,6 +14,6 @@ The source for the diagrams below is [here](SDT_UML.uxf).
-## Key
+## Extend
-
+
diff --git a/SDT/schema4.0/docs/images/Action.png b/SDT/schema4.0/docs/images/Action.png
index e0ef5763eb818538d8e0652652e79c221e7eedbd..3b2b58e715328d08c6fab9d9d010002d01b74e5e 100644
Binary files a/SDT/schema4.0/docs/images/Action.png and b/SDT/schema4.0/docs/images/Action.png differ
diff --git a/SDT/schema4.0/docs/images/Arg.png b/SDT/schema4.0/docs/images/Arg.png
index 4df9eb09ff0855c2523e8fb2f31448a44d675d9b..86993aa56736837004cd01db2d73360d56401ab5 100644
Binary files a/SDT/schema4.0/docs/images/Arg.png and b/SDT/schema4.0/docs/images/Arg.png differ
diff --git a/SDT/schema4.0/docs/images/Array.png b/SDT/schema4.0/docs/images/Array.png
index 6935adc0c1390c7cfd08bd4593f83b9f0b545db6..30982dc73b44c1033c96314b66f5df7be8fda1c7 100644
Binary files a/SDT/schema4.0/docs/images/Array.png and b/SDT/schema4.0/docs/images/Array.png differ
diff --git a/SDT/schema4.0/docs/images/BasicType.png b/SDT/schema4.0/docs/images/BasicType.png
new file mode 100644
index 0000000000000000000000000000000000000000..45dcb9d3c2211a3e6743afb94b04fd196c79231e
Binary files /dev/null and b/SDT/schema4.0/docs/images/BasicType.png differ
diff --git a/SDT/schema4.0/docs/images/Constraint.png b/SDT/schema4.0/docs/images/Constraint.png
index 4293b90e6c7c8224987fb836a703072bb625acfb..fbb39f318aa566b156b47629a3672d414585fb0b 100644
Binary files a/SDT/schema4.0/docs/images/Constraint.png and b/SDT/schema4.0/docs/images/Constraint.png differ
diff --git a/SDT/schema4.0/docs/images/DataPoint.png b/SDT/schema4.0/docs/images/DataPoint.png
index 69ca53b5cdde67940fd3e584fdb6ef807bc3d9bf..1117872599502c1684ba72ae7c24a9470f77377f 100644
Binary files a/SDT/schema4.0/docs/images/DataPoint.png and b/SDT/schema4.0/docs/images/DataPoint.png differ
diff --git a/SDT/schema4.0/docs/images/DataType.png b/SDT/schema4.0/docs/images/DataType.png
index 331498883c24a8d3160603b0725a25d5bac18eac..8db0da0b4302c8cd15a4ffe4a18ebb09dd9a1534 100644
Binary files a/SDT/schema4.0/docs/images/DataType.png and b/SDT/schema4.0/docs/images/DataType.png differ
diff --git a/SDT/schema4.0/docs/images/Device.png b/SDT/schema4.0/docs/images/Device.png
deleted file mode 100644
index 39ac44b0ab73abcabae53fbaf6641aba0dd3da50..0000000000000000000000000000000000000000
Binary files a/SDT/schema4.0/docs/images/Device.png and /dev/null differ
diff --git a/SDT/schema4.0/docs/images/DeviceClass.png b/SDT/schema4.0/docs/images/DeviceClass.png
new file mode 100644
index 0000000000000000000000000000000000000000..0b774eea9434d12592d003dd609d3f550974f33b
Binary files /dev/null and b/SDT/schema4.0/docs/images/DeviceClass.png differ
diff --git a/SDT/schema4.0/docs/images/Domain.png b/SDT/schema4.0/docs/images/Domain.png
index 1b70166e755a694b0ee73d171dd59e8c25c2a7e9..afcbcde446a7b70da3efa2928ac7644b3b3a3f23 100644
Binary files a/SDT/schema4.0/docs/images/Domain.png and b/SDT/schema4.0/docs/images/Domain.png differ
diff --git a/SDT/schema4.0/docs/images/Enum.png b/SDT/schema4.0/docs/images/Enum.png
new file mode 100644
index 0000000000000000000000000000000000000000..db3738a8b77db61aefae50fafaec58079d1d0556
Binary files /dev/null and b/SDT/schema4.0/docs/images/Enum.png differ
diff --git a/SDT/schema4.0/docs/images/EnumValue.png b/SDT/schema4.0/docs/images/EnumValue.png
new file mode 100644
index 0000000000000000000000000000000000000000..e2fc189d10e2037adc5505c68ef35639c430bf84
Binary files /dev/null and b/SDT/schema4.0/docs/images/EnumValue.png differ
diff --git a/SDT/schema4.0/docs/images/Event.png b/SDT/schema4.0/docs/images/Event.png
index 7506c40b4d3387733195ca2242de40837f05fb46..3842ccb14d0a42a75809f8d2953ef63a2aee9713 100644
Binary files a/SDT/schema4.0/docs/images/Event.png and b/SDT/schema4.0/docs/images/Event.png differ
diff --git a/SDT/schema4.0/docs/images/Extend.png b/SDT/schema4.0/docs/images/Extend.png
new file mode 100644
index 0000000000000000000000000000000000000000..8fc8725a3e244f98d95f5fee13a9cdf3c25b1484
Binary files /dev/null and b/SDT/schema4.0/docs/images/Extend.png differ
diff --git a/SDT/schema4.0/docs/images/ExtendExclude.png b/SDT/schema4.0/docs/images/ExtendExclude.png
new file mode 100644
index 0000000000000000000000000000000000000000..5289fd8d9ee2bbcc583ca99a156689ec9d595446
Binary files /dev/null and b/SDT/schema4.0/docs/images/ExtendExclude.png differ
diff --git a/SDT/schema4.0/docs/images/ExtendInclude.png b/SDT/schema4.0/docs/images/ExtendInclude.png
new file mode 100644
index 0000000000000000000000000000000000000000..da42f529aa97117f2e9b480b27001e5e66dbef79
Binary files /dev/null and b/SDT/schema4.0/docs/images/ExtendInclude.png differ
diff --git a/SDT/schema4.0/docs/images/ExtendType.png b/SDT/schema4.0/docs/images/ExtendType.png
new file mode 100644
index 0000000000000000000000000000000000000000..cc68b5402603c8c68131fd95891adfad22ad22a9
Binary files /dev/null and b/SDT/schema4.0/docs/images/ExtendType.png differ
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/ModuleClass.png b/SDT/schema4.0/docs/images/ModuleClass.png
index 1878593c1d8999ba7e891c77d6494489d8b1dbee..3c8fa19e10746abafa6c34400c6ab3a5744f8b50 100644
Binary files a/SDT/schema4.0/docs/images/ModuleClass.png and b/SDT/schema4.0/docs/images/ModuleClass.png differ
diff --git a/SDT/schema4.0/docs/images/Product.png b/SDT/schema4.0/docs/images/Product.png
index 2b870b7189ba3f9aafb804a24d9dbdfc44b93fd9..5da397e839cd889f8032684474cd97fd0666db1b 100644
Binary files a/SDT/schema4.0/docs/images/Product.png and b/SDT/schema4.0/docs/images/Product.png differ
diff --git a/SDT/schema4.0/docs/images/Property.png b/SDT/schema4.0/docs/images/Property.png
index 89581586826c13719185f3ad75aad5392efdd6e6..972617c89d229e5dfa1e489b17174f81c2031984 100644
Binary files a/SDT/schema4.0/docs/images/Property.png and b/SDT/schema4.0/docs/images/Property.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png b/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
index 6c9b5bf3074a153e2f999987c46b49e6f6d30e4d..188558e7d6854fb8c58b881e6fa414cb3bb6fe7e 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png and b/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_DataType.png b/SDT/schema4.0/docs/images/SDT_UML_DataType.png
index 4ff86055aa73d93a8158aac424b3dc3c166220d9..113771b84a82d00cff2f78639cabb21f475afa13 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_DataType.png and b/SDT/schema4.0/docs/images/SDT_UML_DataType.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_Extend.png b/SDT/schema4.0/docs/images/SDT_UML_Extend.png
new file mode 100644
index 0000000000000000000000000000000000000000..48614a5cb3ad37e2b35578523f09b6c82adb6477
Binary files /dev/null and b/SDT/schema4.0/docs/images/SDT_UML_Extend.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_Key.png b/SDT/schema4.0/docs/images/SDT_UML_Key.png
index 88b15e3a83759d499bb639b6bd38d11f70dcc0fe..b6fb00800ef8684fc4b0379c62fb552356719539 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_Key.png and b/SDT/schema4.0/docs/images/SDT_UML_Key.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
diff --git a/SDT/schema4.0/docs/images/SimpleType.png b/SDT/schema4.0/docs/images/SimpleType.png
index 3e7d5b08ef7747985a993fec9d87da5374d23397..4a3c7b61e4edad95d5d78220f982bc720484a08a 100644
Binary files a/SDT/schema4.0/docs/images/SimpleType.png and b/SDT/schema4.0/docs/images/SimpleType.png differ
diff --git a/SDT/schema4.0/docs/images/Struct.png b/SDT/schema4.0/docs/images/Struct.png
index 854645418669bd142b8637443a6516b7eb6548c4..4e4c9984f6418980683ab633aec15699eee686fd 100644
Binary files a/SDT/schema4.0/docs/images/Struct.png and b/SDT/schema4.0/docs/images/Struct.png differ
diff --git a/SDT/schema4.0/docs/images/SubDevice.png b/SDT/schema4.0/docs/images/SubDevice.png
index e77637fd4681b6b6076e93d6bf9654f7b2499b84..50e497d33523029e67129c5138ef93f932d75e0e 100644
Binary files a/SDT/schema4.0/docs/images/SubDevice.png and b/SDT/schema4.0/docs/images/SubDevice.png differ
diff --git a/SDT/schema4.0/docs/images/TypeChoice.png b/SDT/schema4.0/docs/images/TypeChoice.png
index 3606b755f4bb18642f60f49f481a572b99a508ab..b2e48820501f4821232d751ec40b011c48db213a 100644
Binary files a/SDT/schema4.0/docs/images/TypeChoice.png and b/SDT/schema4.0/docs/images/TypeChoice.png differ
diff --git a/SDT/schema4.0/gen/html/action-test.html b/SDT/schema4.0/gen/html/action-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/action-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/action-test/index.html b/SDT/schema4.0/gen/html/action-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..7c32310e6801e0a3b732709b3a5f857497176803
--- /dev/null
+++ b/SDT/schema4.0/gen/html/action-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain action-test</title>
+</head>
+<body>
+<h1>Domain action-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/arg-test.html b/SDT/schema4.0/gen/html/arg-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/arg-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/arg-test/index.html b/SDT/schema4.0/gen/html/arg-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..97178828e080c68a05e287dcaadb2326071c7608
--- /dev/null
+++ b/SDT/schema4.0/gen/html/arg-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain arg-test</title>
+</head>
+<body>
+<h1>Domain arg-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/datapoint-test.html b/SDT/schema4.0/gen/html/datapoint-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/datapoint-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/datapoint-test/index.html b/SDT/schema4.0/gen/html/datapoint-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..e47ad66ca09ca190f2d479e20377944f5f7261bf
--- /dev/null
+++ b/SDT/schema4.0/gen/html/datapoint-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain datapoint-test</title>
+</head>
+<body>
+<h1>Domain datapoint-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/datatypes-test.html b/SDT/schema4.0/gen/html/datatypes-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/datatypes-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/datatypes-test/index.html b/SDT/schema4.0/gen/html/datatypes-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..4907bc94240945852de5bffd42292de87e8733a0
--- /dev/null
+++ b/SDT/schema4.0/gen/html/datatypes-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain datatypes-test</title>
+</head>
+<body>
+<h1>Domain datatypes-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/deviceClass-test.html b/SDT/schema4.0/gen/html/deviceClass-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/deviceClass-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/deviceClass.test/index.html b/SDT/schema4.0/gen/html/deviceClass.test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..87d2ab70d828fb0e478f96e1a4c0cdb801295bbb
--- /dev/null
+++ b/SDT/schema4.0/gen/html/deviceClass.test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain deviceClass.test</title>
+</head>
+<body>
+<h1>Domain deviceClass.test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/enumtype-test.html b/SDT/schema4.0/gen/html/enumtype-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/enumtype-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/enumtype-test/index.html b/SDT/schema4.0/gen/html/enumtype-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..700b30bf4bfb012d016ea7a124445d0897388760
--- /dev/null
+++ b/SDT/schema4.0/gen/html/enumtype-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain enumtype-test</title>
+</head>
+<body>
+<h1>Domain enumtype-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/example1.SDT.html b/SDT/schema4.0/gen/html/example1.SDT.html
index 6d56d3a0164cc6796a69e32edfe965e22169bfea..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df 100644
--- a/SDT/schema4.0/gen/html/example1.SDT.html
+++ b/SDT/schema4.0/gen/html/example1.SDT.html
@@ -1,70 +1 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
-
-
-
-
-
-
-
- This property sets the ON/OFF status.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- This property indicates the installation location
-
-
-
-
-
-
-
-
-
-
-
-
-
- This indicates cumulative power consumption of the device in increments of 0.001kWh.
-
-
-
-
-
-
-
-
-
-
- Timer value (HH:MM)
-
-
-
-
-
-
-
-
-
-
- This reads the open=true or closed=false status of a door
-
-
-
-
-
-
-
-
-
diff --git a/SDT/schema4.0/gen/html/example1.SDT/index.html b/SDT/schema4.0/gen/html/example1.SDT/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..3ab7fae0ca97fa42b6df824d3e8ba7997ec58c95
--- /dev/null
+++ b/SDT/schema4.0/gen/html/example1.SDT/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain example1.SDT</title>
+</head>
+<body>
+<h1>Domain example1.SDT</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/example2.SDT.html b/SDT/schema4.0/gen/html/example2.SDT.html
index b7999204ca9ac6c8a63d3616d48218ffaafe25ce..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df 100644
--- a/SDT/schema4.0/gen/html/example2.SDT.html
+++ b/SDT/schema4.0/gen/html/example2.SDT.html
@@ -1,27 +1 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/SDT/schema4.0/gen/html/example2.SDT/index.html b/SDT/schema4.0/gen/html/example2.SDT/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..4a5a32c614ee803ba54a3b37f1c34ecf62f6de27
--- /dev/null
+++ b/SDT/schema4.0/gen/html/example2.SDT/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain example2.SDT</title>
+</head>
+<body>
+<h1>Domain example2.SDT</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/example3.SDT.html b/SDT/schema4.0/gen/html/example3.SDT.html
index a81f5d635b760c74f447bf33f2298b0fc6b9e81d..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df 100644
--- a/SDT/schema4.0/gen/html/example3.SDT.html
+++ b/SDT/schema4.0/gen/html/example3.SDT.html
@@ -1,30 +1 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/SDT/schema4.0/gen/html/example3.SDT/index.html b/SDT/schema4.0/gen/html/example3.SDT/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..637b1c0cd739833c7ae6062acc8b4849f370fb0c
--- /dev/null
+++ b/SDT/schema4.0/gen/html/example3.SDT/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain example3.SDT</title>
+</head>
+<body>
+<h1>Domain example3.SDT</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/extend-test/index.html b/SDT/schema4.0/gen/html/extend-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..4f0d97e12d5cee3c9c075105b5f4f101ee8b6069
--- /dev/null
+++ b/SDT/schema4.0/gen/html/extend-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain extend-test</title>
+</head>
+<body>
+<h1>Domain extend-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/extends-test.html b/SDT/schema4.0/gen/html/extends-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/extends-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/product-test.html b/SDT/schema4.0/gen/html/product-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..d9e655d1eaf24eff2654803879cd7d1295ad0aad
--- /dev/null
+++ b/SDT/schema4.0/gen/html/product-test.html
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+
+ This is a test product
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/SDT/schema4.0/gen/html/productClass-test.html b/SDT/schema4.0/gen/html/productClass-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/productClass-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/productClass-test/index.html b/SDT/schema4.0/gen/html/productClass-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..f9cd256486004e6775a4dc70e4e51f16e4c4f4f7
--- /dev/null
+++ b/SDT/schema4.0/gen/html/productClass-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain productClass-test</title>
+</head>
+<body>
+<h1>Domain productClass-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/semanticURI-test.html b/SDT/schema4.0/gen/html/semanticURI-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/semanticURI-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/semanticURI-test/index.html b/SDT/schema4.0/gen/html/semanticURI-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..c861a85e821505f87682879da9b6ba2aeb6002af
--- /dev/null
+++ b/SDT/schema4.0/gen/html/semanticURI-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain semanticURI-test</title>
+</head>
+<body>
+<h1>Domain semanticURI-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/gen/html/void-test.html b/SDT/schema4.0/gen/html/void-test.html
new file mode 100644
index 0000000000000000000000000000000000000000..89a325edfb1bba8e2a7ece8f8475e9285ecfe5df
--- /dev/null
+++ b/SDT/schema4.0/gen/html/void-test.html
@@ -0,0 +1 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
diff --git a/SDT/schema4.0/gen/html/void-test/index.html b/SDT/schema4.0/gen/html/void-test/index.html
new file mode 100644
index 0000000000000000000000000000000000000000..1120bf162729b3476566c4250d0d6473fe8ae072
--- /dev/null
+++ b/SDT/schema4.0/gen/html/void-test/index.html
@@ -0,0 +1,10 @@
+<?xml version="1.0" encoding="ISO-8859-1"?><html xmlns:dal="http://www.onem2m.org/xml/sdt/4.0" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Domain void-test</title>
+</head>
+<body>
+<h1>Domain void-test</h1>
+<h2>Devices</h2>
+<ul/>
+</body>
+</html>
diff --git a/SDT/schema4.0/test/EchonetLiteExamples.xml b/SDT/schema4.0/test/EchonetLiteExamples.xml
index e87de7a63e29f9275de5db6a4592c2b17bac490c..fd411ca72f383e31be7f26b24e0fb7f8bb162268 100644
--- a/SDT/schema4.0/test/EchonetLiteExamples.xml
+++ b/SDT/schema4.0/test/EchonetLiteExamples.xml
@@ -69,6 +69,9 @@
<DeviceClasses>
<DeviceClass id="SimpleWaschingMachine">
+
+ <!-- Device Properties -->
+
<Properties>
<Property name="Name" value="washing machine">
<SimpleType type="string" />
@@ -119,21 +122,18 @@
<DataPoint name="door_CoverOpen_CloseStatus" readable="true" writable="false">
<Doc>This property indicates whether the door/cover is open or closed.</Doc>
<DataType>
- <!-- <SimpleType type="enum" /> -->
- <SimpleType type="string" />
+ <SimpleType type="boolean" />
</DataType>
</DataPoint>
<DataPoint name="washingMachineSetting" readable="true" writable="true">
<Doc>Washing machine setting</Doc>
<DataType>
- <!-- <SimpleType type="enum" /> -->
<SimpleType type="string" />
</DataType>
</DataPoint>
<DataPoint name="currentStageOfWashingCycle" readable="true" writable="false">
<Doc>This property indicates the current stage of the washing cycle.</Doc>
<DataType>
- <!-- <SimpleType type="enum" /> -->
<SimpleType type="string" />
</DataType>
</DataPoint>
@@ -152,7 +152,6 @@
<DataPoint name="onTimerReservationSetting" readable="true" writable="true">
<Doc>Reservation ON/OFF</Doc>
<DataType>
- <!-- <SimpleType type="enum" /> -->
<SimpleType type="boolean" />
</DataType>
</DataPoint>
@@ -168,9 +167,9 @@
<SimpleType type="time" />
</DataType>
</DataPoint>
-
</Data>
</ModuleClass>
+
</ModuleClasses>
</DeviceClass>
</DeviceClasses>
diff --git a/SDT/schema4.0/test/SimpleExample.xml b/SDT/schema4.0/test/SimpleExample.xml
new file mode 100644
index 0000000000000000000000000000000000000000..d9d097068c985de8ab86096407aeddf619a6e843
--- /dev/null
+++ b/SDT/schema4.0/test/SimpleExample.xml
@@ -0,0 +1,20 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<Domain xmlns="http://www.onem2m.org/xml/sdt/4.0" id="SimpleExample" >
+ <DeviceClasses>
+ <DeviceClass id="Light">
+ <Doc>This is a very simple device representing a light.</Doc>
+ <ModuleClasses>
+ <ModuleClass name="Switch">
+ <Data>
+ <DataPoint name="status" readable="true" writable="true">
+ <Doc>This property indicates the ON/OFF status.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ </ModuleClasses>
+ </DeviceClass>
+ </DeviceClasses>
+</Domain>
\ No newline at end of file