Skip to content
Snippets Groups Projects
Commit 600de362 authored by Andreas Kraft's avatar Andreas Kraft
Browse files

Documentation for v4.0. Some new links, images etc.

parent 14cdf759
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 528 additions and 496 deletions
LICENSE
+ 1
− 1
View file @ 600de362
Copyright 2019, oneM2M Partners Type 1 Copyright 2020, 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: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
......
README.md
+ 2
− 2
View file @ 600de362
...@@ -12,12 +12,12 @@ Any contributions made to the Smart Device Template format must comply with the ...@@ -12,12 +12,12 @@ Any contributions made to the Smart Device Template format must comply with the
![](SDT/schema4.0/docs/images/SDT_simplified.png) ![](SDT/schema4.0/docs/images/SDT_simplified.png)
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 method 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) for applications that need to interact with connected devices. Usually, these applications would communicate to devices using an abstraction or service layer, or cloud platform as an intermediary logic. This layer usually "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) [Read the full Introduction.](SDT/schema4.0/docs/Introduction.md)
## Quick Links ## Quick Links
- [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. - [UML Diagrams of the SDT 4.0](SDT/schema4.0/docs/UML%20Diagram.md) ([Umlet source](SDT/schema4.0/docs/SDT_UML.uxf)) : These 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. - ['domain.xsd' Version 4.0](SDT/schema4.0/src/domain.xsd) : This is the XSD schema file that defines the SDT XML Schema.
......
SDT/schema4.0/docs/Changelog.md
+ 1
− 0
View file @ 600de362
...@@ -13,6 +13,7 @@ ...@@ -13,6 +13,7 @@
- Added ``optional`` attribute to ``<Arg>``. - Added ``optional`` attribute to ``<Arg>``.
- Added ``default`` attribute to ``<Arg>``. - Added ``default`` attribute to ``<Arg>``.
- Added ``default`` attribute to ``<DataPoint``. - Added ``default`` attribute to ``<DataPoint``.
- Added `minOccurs`` and ``maxOccurs`` to SubDevice and ModuleClass
- Unified all component identifiers, names etc to XSD type ``name``. - Unified all component identifiers, names etc to XSD type ``name``.
- Introduced JSON serialization guidelines. - Introduced JSON serialization guidelines.
- Changed case of ``<Imports>`` element. - Changed case of ``<Imports>`` element.
......
SDT/schema4.0/docs/Examples.md
+ 21
− 18
View file @ 600de362
...@@ -7,23 +7,24 @@ ...@@ -7,23 +7,24 @@
1. [ModuleClasses Definition](#echonetExampleMC) 1. [ModuleClasses Definition](#echonetExampleMC)
2. [DeviceClass Definition](#echonetExampleDC) 2. [DeviceClass Definition](#echonetExampleDC)
3. [The full SDT](#echonetExampleFull) 3. [The full SDT](#echonetExampleFull)
3. [More examples](#moreExamples)
<a name="simpleExample"></a> <a id="simpleExample"></a>
## A simple SDT example ## 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. 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](SDT_Components.md#ModuleClass) "Switch", which contains a single boolean [data point](SDT_Components.md#DataPoint) "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. It is a stand-alone definition without using previously defined [ModuleClasses](SDT_Components.md#ModuleClass). A more sophisticated use is presented in the next example.
The structure and the according SDT looks like this: The structure and the according SDT looks like this:
|SimpleExample.xml | | |SimpleExample.xml | |
|:--------------|-| |:--------------|-|
|Namespace information | SimpleExample | |Namespace information | SimpleExample |
|DeviceClasses |<ul><li>Light</li><ul><li>Switch<ul><li>status</li></ul></li></ul></ul>| |DeviceClasses |<ul><li>Light ([DeviceClass](SDT_Components.md#DeviceClass))</li><ul><li>Switch ([ModuleClass](SDT_Components.md#ModuleClass))<ul><li>status ([DataPoint](SDT_Components.md#DataPoint)</li></ul></li></ul></ul>|
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. The following code section shows the fully integrated template. The source code can be found in [SimpleExample.xml](../test/SimpleExample.xml) in the [test](../test) directory.
```xml ```xml
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="iso-8859-1"?>
...@@ -48,28 +49,28 @@ The following code section shows the fully integrated template. The source code ...@@ -48,28 +49,28 @@ The following code section shows the fully integrated template. The source code
</Domain> </Domain>
``` ```
<a name="echonetExample"></a> <a id="echonetExample"></a>
## A more sophisticated example ## 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]. 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](SDT_Components.md#ModuleClass) 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/) ). [^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. The source code can be found in [EchonetLiteExamples.xml](../test/EchonetLiteExamples.xml) in the "test" directory.
<a name="echonetExampleMC"></a> <a id="echonetExampleMC"></a>
### ModuleClasses ### 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. For the example in this section, to show re-use of [ModuleClass](SDT_Components.md#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](SDT_Components.md#ModuleClass): an air conditioner and a washing machine.
|Functionality | Air Conditioner | Washing Machine | |Functionality | Air Conditioner | Washing Machine |
|:------------|:----------------|:----------------| |:------------|:----------------|:----------------|
|operationStatus |operates on/off |operates on/off | |operationStatus |operates on/off |operates on/off |
|measuredCumulativePowerConsumption |the cumulative power consumption |the cumulative power consumption | |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 | |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 | |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 | |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: Based on the simplified example above, the two appliances will need the [ModuleClasses](SDT_Components.md#ModuleClass) below:
- *air-conditioner*: operationStatus, measuredCumulativePowerConsumption, installationLocation; - *air-conditioner*: operationStatus, measuredCumulativePowerConsumption, installationLocation;
- *washing-machine*: operationStatus, measuredCumulativePowerConsumption, setTimer, temperatureSensorDataPoints. - *washing-machine*: operationStatus, measuredCumulativePowerConsumption, setTimer, temperatureSensorDataPoints.
...@@ -129,11 +130,11 @@ Based on the simplified example above, the two appliances will need the ModuleCl ...@@ -129,11 +130,11 @@ Based on the simplified example above, the two appliances will need the ModuleCl
``` ```
<a name="echonetExampleDC"></a> <a id="echonetExampleDC"></a>
### DeviceClass ### 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. To define a device one would now reference those [ModuleClass](SDT_Components.md#ModuleClass) definitions in a new [DeviceClass](SDT_Components.md#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. In addition to the previously defined [ModuleClasses](SDT_Components.md#ModuleClass) this "SimpleWashingMachine" [DeviceClass](SDT_Components.md#DeviceClass) extends the existing [ModuleClass](SDT_Components.md#ModuleClass) "operationStatus" with an event. It also adds a new [ModuleClass](SDT_Components.md#ModuleClass) "washingMachineDataPoints" with model-specific [DataPoints](SDT_Components.md#DataPoint).
At the beginning of the definition some device Properties are defined. At the beginning of the definition some device Properties are defined.
...@@ -242,15 +243,15 @@ At the beginning of the definition some device Properties are defined. ...@@ -242,15 +243,15 @@ At the beginning of the definition some device Properties are defined.
</DeviceClass> </DeviceClass>
``` ```
<a name="echonetExampleFull"></a> <a id="echonetExampleFull"></a>
### The full SDT ### The full SDT
The structure and the according SDT now looks like this: The structure and the according SDT now looks like this:
|EchonetLiteExamples.xml | | |EchonetLiteExamples.xml | |
|:--------------|-| |:--------------|-|
|Namespace information | example.based.on.echonetLite | |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>| |[ModuleClasses](SDT_Components.md#ModuleClass) |<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>| |[DeviceClasses](SDT_Components.md#DeviceClass) |<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. The following code section shows the fully integrated template.
...@@ -433,6 +434,8 @@ The following code section shows the fully integrated template. ...@@ -433,6 +434,8 @@ The following code section shows the fully integrated template.
</DeviceClass> </DeviceClass>
</DeviceClasses> </DeviceClasses>
</Domain> </Domain>
``` ```
<a id="moreExample"></a>
## More Examples
More examples that also show specific features of the SDT are available in the [test](../test) directory.
SDT/schema4.0/docs/FAQ.md
+ 9
− 7
View file @ 600de362
...@@ -9,14 +9,14 @@ ...@@ -9,14 +9,14 @@
2. [How to validate own templates](#validate) 2. [How to validate own templates](#validate)
3. [Are there tools to work with the SDT?](#tools) 3. [Are there tools to work with the SDT?](#tools)
<a name="general"></a> <a id="general"></a>
## General ## General
<a name="WhatistheSDT"></a> <a id="WhatistheSDT"></a>
### What is the SDT? ### 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. 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> <a id="WhatisoneM2M"></a>
### What is oneM2M? ### 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. oneM2M is a global organization that creates requirements, architecture, API specifications, security solutions and interoperability for Machine-to-Machine and IoT technologies.
...@@ -38,22 +38,24 @@ Service Layer aspects with high level and detailed service architecture, in ligh ...@@ -38,22 +38,24 @@ Service Layer aspects with high level and detailed service architecture, in ligh
[http://www.onem2m.org](http://www.onem2m.org) [http://www.onem2m.org](http://www.onem2m.org)
<a name="working"></a> <a id="working"></a>
## Working with the SDT ## Working with the SDT
<a name="working"></a> <a id="working"></a>
### How to build the SDT ### How to build the SDT
Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md). Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md).
In short: In short:
- Clone the SDT repository from [https://git.onem2m.org/MAS/SDT.git](https://git.onem2m.org/MAS/SDT.git)
- Install Apache ant
- In a terminal, go to the directoy *SDT/schema4.0* - In a terminal, go to the directoy *SDT/schema4.0*
- Run the command: - Run the command:
```sh ```sh
$ ant $ ant
``` ```
<a name="validate"></a> <a id="validate"></a>
### How to validate own templates ### How to validate own templates
Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md). Please follow the instructions for the [SDT Build System](SDT/schema4.0/docs/SDT%20Build%20System.md).
...@@ -66,7 +68,7 @@ In short: ...@@ -66,7 +68,7 @@ In short:
$ ant validate $ ant validate
``` ```
<a name="tools"></a> <a id="tools"></a>
### Are there tools to work with the SDT? ### 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. 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.
......
SDT/schema4.0/docs/Introduction.md
+ 27
− 22
View file @ 600de362
...@@ -6,19 +6,20 @@ ...@@ -6,19 +6,20 @@
3. [How should SDT work?](#Work) 3. [How should SDT work?](#Work)
4. [Related aspects which are out of scope of the SDT](#related) 4. [Related aspects which are out of scope of the SDT](#related)
<a name="Introduction"/></a> <a id="Introduction"/></a>
## Introduction ## Introduction
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. 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. 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, ...). At the time of writing, every software developed for Internet-of-Things gateways and applications, for example gateways for home or building 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, testing and updating code. The purpose of the 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 (C/C++, Go, Java, Javascript, Python, ...).
### Goals
The key goals of the SDT are: The key goals of the SDT are:
1. keep it simple, especially for manufacturers to contribute device information; 1. keep it simple, especially for manufacturers to contribute device information;
2. modularity for functions and device types; 2. enable and support modularity for functions and device types;
3. make it easy for developers to create unified APIs; 3. make it easy for developers to create unified APIs;
4. be independent of underlying LAN technologies and protocols; 4. be independent of underlying LAN technologies and protocols;
5. enable extendibility of the system in place without service interruption; 5. enable extendibility of the system in place without service interruption;
...@@ -26,62 +27,66 @@ The key goals of the SDT are: ...@@ -26,62 +27,66 @@ The key goals of the SDT are:
In general a description of device (or complex appliance) behaviour can be made in many ways, with various kinds of constraints: In general a description of device (or complex appliance) behaviour can be made in many ways, with various kinds of constraints:
1. no constraints (e.g. using OWL 2.0 or even more "flexibly" RDF) 1. no constraints (e.g. using OWL 2.0 or RDF)
2. moderate constraints (e.g. using XML and a related extensible XSD template) 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) 3. strict constraints (typical for a device certified to interoperate with a specific LAN protocol)
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. 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.
### Guidelines for Structured Information Models
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. 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 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). 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 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. The SDT approach is to define re-usable basic functions (or services), labelled "[ModuleClass](SDT_Components.md#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](SDT_Components.md#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 for a generic device (UML, basic entities)](images/SDT_simplified.png) ![SmartHome Device Template for a generic device (UML, basic entities)](images/SDT_simplified.png)
**SmartHome Device Template for a generic device (UML, basic entities)** **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 schema is achieved with re-usable XML fragments (for example the "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 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. Complex [Devices](SDT_Components.md#Devices), appliances or even [Products](SDT_Components.md#Products) can then be described by an appropriate set or collection of the agreed [ModuleClasses](SDT_Components.md#ModuleClass), as indicated in the figure, which also shows an optional "[Property](SDT_Components.md#Property)" fragment to allow noting of static information such as device manufacturer name, device firmware version, etc.
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). 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 "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 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](SDT_Components.md#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. 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 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. 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> <a id="Definitions"/></a>
## Definitions ## Definitions
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: 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 | | Term | Definition |
|------|------------| |------|------------|
|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) | |[Domain](SDT_Components.md#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. | |[ProductClass](SDT_Components.md#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. | |[DeviceClass](SDT_Components.md#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. | |[Sub-Device](SDT_Components.md#SubDevice) | 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. | | [ModuleClass](SDT_Components.md#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. |
A major decision, facilitating validation of code and signaling, was to describe services (functionality) of devices in terms of [ModuleClasses](SDT_Components.md#ModuleClass) 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](SDT_Components.md#DataPoint) which are aspects of a functionality that can be read and/or written,
2. [Actions](SDT_Components.md#Action) which consist of more complex sequences of operations;
3. [Events](SDT_Components.md#Event) which can be signaled ("published") by devices asynchronously.
1. DataPoints which are aspects of a functionality that can be read and/or written, Any of these elements is optional.
2. Actions which consist of more complex sequences of operations;
3. Events which can be signaled ("published") by devices asynchronously.
The ModuleClass structure is a major part of the SDT which is illustrated in detail in the following figure: This [ModuleClass](SDT_Components.md#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 DataPoints, Actions, and Events](images/MC.Action.DataPoint.Event.png) ![UML description of device functionality in terms of DataPoints, Actions, and Events](images/MC.Action.DataPoint.Event.png)
**UML description of device functionality in terms of DataPoints, Actions, and Events** **UML description of device functionality in terms of DataPoints, Actions, and Events**
<a name="Work"/></a> <a id="Work"/></a>
## How should SDT work? ## 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. The basic concept is that a manufacturer, organisation, service provider 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.
Assuming that the XML files conform to the specified XSD and to some guidelines described in this document, software developers could readily create APIs able to "parse" the XML-descriptions of devices and (assuming the underlying LAN technology of the device is supported by the software/hardware environment in the gateway) operate the equipment. Assuming that the XML files conform to the specified XSD and to some guidelines described in this document, software developers could readily create APIs able to "parse" the XML-descriptions of devices and (assuming the underlying LAN technology of the device is supported by the software/hardware environment in the gateway) operate the equipment.
...@@ -89,12 +94,12 @@ The key to making software reliably interoperate with various technologies is to ...@@ -89,12 +94,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. 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> <a id="related"/></a>
## Related aspects which are out of scope of the SDT ## 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, and (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 (a) software APIs written based on a particular SDT and (b) 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" (or "service 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. 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.
......
SDT/schema4.0/docs/Links.md
+ 0
− 3
View file @ 600de362
...@@ -3,9 +3,6 @@ ...@@ -3,9 +3,6 @@
## Smart Device Template ## Smart Device Template
- **SDT Repository** : [https://git.onem2m.org/MAS/SDT](https://git.onem2m.org/MAS/SDT) - **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) - **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) - **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)
......
SDT/schema4.0/docs/SDT Build System Components and Licenses.md
+ 3
− 3
View file @ 600de362
...@@ -7,7 +7,7 @@ The following third-party libraries and components are used in the build system ...@@ -7,7 +7,7 @@ The following third-party libraries and components are used in the build system
3. [antSetLogLevel.JAR](#antSetLogLevel) 3. [antSetLogLevel.JAR](#antSetLogLevel)
<a name="trang"/></a> <a id="trang"/></a>
## trang.jar ## trang.jar
[https://relaxng.org/jclark/trang.html](https://relaxng.org/jclark/trang.html) [https://relaxng.org/jclark/trang.html](https://relaxng.org/jclark/trang.html)
...@@ -53,7 +53,7 @@ LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING ...@@ -53,7 +53,7 @@ LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<a name="antcontrib"/></a> <a id="antcontrib"/></a>
## Ant-Contrib Tasks ## Ant-Contrib Tasks
[http://ant-contrib.sourceforge.net](http://ant-contrib.sourceforge.net) [http://ant-contrib.sourceforge.net](http://ant-contrib.sourceforge.net)
...@@ -64,7 +64,7 @@ The *Ant-Contrib* project is a collection of tasks (and at one point maybe types ...@@ -64,7 +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. This Software is distributed under the Apache Software License.
<a name="antSetLogLevel"/></a> <a id="antSetLogLevel"/></a>
## antSetLogLevel.jar ## antSetLogLevel.jar
GUI dialog for Ant tasks. GUI dialog for Ant tasks.
......
SDT/schema4.0/docs/SDT Build System.md
+ 10
− 9
View file @ 600de362
# SDT Build System # SDT Build System
This document describes the SDT build system and how to build the SDT and validate new templates and contributions. This document describes the SDT build system and how to build the SDT schema and validate new templates and contributions.
The files referenced in this document point to version **4.0** of the SDT. The files referenced in this document point to version **4.0** of the SDT.
...@@ -11,12 +11,13 @@ The files referenced in this document point to version **4.0** of the SDT. ...@@ -11,12 +11,13 @@ The files referenced in this document point to version **4.0** of the SDT.
2. [Validating SDT Templates](#BuildingValidate) 2. [Validating SDT Templates](#BuildingValidate)
4. [Editing the Schema](#Editing) 4. [Editing the Schema](#Editing)
<a name="Structure"/></a> <a id="Structure"/></a>
## Directory Structure and Important Files ## Directory Structure and Important Files
- [SDT/schema4.0/](../..) : Base directory - [SDT/schema4.0/](../..) : Base directory
- [SDT/schema4.0/src/](../src/) : Source files of the SDT. - [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). - [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 you want to make changes to the SDT!** See also [Editing the Schema](#Editing) below. **Only edit this file when you want to make changes to the SDT! Changes to XSD file will be overwritten the next time you run the *ant* command.**
See also [Editing the Schema](#Editing) below.
- [domain.xsd](../src/domain.xsd) : The actual SDT schema definition that is generated from *domain.rng*. - [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 - [xml.xsd](../src/xml.xsd) : General schema definitions for the SDT
- [SDT/schema4.0/test/](../test/) : This directory contains XML files with SDT definitions that should be validated whether they conform to the SDT schema. - [SDT/schema4.0/test/](../test/) : This directory contains XML files with SDT definitions that should be validated whether they conform to the SDT schema.
...@@ -29,7 +30,7 @@ This could be example definitions or new templates and contributions. If you wan ...@@ -29,7 +30,7 @@ This could be example definitions or new templates and contributions. If you wan
- [SDT/schema4.0/etc/schema.xmlns](../etc/schema.xmlns) : This file defines the target namespace for the schema. - [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). - [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> <a id="Installation"/></a>
## Installation ## Installation
### Prerequisites ### Prerequisites
...@@ -41,18 +42,18 @@ This could be example definitions or new templates and contributions. If you wan ...@@ -41,18 +42,18 @@ This could be example definitions or new templates and contributions. If you wan
$ git clone https://git.onem2m.org/MAS/SDT.git $ git clone https://git.onem2m.org/MAS/SDT.git
<a name="Building"/></a> <a id="Building"/></a>
## How to Use the Build System ## How to Use the Build System
After cloning the repository go to the directory *SDT/schema4.0* 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.
<a name="BuildingSchema"/></a> <a id="BuildingSchema"/></a>
### Building the Schema ### 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) 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/schema4.0 $ cd SDT/schema4.0
$ ant $ ant
<a name="BuildingValidate"/></a> <a id="BuildingValidate"/></a>
### Validating SDT Templates ### 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: You can use the build system to validate new SDT definitions or changes made to existing ones by running the following command:
...@@ -65,12 +66,12 @@ The output after a successful validation should look similar this: ...@@ -65,12 +66,12 @@ The output after a successful validation should look similar this:
>BUILD SUCCESSFUL >BUILD SUCCESSFUL
>Total time: 1 second >Total time: 1 second
Otherwise you most likely receive a stack trace or some other error messages. Search the output for the line *BUILD FAILED*. Above this line you will find some helpful hints for the filename and line number on which the error occurred (here: file *mseeb.xml* on line 66) and a reason: Otherwise you most likely receive a stack trace and some other error messages. Search the output for the line *BUILD FAILED*. Above this line you will find some helpful hints for the filename and line number on which the error occurred (here: file *mseeb.xml* on line 66) and a reason:
>[schemavalidate] /Users/someone/Sources/git/SmartDeviceTemplate/SDT/schema/test/mseeb.xml:66:18: cvc-elt.1: Cannot find the declaration of element 'Domain'. >[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 >BUILD FAILED
<a name="Editing"/></a> <a id="Editing"/></a>
## Editing the Schema ## 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. 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.
......
SDT/schema4.0/docs/SDT_Components.md
+ 209
− 197
View file @ 600de362
...@@ -3,41 +3,40 @@ ...@@ -3,41 +3,40 @@
## Table of Contents ## Table of Contents
1. [Basic Components](#BasicComponents) 1. [Basic Components](#BasicComponents)
1. [Domain](#Domain) 1. [Domain](#Domain)
2. [ModuleClass](#ModuleClass) 2. [ModuleClass](#ModuleClass)
1. [DataPoint](#DataPoint) 1. [DataPoint](#DataPoint)
2. [Action](#Action) 2. [Action](#Action)
1. [Arg](#Arg) 1. [Arg](#Arg)
3. [Event](#Event) 3. [Event](#Event)
4. [DeviceClass](#DeviceClass) 4. [DeviceClass](#DeviceClass)
1. [SubDevice](#SubDevice) 1. [SubDevice](#SubDevice)
5. [ProductClass](#ProductClass) 5. [ProductClass](#ProductClass)
6. [Property](#Property) 6. [Property](#Property)
2. [Data Types](#DataTypes) 2. [Data Types](#DataTypes)
1. [DataType](#DataType) 1. [DataType](#DataType)
1. [Constraint](#Constraint) 1. [Constraint](#Constraint)
2. [TypeChoice](#TypeChoice) 2. [TypeChoice](#TypeChoice)
2. [SimpleType](#SimpleType) 2. [SimpleType](#SimpleType)
3. [StructType](#StructType) 3. [StructType](#StructType)
4. [ArrayType](#ArrayType) 4. [ArrayType](#ArrayType)
5. [EnumType](#EnumType) 5. [EnumType](#EnumType)
1. [ExtendExclude](#ExtendExclude) 1. [ExtendExclude](#ExtendExclude)
3. [Extending (Inheriting)](#Extending) 3. [Extending (Inheriting)](#Extending)
1. [Extend](#Extend) 1. [Extend](#Extend)
1. [Include](#ExtendInclude) 1. [Include](#ExtendInclude)
2. [Exclude](#ExtendExclude) 2. [Exclude](#ExtendExclude)
3. [ExtendType](#ExtendType) 3. [ExtendType](#ExtendType)
4. [Documentation (Doc)](#Documentation) 4. [Documentation (Doc)](#Documentation)
--- ---
## SDT Overview ## 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 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 following UML diagrams 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 and the snippets in the following sections follow this figure:
![](images/SDT_UML_Key.png) ![](images/SDT_UML_Key.png)
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 diagrams to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
...@@ -47,17 +46,17 @@ The syntax used in the diagrams to model an XML Schema Definition (XSD) as an UM ...@@ -47,17 +46,17 @@ The syntax used in the diagrams to model an XML Schema Definition (XSD) as an UM
- [UML For W3C XML Schema Design](http://www.xml.com/pub/a/2002/08/07/wxs_uml.html) - [UML For W3C XML Schema Design](http://www.xml.com/pub/a/2002/08/07/wxs_uml.html)
<a name="BasicComponents"></a> <a id="BasicComponents"></a>
## Basic Elements ## Basic Elements
![](images/SDT_UML_Basic_Elements.png) ![](images/SDT_UML_Basic_Elements.png)
<a name="Domain"></a> <a id="Domain"></a>
### Domain ### Domain
![](images/Domain.png) ![](images/Domain.png)
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. 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), [DeviceClasses](#DeviceClasss), [DataTypes](#DataTypes) and [ProductClasses](#ProductClasses) 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.
...@@ -77,37 +76,40 @@ Note, that when using **Imports** one must include the following namespace in th ...@@ -77,37 +76,40 @@ Note, that when using **Imports** one must include the following namespace in th
#### Example #### Example
```xml ```xml
<Domain xmlns:xi="http://www.w3.org/2001/XInclude" <Domain xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns="http://homegatewayinitiative.org/xml/dal/3.0" xmlns="http://www.onem2m.org/xml/sdt/4.0">
id="org.homegatewayinitiative"> id="org.onem2m.home.device">
<Doc>Some documentation</Doc>
<Imports> <Doc>Some documentation</Doc>
<!-- Import other SDTs via XInclude's include mechanism --> <Imports>
<xi:include href="anotherSDT.xml" parse="xml" /> <!-- Import other SDTs via XInclude's include mechanism -->
</Imports> <xi:include href="anotherSDT.xml" parse="xml" />
<ModuleClasses> </Imports>
<!-- List of Domain global ModuleClasses goes here --> <ModuleClasses>
</ModuleClasses> <!-- List of Domain global ModuleClasses goes here -->
<DeviceClasses> </ModuleClasses>
<!-- List of Devices goes here --> <DeviceClasses>
</DeviceClasses> <!-- List of Devices goes here -->
</DeviceClasses>
</Domain> </Domain>
``` ```
--- ---
<a name="ModuleClass"/></a> <a id="ModuleClass"/></a>
### ModuleClass ### ModuleClass
Element of [Domain](#Domain) and [Product](#Product). Element of [Domain](#Domain) and [Product](#Product).
![](images/ModuleClass.png) ![](images/ModuleClass.png)
*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. *ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). *ModuleClasses* are the central element of the SDT to wrap functionalities.
A *ModuleClass* can extend another *ModuleClass* with additional functionalities.
Every [DeviceClass](#DeviceClass) can be described by a collection of *ModuleClasses* (functionality). Every [DeviceClass](#DeviceClass) can be described by a collection of *ModuleClasses* (functionality).
The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [DeviceClass](#DeviceClass). The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [DeviceClass](#DeviceClass).
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). 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 system architects and 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](#DeviceClass) and [SubDevice](#SubDevice) models).
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. 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.
...@@ -116,6 +118,11 @@ Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "Pa ...@@ -116,6 +118,11 @@ Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "Pa
- **name** : Name of the *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). 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*. - **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. - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
- **minOccurs** : An optional string attribute that indicates the minimum cardinality of a *ModuleClass*, for example, in a [DeviceClass](#DeviceClass) definition. Optional. The default is "1".
Note, if only the *minOccurs* attribute is specified, it can't be greater than 1, because the default value for *maxOccurs* is 1.
- **maxOccurs** : An optional string attribute that indicates the maximum cardinality of a *ModuleClass*, for example, in a [DeviceClass](#DeviceClass) definition. Optional. The default is "1".
Note, if only the *maxOccurs* attribute is specified, it can't be smaller than 1, because the default value for *minOccurs* is 1.
Also note, that if both *minOccurs* and *maxOccurs* are specified, then *maxOccurs* always must have an equal or higher cardinality than *minOccurs*.
#### Elements #### Elements
...@@ -129,22 +136,22 @@ Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "Pa ...@@ -129,22 +136,22 @@ Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "Pa
#### Example #### Example
```xml ```xml
<ModuleClass name="BooleanState"> <ModuleClass name="BooleanState">
<Doc>Some documentation</Doc> <Doc>Some documentation</Doc>
<Actions> <Actions>
<!-- List of Actions goes here--> <!-- List of Actions goes here-->
</Actions> </Actions>
<Events> <Events>
<!-- List of Events goes here--> <!-- List of Events goes here-->
</Events> </Events>
<Data> <Data>
<!-- List of DataPoints goes here--> <!-- List of DataPoints goes here-->
</Data> </Data>
</ModuleClass> </ModuleClass>
``` ```
--- ---
<a name="DataPoint"/></a> <a id="DataPoint"/></a>
### DataPoint ### DataPoint
Element of [ModuleClass](#ModuleClass) and [Event](#Event). Element of [ModuleClass](#ModuleClass) and [Event](#Event).
...@@ -175,7 +182,7 @@ string = (* character string excluding the character "/" *) ; ...@@ -175,7 +182,7 @@ string = (* character string excluding the character "/" *) ;
- **readable** : Boolean value that indicates whether this *DataPoint* is readable 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. - **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*. - **default** : A default value for the *DataPoint*.
- - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional. - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements #### Elements
- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional. - **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
...@@ -184,25 +191,25 @@ string = (* character string excluding the character "/" *) ; ...@@ -184,25 +191,25 @@ string = (* character string excluding the character "/" *) ;
#### Example #### Example
```xml ```xml
<Data> <Data>
<DataPoint name="attributeName" writable="false"> <DataPoint name="attributeName" writable="false">
<Doc>Some documentation for the DataPoint</Doc> <Doc>Some documentation for the DataPoint</Doc>
<DataType> <DataType>
<SimpleType type="string" /> <SimpleType type="string" />
</DataType </DataType
</DataPoint> </DataPoint>
</Data> </Data>
``` ```
--- ---
<a name="Action"/></a> <a id="Action"/></a>
### Action ### Action
Element of [ModuleClass](#ModuleClass). Element of [ModuleClass](#ModuleClass).
![](images/Action.png) ![](images/Action.png)
*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. *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 (see [Args](#Arg)) with the method which checks and executes them, in one step.
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. 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.
...@@ -216,30 +223,30 @@ Note, that systems which rely on RESTful operations need to carry out such compl ...@@ -216,30 +223,30 @@ Note, that systems which rely on RESTful operations need to carry out such compl
- **[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. - **[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. - **[Args](#Arg)** : Zero or more occurances of argument definitions for an *Action*. Optional.
<a name="ActionExample"/></a> <a id="ActionExample"/></a>
#### Example #### Example
The following are two examples for actions implementing a getter and a setter for boolean values. The following are two examples for actions implementing a getter and a setter for boolean values.
```xml ```xml
<Action name="get" type="boolean"> <Action name="get" type="boolean">
<Doc>Obtain the current associated state. Example of a getter.</Doc> <Doc>Obtain the current associated state. Example of a getter.</Doc>
</Action> </Action>
<Action name="setTarget"> <Action name="setTarget">
<Doc>Set the associated state to the specified value. Example of a setter.</Doc> <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
<Args> <Args>
<Arg name="value"> <Arg name="value">
<Doc>The desired value of the associated state.</Doc> <Doc>The desired value of the associated state.</Doc>
<DataType> <DataType>
<SimpleType type="boolean" /> <SimpleType type="boolean" />
</DataType> </DataType>
</Arg> </Arg>
</Args> </Args>
</Action> </Action>
``` ```
--- ---
<a name="Arg"/></a> <a id="Arg"/></a>
### Arg ### Arg
Element of [Action](#Action). Element of [Action](#Action).
...@@ -260,11 +267,11 @@ The *Arg* has the following attributes and elements: ...@@ -260,11 +267,11 @@ The *Arg* has the following attributes and elements:
- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required. - **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
#### Example #### Example
See [example above](#ActionExample). See [the Action example above](#ActionExample).
--- ---
<a name="Event"/></a> <a id="Event"/></a>
### Event ### Event
Element of [ModuleClass](#ModuleClass). Element of [ModuleClass](#ModuleClass).
...@@ -284,19 +291,19 @@ Element of [ModuleClass](#ModuleClass). ...@@ -284,19 +291,19 @@ Element of [ModuleClass](#ModuleClass).
#### Example #### Example
```xml ```xml
<Event name="stateChanged"> <Event name="stateChanged">
<Doc>Some documentation for the Event</Doc> <Doc>Some documentation for the Event</Doc>
<Data> <Data>
<DataPoint name="state"> <DataPoint name="state">
<DataType> <DataType>
<SimpleType type="boolean" /> <SimpleType type="boolean" />
</DataType> </DataType>
</DataPoint> </DataPoint>
</Data> </Data>
</Event> </Event>
``` ```
--- ---
<a name="DeviceClass"/></a> <a id="DeviceClass"/></a>
### DeviceClass ### DeviceClass
Element of [Domain](#Domain) and [Product](#Product). Element of [Domain](#Domain) and [Product](#Product).
...@@ -304,9 +311,9 @@ Element of [Domain](#Domain) and [Product](#Product). ...@@ -304,9 +311,9 @@ Element of [Domain](#Domain) and [Product](#Product).
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. 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.
Note, that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass). Note, that all the different devices which one needs to model within a domain are composed of one or more [ModuleClasses](#ModuleClass).
For each physical device on the network at least one *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. For each physical device type 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.
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". 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".
...@@ -326,34 +333,39 @@ An example for a compound device is a connected power-strip where each of the s ...@@ -326,34 +333,39 @@ An example for a compound device is a connected power-strip where each of the s
#### Example #### Example
```xml ```xml
<Device id="aDevice"> <Device id="aDevice">
<Doc>Some documentation</Doc> <Doc>Some documentation</Doc>
<Properties> <Properties>
<!-- The list of Properties for the Device goes here--> <!-- The list of Properties for the Device goes here-->
</Properties> </Properties>
<ModuleClasses> <ModuleClasses>
<!-- List of ModuleClasses local to the Device goes here--> <!-- List of ModuleClasses local to the Device goes here-->
</ModuleClasses> </ModuleClasses>
<SubDevices> <SubDevices>
<!-- List of Sub-Devices of the Device goes here--> <!-- List of Sub-Devices of the Device goes here-->
</SubDevices> </SubDevices>
</Device> </Device>
``` ```
--- ---
<a name="SubDevice"/></a> <a id="SubDevice"/></a>
### SubDevice ### SubDevice
Element of [DeviceClass](#DeviceClass) and [Product](#Product). Element of [DeviceClass](#DeviceClass) and [Product](#Product).
*SubDevices* are optional components of a [DeviceClass](#DeviceClass). They represent physical sub-devices and services inside another device (the *DeviceClass*). *SubDevices* are optional components of a [DeviceClass](#DeviceClass). They represent physical sub-devices and services inside another device (the *DeviceClass*).
*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain). *SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of its or another [Domain](#Domain).
![](images/SubDevice.png) ![](images/SubDevice.png)
#### Attributes #### 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. - **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. - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
- **minOccurs** : An optional string attribute that indicates the minimum cardinality of a *SubDevice*, for example, in a [DeviceClass](#DeviceClass) definition. Optional. The default is "1".
Note, if only the *minOccurs* attribute is specified, it can't be greater than 1, because the default value for *maxOccurs* is 1.
- **maxOccurs** : An optional string attribute that indicates the maximum cardinality of a *SubDevice*, for example, in a [DeviceClass](#DeviceClass) definition. Optional. The default is "1".
Note, if only the *maxOccurs* attribute is specified, it can't be smaller than 1, because the default value for *minOccurs* is 1.
Also note, that if both *minOccurs* and *maxOccurs* are specified, then *maxOccurs* always must have an equal or higher cardinality than *minOccurs*.
#### Elements #### Elements
- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional. - **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
...@@ -363,30 +375,30 @@ Element of [DeviceClass](#DeviceClass) and [Product](#Product). ...@@ -363,30 +375,30 @@ Element of [DeviceClass](#DeviceClass) and [Product](#Product).
#### Example #### Example
```xml ```xml
<SubDevice id="aSubDevice"> <SubDevice id="aSubDevice">
<Doc>Some documentation</Doc> <Doc>Some documentation</Doc>
<Properties> <Properties>
<!-- The list of Properties for the Device goes here--> <!-- The list of Properties for the Device goes here-->
</Properties> </Properties>
<ModuleClasses> <ModuleClasses>
<!-- List of ModuleClasses local to the Device goes here--> <!-- List of ModuleClasses local to the Device goes here-->
</ModuleClasses> </ModuleClasses>
</SubDevice> </SubDevice>
``` ```
--- ---
<a name="ProductClass"/></a> <a id="ProductClass"/></a>
### ProductClass ### ProductClass
Element of [Domain](#Domain). Element of [Domain](#Domain).
![](images/Product.png) ![](images/Product.png)
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). 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 features, using [ModuleClasses](#ModuleClass) to model the functionalities. 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. 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.
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. In short, a *ProductClass* is a concrete device model with deterministic [device Properties](#Property) and [ModuleClasses](#ModuleClass) without any 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.
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)). A *ProductClass* can be defined by implementing the functionalities of an existing [DeviceClass](#DeviceClass) while removing unimplemented optional [ Properties](#Property) and [ModuleClasses](#ModuleClass)), by extending from an existing [DeviceClass](#DeviceClass) and adding new [Properties](#Property) and [ModuleClasses](#ModuleClass), or from scratch not re-using on any [DeviceClass](#DeviceClass).
#### Attributes #### Attributes
- **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. - **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.
...@@ -407,35 +419,35 @@ All elements of [DeviceClass](#DeviceClass) can be reused in *ProductClass*, but ...@@ -407,35 +419,35 @@ All elements of [DeviceClass](#DeviceClass) can be reused in *ProductClass*, but
#### Example #### Example
```xml ```xml
<ProductClass id="TestProductClass"> <ProductClass id="TestProductClass">
<Doc>This is a new product</Doc> <Doc>This is a new product</Doc>
<Properties> <Properties>
<Property name="name" value="product-abc"> <Property name="name" value="product-abc">
<SimpleType type="string"></SimpleType> <SimpleType type="string"></SimpleType>
</Property> </Property>
<Property name="vendor" value="xyz"/> <Property name="vendor" value="xyz"/>
<SimpleType type="string"></SimpleType> <SimpleType type="string"></SimpleType>
</Property> </Property>
<Property name="SerialNumber"/> <Property name="SerialNumber"/>
<SimpleType type="string"></SimpleType> <SimpleType type="string"></SimpleType>
</Property> </Property>
</Properties> </Properties>
<ModuleClasses> <ModuleClasses>
<ModuleClass name="aModuleClass"> <ModuleClass name="aModuleClass">
<Extend domain="adomain" entity="aModuleClass" /> <Extend domain="adomain" entity="aModuleClass" />
</ModuleClass> </ModuleClass>
<ModuleClass name="newModuleClass"> <ModuleClass name="newModuleClass">
<!-- List of Actions, Events and DataPoints goes here--> <!-- List of Actions, Events and DataPoints goes here-->
</ModuleClass> </ModuleClass>
</ModuleClasses> </ModuleClasses>
<ExtendDevice> <ExtendDevice>
<Extend domain="adomain" entity="aDeviceClass" /> <Extend domain="adomain" entity="aDeviceClass" />
</ExtendDevice> </ExtendDevice>
</ProductClass> </ProductClass>
``` ```
--- ---
<a name="Property"/></a> <a id="Property"/></a>
### Property ### Property
Element of a [ProductClass](#ProductClass), [DeviceClass](#DeviceClass), [SubDevice](#SubDevice), and [ModuleClass](#ModuleClass). Element of a [ProductClass](#ProductClass), [DeviceClass](#DeviceClass), [SubDevice](#SubDevice), and [ModuleClass](#ModuleClass).
...@@ -460,13 +472,13 @@ Since the *Properties* are highly varied, depending on industry segment, no atte ...@@ -460,13 +472,13 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
#### Example #### Example
```xml ```xml
<Property name="ManufacturedDate" value="2015.10.30 10:06"> <Property name="ManufacturedDate" value="2015.10.30 10:06">
<SimpleType type="datetime" /> <SimpleType type="datetime" />
</Property> </Property>
``` ```
--- ---
<a name="DataTypes"/></a> <a id="DataTypes"/></a>
## Data Types ## Data Types
...@@ -479,7 +491,7 @@ The various elements of *DataType* are described in the following sections. ...@@ -479,7 +491,7 @@ 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). *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="DataType"/></a> <a id="DataType"/></a>
### DataType ### DataType
Element of a [Domain](#Domain), [Property](#Property), [Action](#Action), [Arg](#Arg), [DataPoint](#DataPoint), [Event](#Event), [StructType](#StructType), and [ArrayType](#ArrayType). Element of a [Domain](#Domain), [Property](#Property), [Action](#Action), [Arg](#Arg), [DataPoint](#DataPoint), [Event](#Event), [StructType](#StructType), and [ArrayType](#ArrayType).
...@@ -496,15 +508,15 @@ The *DataType* element is a "container" for the various aspects of a type. ...@@ -496,15 +508,15 @@ The *DataType* element is a "container" for the various aspects of a type.
#### Elements #### Elements
- **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional. - **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional.
- **TypeChoice** : This element is actual an element from the following list of data types: - **TypeChoice** : This element is actual an element from the following list of data types:
- **[SimpleType](#SimpleType)** - **[SimpleType](#SimpleType)**
- **[Struct](#StructType)** - **[Struct](#StructType)**
- **[Array](#ArrayType)** - **[Array](#ArrayType)**
- **[EnumType](#EnumType)** - **[EnumType](#EnumType)**
- **[Constraint](#Constraint)** : A list of *Constraint* elements. Optional. - **[Constraint](#Constraint)** : A list of *Constraint* elements. Optional.
--- ---
<a name="Constraint"/></a> <a id="Constraint"/></a>
### Constraint ### Constraint
Element of [DataType](#DataType). Element of [DataType](#DataType).
...@@ -532,7 +544,7 @@ The *TypeChoice* construct is required for syntactic reasons in the UML diagram ...@@ -532,7 +544,7 @@ The *TypeChoice* construct is required for syntactic reasons in the UML diagram
--- ---
<a name="SimpleType"/></a> <a id="SimpleType"/></a>
### SimpleType ### SimpleType
Element of [DataType](#DataType). Element of [DataType](#DataType).
...@@ -564,14 +576,14 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi ...@@ -564,14 +576,14 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi
### Example ### Example
```xml ```xml
<DataPoint name="simpleDataPoint"> <DataPoint name="simpleDataPoint">
<DataType> <DataType>
<SimpleType type="string" /> <SimpleType type="string" />
</DataType> </DataType>
</DataPoint> </DataPoint>
``` ```
--- ---
<a name="StructType"/></a> <a id="StructType"/></a>
### StructType ### StructType
Element of [DataType](#DataType). Element of [DataType](#DataType).
...@@ -585,22 +597,22 @@ The *StructType* element can be used to represent an ordered list of diverse Dat ...@@ -585,22 +597,22 @@ The *StructType* element can be used to represent an ordered list of diverse Dat
### Example ### Example
```xml ```xml
<DataPoint name="structDataPoint"> <DataPoint name="structDataPoint">
<DataType name="structured"> <DataType name="structured">
<Struct> <Struct>
<DataType name="aString"> <DataType name="aString">
<SimpleType type="string" /> <SimpleType type="string" />
</DataType> </DataType>
<DataType name="anInteger"> <DataType name="anInteger">
<SimpleType type="integer" /> <SimpleType type="integer" />
</DataType> </DataType>
</Struct> </Struct>
</DataType> </DataType>
</DataPoint> </DataPoint>
``` ```
--- ---
<a name="ArrayType"/></a> <a id="ArrayType"/></a>
### ArrayType ### ArrayType
Element of [DataType](#DataType). Element of [DataType](#DataType).
...@@ -615,18 +627,18 @@ The *ArrayType* element is provided for defining lists of data; the definition i ...@@ -615,18 +627,18 @@ The *ArrayType* element is provided for defining lists of data; the definition i
### Example ### Example
```xml ```xml
<DataPoint name="arrayDataPoint"> <DataPoint name="arrayDataPoint">
<DataType name="arrayOfInteger"> <DataType name="arrayOfInteger">
<Array> <Array>
<DataType> <DataType>
<SimpleType type="integer" /> <SimpleType type="integer" />
</DataType> </DataType>
</Array> </Array>
</DataType> </DataType>
</DataPoint> </DataPoint>
``` ```
--- ---
<a name="EnumType"/></a> <a id="EnumType"/></a>
### EnumType ### EnumType
Element of [DataType](#DataType). Element of [DataType](#DataType).
...@@ -637,23 +649,23 @@ The *EnumType* element is provided for defining an enumeration data type; it def ...@@ -637,23 +649,23 @@ The *EnumType* element is provided for defining an enumeration data type; it def
#### Elements #### Elements
- **[EnumValue](#EnumValue)** : A list of *EnumValue" element that specifies the data type for the elements of the array. - **[EnumValue](#EnumValue)** : A list of *EnumValue" element that specifies the data type for the elements of the array.
<a name="EnumTypeExample"/></a> <a id="EnumTypeExample"/></a>
#### Example #### Example
```xml ```xml
<DataPoint name="enumDataPoint"> <DataPoint name="enumDataPoint">
<DataType name="enumOfInteger"> <DataType name="enumOfInteger">
<Enum> <Enum>
<EnumValue name="red" value="1" type="integer" /> <EnumValue name="red" value="1" type="integer" />
<EnumValue name="green" value="2" /> <EnumValue name="green" value="2" />
<EnumValue name="blue" value="3" /> <EnumValue name="blue" value="3" />
</Enum> </Enum>
</DataType> </DataType>
</DataPoint> </DataPoint>
``` ```
--- ---
<a name="EnumValue"/></a> <a id="EnumValue"/></a>
### EnumValue ### EnumValue
Element of [EnumType](#EnumType). Element of [EnumType](#EnumType).
...@@ -675,7 +687,7 @@ See [example in *EnumType*](#EnumTypeExample). ...@@ -675,7 +687,7 @@ See [example in *EnumType*](#EnumTypeExample).
--- ---
<a name="Extending"/></a> <a id="Extending"/></a>
## Extending (Inheriting) ## Extending (Inheriting)
The SDT supports inhering for certain element types. This is done by extending a parent element definition. The SDT supports inhering for certain element types. This is done by extending a parent element definition.
...@@ -686,34 +698,34 @@ Extension across [Domains](#Domain) is supported and encouraged. ...@@ -686,34 +698,34 @@ Extension across [Domains](#Domain) is supported and encouraged.
![](images/SDT_UML_Extend.png) ![](images/SDT_UML_Extend.png)
<a name="ExtendExample"/></a> <a id="ExtendExample"/></a>
#### Example #### Example
The following example defines two [ModuleClasses](#ModuleClass), where the second definition extends to first one, but explicitly excludes one of the [DataPoints](#DataPoint). The following example defines two [ModuleClasses](#ModuleClass), where the second definition extends to first one, but explicitly excludes one of the [DataPoints](#DataPoint).
```xml ```xml
<ModuleClasses> <ModuleClasses>
<ModuleClass name="aModuleClass"> <ModuleClass name="aModuleClass">
<Data> <Data>
<DataPoint name="dataPoint1"> <DataPoint name="dataPoint1">
<!-- type definition --> <!-- type definition -->
</DataPoint> </DataPoint>
<DataPoint name="dataPoint2"> <DataPoint name="dataPoint2">
<!-- type definition --> <!-- type definition -->
</DataPoint> </DataPoint>
</Data> </Data>
</ModuleClass> </ModuleClass>
<ModuleClass name="anotherModuleClass"> <ModuleClass name="anotherModuleClass">
<Extend domain="aDomain" entity="aModuleClass"> <Extend domain="aDomain" entity="aModuleClass">
<Exclude name="dataPoint2" type="datapoint" /> <Exclude name="dataPoint2" type="datapoint" />
</Extend> </Extend>
<!-- more local definitions, such as Actions, DataPoints etc --> <!-- more local definitions, such as Actions, DataPoints etc -->
</ModuleClass> </ModuleClass>
</ModuleClasses> </ModuleClasses>
``` ```
--- ---
<a name="Extend"/></a> <a id="Extend"/></a>
### Extend ### Extend
Element of [ProductClass](#ProductClass), [ModuleClass](#ModuleClass) and [DataType](#DataType). Element of [ProductClass](#ProductClass), [ModuleClass](#ModuleClass) and [DataType](#DataType).
...@@ -729,15 +741,15 @@ Please note, that it is only possible to either [Include](#ExtendInclude) or [Ex ...@@ -729,15 +741,15 @@ Please note, that it is only possible to either [Include](#ExtendInclude) or [Ex
#### Elements #### 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. - **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)** - **[Include](#ExtendInclude)**
- **[Exclude](#ExtendExclude)** - **[Exclude](#ExtendExclude)**
#### Example #### Example
See [example in *Extending (Inheriting)*](#ExtendExample). See [example in *Extending (Inheriting)*](#ExtendExample).
--- ---
<a name="ExtendInclude"/></a> <a id="ExtendInclude"/></a>
### Include ### Include
Element of [Extend](#Extend). Element of [Extend](#Extend).
...@@ -752,7 +764,7 @@ This element specifies a single element from the parent that will be included wh ...@@ -752,7 +764,7 @@ This element specifies a single element from the parent that will be included wh
--- ---
<a name="ExtendExclude"/></a> <a id="ExtendExclude"/></a>
### Exclude ### Exclude
Element of [Extend](#Extend). Element of [Extend](#Extend).
...@@ -766,7 +778,7 @@ This element specifies a single element from the parent that will be excluded wh ...@@ -766,7 +778,7 @@ This element specifies a single element from the parent that will be excluded wh
--- ---
<a name="ExtendType"/></a> <a id="ExtendType"/></a>
### ExendType ### ExendType
Element of [ExtendInclude](#ExtendInclude) and [ExtendExclude](#ExtendExclude). Element of [ExtendInclude](#ExtendInclude) and [ExtendExclude](#ExtendExclude).
...@@ -776,7 +788,7 @@ This is an enumeration of element types for inclusion or exclusion while extendi ...@@ -776,7 +788,7 @@ This is an enumeration of element types for inclusion or exclusion while extendi
--- ---
<a name="Documentation"/></a> <a id="Documentation"/></a>
## Documentation (Doc) ## Documentation (Doc)
Element for documentation in all elements. Element for documentation in all elements.
......
SDT/schema4.0/docs/SDT_JSON.md
+ 100
− 95
View file @ 600de362
...@@ -17,10 +17,10 @@ ...@@ -17,10 +17,10 @@
<a name="introduction"/></a> <a id="introduction"/></a>
## Introduction ## 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. When the Smart Device Template was introduced, XML was the favorite encoding format for schemas. Since then, JSON became more popular in developers' communities, especially in the context of RESTful implementations.
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)). 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)).
...@@ -30,44 +30,46 @@ There are some open tools such as [JSON Schema](http://json-schema.org/) that mi ...@@ -30,44 +30,46 @@ There are some open tools such as [JSON Schema](http://json-schema.org/) that mi
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. 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). The general JSON structure follows the general SDT structure presented in [SDT_UML.uxf](SDT_UML.uxf) and described in [SDT_Components.md](SDT_Components.md).
<a name="mappings"/></a> <a id="mappings"/></a>
## SDT mapping to JSON ## SDT mapping to JSON
<a name="elements"/></a> <a id="elements"/></a>
### Elements mapping ### Elements mapping
| SDT XML Elements | JSON Key Words | Remark | | SDT XML Elements | JSON Key Words | Remark |
|------------------|----------------|--------| |:-----------------------------------------------|:---------------|:----------------------------------------------------------|
|Action | Action | | | [Action](SDT_Components.md#Action) | Action | |
|Actions | Actions | This element is an array of *Action* structures. | | Actions | Actions | This element is an array of *Action* structures. |
|Arg | Arg | | | [Arg](SDT_Components.md#Arg) | Arg | |
|Args | Args | This element is an array of *Arg* structures. | | Args | Args | This element is an array of *Arg* structures. |
|Constraint | Constraint | | | Constraint | Constraint | |
|Constraints | Constraints | This element is an array of *Constraint* structures. | | Constraints | Constraints | This element is an array of *Constraint* structures. |
|Data | Data | This element is an array of *DataPoint* structures. | | Data | Data | This element is an array of *DataPoint* structures. |
|DataPoint | DataPoint | | | [DataPoint](SDT_Components.md#DataPoint) | DataPoint | |
|DataType | DataType | | | [DataType](SDT_Components.md#DataType) | DataType | |
|DataTypes | DataTypes | This element is an array of *DataType* structures. | | [DataTypes](SDT_Components.md#DataTypes) | DataTypes | This element is an array of *DataType* structures. |
|DeviceClass | DeviceClass | | | [DeviceClass](SDT_Components.md#DeviceClass) | DeviceClass | |
|DeviceClasses | DeviceClasses | This element is an array of *DeviceClass* structures. | | DeviceClasses | DeviceClasses | This element is an array of *DeviceClass* structures. |
|Doc |Doc | | | [Doc](SDT_Components.md#Documentation) | Doc | |
|Domain | Domain | | | [Domain](SDT_Components.md#Domain) | Domain | |
|Event | Event | | | [Event](SDT_Components.md#Event) | Event | |
|Events | Events | This element is an array of *Event* structures. | | Events | Events | This element is an array of *Event* structures. |
|Exclude | Exclude | | | Exclude | Exclude | |
|Extend | Extend | | | Excludes | Excludes | This element is an array of *Exclude* structures. |
|Imports |Imports| This element is an array of *Include* structures. | | [Extend](SDT_Components.md#Extending) | Extend | |
|Include | Include | | | Imports | Imports | This is an array of URLs or file URLs to files to import. |
|ModuleClass | ModuleClass | | | Include | Include | |
|ModuleClasses | ModuleClasses | This element is an array of *ModuleClass* structures. | | Includes | Includes | This element is an array of *Include* structures. |
|ProductClass | ProductClass | | | [ModuleClass](SDT_Components.md#ModuleClass) | ModuleClass | |
|ProductClasses | ProductClasses | This element is an array of *ProductClasses* structures. | | ModuleClasses | ModuleClasses | This element is an array of *ModuleClass* structures. |
|Properties | Properties | This element is an array of *Property* structures. | | [ProductClass](SDT_Components.md#ProductClass) | ProductClass | |
|Property | Property | | | ProductClasses | ProductClasses | This element is an array of *ProductClasses* structures. |
|SubDevice | SubDevice | | | Properties | Properties | This element is an array of *Property* structures. |
|SubDevices | SubDevices | This element is an array of *SubDevice* structures. | | [Property](SDT_Components.md#Property) | Property | |
| [SubDevice](SDT_Components.md#SubDevice) | SubDevice | |
| SubDevices | SubDevices | This element is an array of *SubDevice* structures. |
#### Example #### Example
...@@ -132,33 +134,36 @@ The following example defines a simple *Light* device. ...@@ -132,33 +134,36 @@ The following example defines a simple *Light* device.
} }
``` ```
<a name="attributes"/></a> <a id="attributes"/></a>
### Attributes mapping ### 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. 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*). XML attributes are represented as normal fields in JSON. The mapping of those attributes to JSON follows the rules as below.
| SDT XML Attributes | JSON Key Word | | SDT XML Attributes | JSON Key Word |
|----------------|-------------| |:-------------------|:--------------|
|@default | default | | @default | default |
|@domain |domain | | @domain | domain |
|@entity |entity | | @entity | entity |
|@eventable | eventable| | @eventable | eventable |
|@href | href | | @href | href |
|@id |id | | @id | id |
|@name |name | | @maxOccurs | maxOccurs |
|@optional | optional| | @minOccurs | minOccurs |
|@parse | parse | | @name | name |
|@readable | readable| | @optional | optional |
|@semanticURI | semanticURI | | @parse | parse |
|@value |value | | @readable | readable |
|@writable | writable| | @semanticURI | semanticURI |
|@type | type | | @type | type |
|@unitOfMeasure | unitOfMeasure | | @unitOfMeasure | unitOfMeasure |
| @value | value |
| @writable | writable |
<a name="imports"/></a>
<a id="imports"/></a>
### Import mapping ### Import mapping
The imports are mapped to an array of *Include* structures. Each *Include* structure contains a *href* and a *parse* element. The imports are mapped to an array of *Include* structures. Each *Include* structure contains a *href* and a *parse* element.
A parser must make sure to import and regard the definitions in the referenced files.
#### Example #### Example
...@@ -178,46 +183,47 @@ The imports are mapped to an array of *Include* structures. Each *Include* struc ...@@ -178,46 +183,47 @@ The imports are mapped to an array of *Include* structures. Each *Include* struc
{ "Include" : { "href" : "anotherSDT.xml", "parse" : "json" } } { "Include" : { "href" : "anotherSDT.xml", "parse" : "json" } }
] ]
``` ```
<a name="ExtendType"/></a>
<a id="ExtendType"/></a>
### ExtendType mapping ### 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*. 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_Components.md#ExtendType).
| SDT ExtendType | JSON Key Word | | SDT ExtendType | JSON Key Word |
|----------------|---------------| |:---------------|:--------------|
|action | action | | action | action |
|datapoint | datapoint | | datapoint | datapoint |
|event | event | | event | event |
|moduleclass | moduleclass | | moduleclass | moduleclass |
|property | property | | property | property |
|device | device | | device | device |
|subdevice |subdevice | | subdevice | subdevice |
<a name="dataTypes"/></a> <a id="dataTypes"/></a>
### Data Type mapping ### Data Type mapping
Data types are defined in [SDT_Components.md](SDT_Components.md). 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. 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> <a id="SimpleType"/></a>
### SimpleType ### 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"``` Note for [SimpelType](SDT_Components.md#SimpelType): For simplicity, if there is no other attribute present then the type value of [SimpelType](SDT_Components.md#SimpelType) can be directly put as the value of parent [DataType](SDT_Components.md#DataType) key, e.g. ```"DataType":"string"```
| SDT Data Types | Note | | SDT Data Types | Note |
|----------------|-----------| |:---------------|:----------------------------------------------------------------------------------------------------|
| boolean | boolean (JSON Schema) | | boolean | boolean (JSON Schema) |
| string | string (JSON Schema) | | string | string (JSON Schema) |
| byte | An integer datatype with the range of [0 - 255] | | byte | An integer datatype with the range of [0 - 255] |
| integer | integer (JSON Schema) | | integer | integer (JSON Schema) |
| float | number (JSON Schema) | | float | number (JSON Schema) |
| date | date (JSON Schema) | | date | date (JSON Schema) |
| time | time (JSON Schema) | | time | time (JSON Schema) |
| datetime | date-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) | | 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) | | uri | A string following the URI format (JSON Schema) |
| void | null (JSON Schema) | | void | null (JSON Schema) |
#### Examples #### Examples
...@@ -257,10 +263,10 @@ A simple data type with additional attributes: ...@@ -257,10 +263,10 @@ A simple data type with additional attributes:
} }
``` ```
<a name="ArrayType"/></a> <a id="ArrayType"/></a>
### ArrayType ### 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*. An [ArrayType](SDT_Components.md#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](#SimpleType), [ArrayType](#ArrayType), [StructType](#StructType), or [EnumType](#EnumType).
#### Example #### Example
...@@ -286,10 +292,10 @@ A simple data type with additional attributes: ...@@ -286,10 +292,10 @@ A simple data type with additional attributes:
} }
``` ```
<a name="StructType"/></a> <a id="StructType"/></a>
### StructType ### 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](SDT_Components.md#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](#SimpleType), [ArrayType](#ArrayType), [StructType](#StructType), or [EnumType](#EnumType).
A *StructType* definition must contain a *name* attribute. A *StructType* definition must contain a *name* attribute.
...@@ -368,16 +374,16 @@ A more complex structured data type (a structure that contains an indentifier va ...@@ -368,16 +374,16 @@ A more complex structured data type (a structure that contains an indentifier va
] ]
``` ```
<a name="EnumType"/></a> <a id="EnumType"/></a>
### EnumType ### 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](SDT_Components.md#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. A *EnumType* definition must contain a *name* attribute.
#### Example #### Example
An *Enum* that defines three *EnumValues*. The first definition explicitly specifies the type of the *EnumValue*. An *Enum* that defines three [EnumValues](SDT_Components.md#EnumValues). The first definition explicitly specifies the type of the [EnumValues](SDT_Components.md#EnumValues).
**XML**: **XML**:
...@@ -401,15 +407,14 @@ An *Enum* that defines three *EnumValues*. The first definition explicitly speci ...@@ -401,15 +407,14 @@ An *Enum* that defines three *EnumValues*. The first definition explicitly speci
] ]
``` ```
<a name="extendingDatatypes"/></a> <a id="extendingDatatypes"/></a>
### Extending Data Types ### 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*. Extending [DataTypes](SDT_Components.md#DataTypes) are mapped the same way as extending, for example, [ModuleClasses](SDT_Components.md#ModuleClass). However, since the [DataType](SDT_Components.md#DataTypes) is open, the generic form [DataType](SDT_Components.md#DataTypes) must be used for JSON serialization. It maps to a structure that contains a single [Extend](SDT_Components.md#Extending) structure. This structure contains the two attributes *domain* and *entity*.
#### Example #### Example
An [Enum](SDT_Components.md#EnumType) that defines three *EnumValues*. The first definition explicitly specifies the type of the *EnumValue*.
An *Enum* that defines three *EnumValues*. The first definition explicitly specifies the type of the *EnumValue*.
**XML**: **XML**:
......
SDT/schema4.0/docs/SDT_UML.uxf
+ 139
− 139
View file @ 600de362
...@@ -5,8 +5,8 @@ ...@@ -5,8 +5,8 @@
<element> <element>
<id>UMLNote</id> <id>UMLNote</id>
<coordinates> <coordinates>
<x>1152</x> <x>1136</x>
<y>1424</y> <y>1400</y>
<w>232</w> <w>232</w>
<h>208</h> <h>208</h>
</coordinates> </coordinates>
...@@ -36,8 +36,8 @@ group=1</panel_attributes> ...@@ -36,8 +36,8 @@ group=1</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1256</x> <x>1240</x>
<y>1504</y> <y>1480</y>
<w>88</w> <w>88</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -51,8 +51,8 @@ group=1</panel_attributes> ...@@ -51,8 +51,8 @@ group=1</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1256</x> <x>1240</x>
<y>1536</y> <y>1512</y>
<w>88</w> <w>88</w>
<h>24</h> <h>24</h>
</coordinates> </coordinates>
...@@ -64,8 +64,8 @@ group=1</panel_attributes> ...@@ -64,8 +64,8 @@ group=1</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>1264</x> <x>1248</x>
<y>1056</y> <y>1032</y>
<w>120</w> <w>120</w>
<h>176</h> <h>176</h>
</coordinates> </coordinates>
...@@ -88,8 +88,8 @@ void</panel_attributes> ...@@ -88,8 +88,8 @@ void</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>768</x> <x>752</x>
<y>1120</y> <y>1096</y>
<w>112</w> <w>112</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -101,8 +101,8 @@ fontsize=12</panel_attributes> ...@@ -101,8 +101,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>768</x> <x>752</x>
<y>1056</y> <y>1032</y>
<w>112</w> <w>112</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -114,8 +114,8 @@ fontsize=12</panel_attributes> ...@@ -114,8 +114,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>384</x> <x>368</x>
<y>1056</y> <y>1032</y>
<w>152</w> <w>152</w>
<h>120</h> <h>120</h>
</coordinates> </coordinates>
...@@ -134,8 +134,8 @@ fg=blue</panel_attributes> ...@@ -134,8 +134,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>528</x> <x>512</x>
<y>1016</y> <y>992</y>
<w>544</w> <w>544</w>
<h>96</h> <h>96</h>
</coordinates> </coordinates>
...@@ -147,8 +147,8 @@ fontsize=12</panel_attributes> ...@@ -147,8 +147,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>528</x> <x>512</x>
<y>1016</y> <y>992</y>
<w>544</w> <w>544</w>
<h>144</h> <h>144</h>
</coordinates> </coordinates>
...@@ -160,8 +160,8 @@ fontsize=12</panel_attributes> ...@@ -160,8 +160,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>864</x> <x>848</x>
<y>1152</y> <y>1128</y>
<w>152</w> <w>152</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -174,8 +174,8 @@ fg=blue</panel_attributes> ...@@ -174,8 +174,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1008</x> <x>992</x>
<y>1176</y> <y>1152</y>
<w>272</w> <w>272</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -187,8 +187,8 @@ fontsize=12</panel_attributes> ...@@ -187,8 +187,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>864</x> <x>848</x>
<y>1248</y> <y>1224</y>
<w>152</w> <w>152</w>
<h>88</h> <h>88</h>
</coordinates> </coordinates>
...@@ -205,8 +205,8 @@ fg=blue</panel_attributes> ...@@ -205,8 +205,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>528</x> <x>512</x>
<y>1136</y> <y>1112</y>
<w>352</w> <w>352</w>
<h>144</h> <h>144</h>
</coordinates> </coordinates>
...@@ -218,8 +218,8 @@ fontsize=12</panel_attributes> ...@@ -218,8 +218,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1008</x> <x>992</x>
<y>1224</y> <y>1200</y>
<w>336</w> <w>336</w>
<h>112</h> <h>112</h>
</coordinates> </coordinates>
...@@ -231,8 +231,8 @@ fontsize=12</panel_attributes> ...@@ -231,8 +231,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>864</x> <x>848</x>
<y>1056</y> <y>1032</y>
<w>152</w> <w>152</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -245,8 +245,8 @@ fg=blue</panel_attributes> ...@@ -245,8 +245,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>864</x> <x>848</x>
<y>1104</y> <y>1080</y>
<w>152</w> <w>152</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -259,8 +259,8 @@ fg=blue</panel_attributes> ...@@ -259,8 +259,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>768</x> <x>752</x>
<y>1096</y> <y>1072</y>
<w>112</w> <w>112</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -273,8 +273,8 @@ fontsize=12 ...@@ -273,8 +273,8 @@ fontsize=12
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>384</x> <x>368</x>
<y>944</y> <y>920</y>
<w>1000</w> <w>1000</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -288,8 +288,8 @@ lw=0.1</panel_attributes> ...@@ -288,8 +288,8 @@ lw=0.1</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>96</x> <x>80</x>
<y>72</y> <y>48</y>
<w>1288</w> <w>1288</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -303,8 +303,8 @@ lw=0.1</panel_attributes> ...@@ -303,8 +303,8 @@ lw=0.1</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>664</x> <x>648</x>
<y>176</y> <y>152</y>
<w>192</w> <w>192</w>
<h>168</h> <h>168</h>
</coordinates> </coordinates>
...@@ -328,8 +328,8 @@ fg=blue ...@@ -328,8 +328,8 @@ fg=blue
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>944</x> <x>928</x>
<y>176</y> <y>152</y>
<w>176</w> <w>176</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -347,8 +347,8 @@ fg=blue</panel_attributes> ...@@ -347,8 +347,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>1216</x> <x>1200</x>
<y>248</y> <y>224</y>
<w>168</w> <w>168</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -366,8 +366,8 @@ fg=blue</panel_attributes> ...@@ -366,8 +366,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1112</x> <x>1096</x>
<y>248</y> <y>224</y>
<w>120</w> <w>120</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -379,8 +379,8 @@ fontsize=12</panel_attributes> ...@@ -379,8 +379,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>112</x> <x>96</x>
<y>176</y> <y>152</y>
<w>184</w> <w>184</w>
<h>128</h> <h>128</h>
</coordinates> </coordinates>
...@@ -400,8 +400,8 @@ fg=blue</panel_attributes> ...@@ -400,8 +400,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>176</y> <y>152</y>
<w>136</w> <w>136</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -413,8 +413,8 @@ fontsize=12</panel_attributes> ...@@ -413,8 +413,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>376</x> <x>360</x>
<y>424</y> <y>400</y>
<w>176</w> <w>176</w>
<h>120</h> <h>120</h>
</coordinates> </coordinates>
...@@ -433,8 +433,8 @@ fg=blue</panel_attributes> ...@@ -433,8 +433,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>272</y> <y>248</y>
<w>56</w> <w>56</w>
<h>72</h> <h>72</h>
</coordinates> </coordinates>
...@@ -446,8 +446,8 @@ fontsize=12</panel_attributes> ...@@ -446,8 +446,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>352</y> <y>328</y>
<w>136</w> <w>136</w>
<h>128</h> <h>128</h>
</coordinates> </coordinates>
...@@ -459,8 +459,8 @@ fontsize=12</panel_attributes> ...@@ -459,8 +459,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>1216</x> <x>1200</x>
<y>472</y> <y>448</y>
<w>168</w> <w>168</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -472,8 +472,8 @@ fg=blue</panel_attributes> ...@@ -472,8 +472,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>848</x> <x>832</x>
<y>176</y> <y>152</y>
<w>112</w> <w>112</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -485,8 +485,8 @@ fontsize=12</panel_attributes> ...@@ -485,8 +485,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1168</x> <x>1152</x>
<y>472</y> <y>448</y>
<w>64</w> <w>64</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -498,8 +498,8 @@ fontsize=12</panel_attributes> ...@@ -498,8 +498,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>848</x> <x>832</x>
<y>224</y> <y>200</y>
<w>112</w> <w>112</w>
<h>96</h> <h>96</h>
</coordinates> </coordinates>
...@@ -511,8 +511,8 @@ fontsize=12</panel_attributes> ...@@ -511,8 +511,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>944</x> <x>928</x>
<y>288</y> <y>264</y>
<w>176</w> <w>176</w>
<h>144</h> <h>144</h>
</coordinates> </coordinates>
...@@ -535,8 +535,8 @@ fg=blue ...@@ -535,8 +535,8 @@ fg=blue
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>944</x> <x>928</x>
<y>440</y> <y>416</y>
<w>176</w> <w>176</w>
<h>88</h> <h>88</h>
</coordinates> </coordinates>
...@@ -553,8 +553,8 @@ fg=blue</panel_attributes> ...@@ -553,8 +553,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>848</x> <x>832</x>
<y>304</y> <y>280</y>
<w>112</w> <w>112</w>
<h>168</h> <h>168</h>
</coordinates> </coordinates>
...@@ -566,8 +566,8 @@ fontsize=12</panel_attributes> ...@@ -566,8 +566,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>176</y> <y>152</y>
<w>136</w> <w>136</w>
<h>336</h> <h>336</h>
</coordinates> </coordinates>
...@@ -579,8 +579,8 @@ fontsize=12</panel_attributes> ...@@ -579,8 +579,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>376</x> <x>360</x>
<y>312</y> <y>288</y>
<w>176</w> <w>176</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -598,8 +598,8 @@ fg=blue</panel_attributes> ...@@ -598,8 +598,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>392</y> <y>368</y>
<w>64</w> <w>64</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -611,8 +611,8 @@ fontsize=12</panel_attributes> ...@@ -611,8 +611,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>176</y> <y>152</y>
<w>136</w> <w>136</w>
<h>224</h> <h>224</h>
</coordinates> </coordinates>
...@@ -623,8 +623,8 @@ fontsize=12</panel_attributes> ...@@ -623,8 +623,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>352</y> <y>328</y>
<w>136</w> <w>136</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -634,8 +634,8 @@ fontsize=12</panel_attributes> ...@@ -634,8 +634,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>664</x> <x>648</x>
<y>352</y> <y>328</y>
<w>192</w> <w>192</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -654,21 +654,21 @@ transparency=80</panel_attributes> ...@@ -654,21 +654,21 @@ transparency=80</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1112</x> <x>1096</x>
<y>176</y> <y>256</y>
<w>56</w> <w>56</w>
<h>320</h> <h>216</h>
</coordinates> </coordinates>
<panel_attributes>lt=&lt;. <panel_attributes>lt=&lt;.
m1=0..n r1=0..n
fontsize=12</panel_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> <additional_attributes>10.0;20.0;40.0;20.0;40.0;250.0;10.0;250.0</additional_attributes>
</element> </element>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>848</x> <x>832</x>
<y>304</y> <y>280</y>
<w>56</w> <w>56</w>
<h>80</h> <h>80</h>
</coordinates> </coordinates>
...@@ -680,8 +680,8 @@ fontsize=12</panel_attributes> ...@@ -680,8 +680,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>624</x> <x>608</x>
<y>1064</y> <y>1040</y>
<w>152</w> <w>152</w>
<h>88</h> <h>88</h>
</coordinates> </coordinates>
...@@ -699,8 +699,8 @@ Enum : EnumType ...@@ -699,8 +699,8 @@ Enum : EnumType
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>528</x> <x>512</x>
<y>1072</y> <y>1048</y>
<w>112</w> <w>112</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -712,8 +712,8 @@ fontsize=12</panel_attributes> ...@@ -712,8 +712,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>240</y> <y>216</y>
<w>136</w> <w>136</w>
<h>136</h> <h>136</h>
</coordinates> </coordinates>
...@@ -724,8 +724,8 @@ fontsize=12</panel_attributes> ...@@ -724,8 +724,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>288</x> <x>272</x>
<y>144</y> <y>120</y>
<w>392</w> <w>392</w>
<h>88</h> <h>88</h>
</coordinates> </coordinates>
...@@ -736,8 +736,8 @@ fontsize=12</panel_attributes> ...@@ -736,8 +736,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>544</x> <x>528</x>
<y>256</y> <y>232</y>
<w>64</w> <w>64</w>
<h>192</h> <h>192</h>
</coordinates> </coordinates>
...@@ -749,8 +749,8 @@ fontsize=12</panel_attributes> ...@@ -749,8 +749,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>864</x> <x>848</x>
<y>1200</y> <y>1176</y>
<w>152</w> <w>152</w>
<h>40</h> <h>40</h>
</coordinates> </coordinates>
...@@ -763,8 +763,8 @@ fg=blue</panel_attributes> ...@@ -763,8 +763,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>768</x> <x>752</x>
<y>1128</y> <y>1104</y>
<w>112</w> <w>112</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -776,8 +776,8 @@ fontsize=12</panel_attributes> ...@@ -776,8 +776,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>1064</x> <x>1048</x>
<y>1216</y> <y>1192</y>
<w>168</w> <w>168</w>
<h>88</h> <h>88</h>
</coordinates> </coordinates>
...@@ -794,8 +794,8 @@ fg=blue</panel_attributes> ...@@ -794,8 +794,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1008</x> <x>992</x>
<y>1216</y> <y>1192</y>
<w>72</w> <w>72</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -807,8 +807,8 @@ fontsize=12</panel_attributes> ...@@ -807,8 +807,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1224</x> <x>1208</x>
<y>1224</y> <y>1200</y>
<w>88</w> <w>88</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -820,8 +820,8 @@ fontsize=12</panel_attributes> ...@@ -820,8 +820,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>432</x> <x>416</x>
<y>696</y> <y>672</y>
<w>176</w> <w>176</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -837,8 +837,8 @@ fg=blue ...@@ -837,8 +837,8 @@ fg=blue
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>928</x> <x>912</x>
<y>696</y> <y>672</y>
<w>192</w> <w>192</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -852,8 +852,8 @@ fg=blue</panel_attributes> ...@@ -852,8 +852,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>856</x> <x>840</x>
<y>696</y> <y>672</y>
<w>88</w> <w>88</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -866,8 +866,8 @@ fontsize=12 ...@@ -866,8 +866,8 @@ fontsize=12
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>384</x> <x>368</x>
<y>696</y> <y>672</y>
<w>64</w> <w>64</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
...@@ -879,8 +879,8 @@ fontsize=12</panel_attributes> ...@@ -879,8 +879,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>1208</x> <x>1192</x>
<y>696</y> <y>672</y>
<w>176</w> <w>176</w>
<h>128</h> <h>128</h>
</coordinates> </coordinates>
...@@ -900,8 +900,8 @@ subdevice ...@@ -900,8 +900,8 @@ subdevice
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1112</x> <x>1096</x>
<y>696</y> <y>672</y>
<w>112</w> <w>112</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -913,8 +913,8 @@ fontsize=12</panel_attributes> ...@@ -913,8 +913,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>928</x> <x>912</x>
<y>760</y> <y>736</y>
<w>192</w> <w>192</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -928,8 +928,8 @@ fg=blue</panel_attributes> ...@@ -928,8 +928,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>856</x> <x>840</x>
<y>744</y> <y>720</y>
<w>88</w> <w>88</w>
<h>48</h> <h>48</h>
</coordinates> </coordinates>
...@@ -942,8 +942,8 @@ fontsize=12 ...@@ -942,8 +942,8 @@ fontsize=12
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>1112</x> <x>1096</x>
<y>696</y> <y>672</y>
<w>112</w> <w>112</w>
<h>120</h> <h>120</h>
</coordinates> </coordinates>
...@@ -955,8 +955,8 @@ fontsize=12</panel_attributes> ...@@ -955,8 +955,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>688</x> <x>672</x>
<y>696</y> <y>672</y>
<w>176</w> <w>176</w>
<h>64</h> <h>64</h>
</coordinates> </coordinates>
...@@ -973,8 +973,8 @@ Includes : Include ...@@ -973,8 +973,8 @@ Includes : Include
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>600</x> <x>584</x>
<y>704</y> <y>680</y>
<w>104</w> <w>104</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -987,8 +987,8 @@ fontsize=12 ...@@ -987,8 +987,8 @@ fontsize=12
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>376</x> <x>360</x>
<y>176</y> <y>152</y>
<w>176</w> <w>176</w>
<h>128</h> <h>128</h>
</coordinates> </coordinates>
...@@ -1009,8 +1009,8 @@ fg=blue</panel_attributes> ...@@ -1009,8 +1009,8 @@ fg=blue</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>288</x> <x>272</x>
<y>288</y> <y>264</y>
<w>104</w> <w>104</w>
<h>56</h> <h>56</h>
</coordinates> </coordinates>
...@@ -1022,8 +1022,8 @@ fontsize=12</panel_attributes> ...@@ -1022,8 +1022,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>Relation</id> <id>Relation</id>
<coordinates> <coordinates>
<x>288</x> <x>272</x>
<y>176</y> <y>152</y>
<w>104</w> <w>104</w>
<h>104</h> <h>104</h>
</coordinates> </coordinates>
...@@ -1035,8 +1035,8 @@ fontsize=12</panel_attributes> ...@@ -1035,8 +1035,8 @@ fontsize=12</panel_attributes>
<element> <element>
<id>UMLClass</id> <id>UMLClass</id>
<coordinates> <coordinates>
<x>384</x> <x>368</x>
<y>608</y> <y>584</y>
<w>1000</w> <w>1000</w>
<h>32</h> <h>32</h>
</coordinates> </coordinates>
......
SDT/schema4.0/docs/UML Diagram.md
+ 6
− 0
View file @ 600de362
...@@ -8,12 +8,18 @@ The source for the diagrams below can be found [here (SDT_UML.uxf)](SDT_UML.uxf) ...@@ -8,12 +8,18 @@ The source for the diagrams below can be found [here (SDT_UML.uxf)](SDT_UML.uxf)
## Basic Elements ## Basic Elements
This diagram presents the main functional elements of the Smart Device Template.
![](images/SDT_UML_Basic_Elements.png) ![](images/SDT_UML_Basic_Elements.png)
## Data Types ## Data Types
This diagram shows how data types are specified in the Smart Device Temple.
![](images/SDT_UML_DataType.png) ![](images/SDT_UML_DataType.png)
## Extend ## Extend
Some elements of the Smart Device Template can be extended. This diagram presents the elements that are used to extend elements as well as to include and exclude certain attributs and sub-elements when extending.
![](images/SDT_UML_Extend.png) ![](images/SDT_UML_Extend.png)
SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
+ 0
− 0
View replaced file @ 14cdf759 View file @ 600de362
SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png

12.4 KiB | W: | H:

SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png

14.3 KiB | W: | H:

SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
SDT/schema4.0/docs/images/MC.Action.DataPoint.Event.png
  • 2-up
  • Swipe
  • Onion skin
SDT/schema4.0/docs/images/ModuleClass.png
+ 0
− 0
View replaced file @ 14cdf759 View file @ 600de362
SDT/schema4.0/docs/images/ModuleClass.png

8.19 KiB | W: | H:

SDT/schema4.0/docs/images/ModuleClass.png

9.38 KiB | W: | H:

SDT/schema4.0/docs/images/ModuleClass.png
SDT/schema4.0/docs/images/ModuleClass.png
SDT/schema4.0/docs/images/ModuleClass.png
SDT/schema4.0/docs/images/ModuleClass.png
  • 2-up
  • Swipe
  • Onion skin
SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
+ 0
− 0
View replaced file @ 14cdf759 View file @ 600de362
SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png

92.6 KiB | W: | H:

SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png

92.7 KiB | W: | H:

SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
  • 2-up
  • Swipe
  • Onion skin
SDT/schema4.0/docs/images/SDT_simplified.png
+ 0
− 0
View replaced file @ 14cdf759 View file @ 600de362
SDT/schema4.0/docs/images/SDT_simplified.png

79 KiB | W: | H:

SDT/schema4.0/docs/images/SDT_simplified.png

88 KiB | W: | H:

SDT/schema4.0/docs/images/SDT_simplified.png
SDT/schema4.0/docs/images/SDT_simplified.png
SDT/schema4.0/docs/images/SDT_simplified.png
SDT/schema4.0/docs/images/SDT_simplified.png
  • 2-up
  • Swipe
  • Onion skin
SDT/schema4.0/docs/images/SubDevice.png
+ 0
− 0
View replaced file @ 14cdf759 View file @ 600de362
SDT/schema4.0/docs/images/SubDevice.png

5.98 KiB | W: | H:

SDT/schema4.0/docs/images/SubDevice.png

7.2 KiB | W: | H:

SDT/schema4.0/docs/images/SubDevice.png
SDT/schema4.0/docs/images/SubDevice.png
SDT/schema4.0/docs/images/SubDevice.png
SDT/schema4.0/docs/images/SubDevice.png
  • 2-up
  • Swipe
  • Onion skin
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment