diff --git a/SDT/schema4.0/docs/SDT_Components.md b/SDT/schema4.0/docs/SDT_Components.md
index 2619a9124a735b2f2c2d90c1f38f5a76e5f49eaf..d93bc792e52b9d9f07aaea83e36d6a120d20ff0c 100644
--- a/SDT/schema4.0/docs/SDT_Components.md
+++ b/SDT/schema4.0/docs/SDT_Components.md
@@ -1,499 +1,494 @@
# SDT Components
-[Domain](#Domain)
-[Device](#Device) | [SubDevice](#SubDevice)
-[Product](#Product)
-[Property](#Property)
-[ModuleClass](#ModuleClass)
- [Action](#Action)
- [Arg](#Arg)
- [DataPoint](#DataPoint)
- [Event](#Event)
-[Data Types](#Data_Types)
- [DataType](#DataType)
- [Constraint](#Constraint)
- [SimpleType](#SimpleType)
- [StructType](#StructType)
- [ArrayType](#ArrayType)
-[Doc](#Documentation)
+1. [Basic Components](#BasicComponents)
+ 1. [Domain](#Domain)
+ 2. [ModuleClass](#ModuleClass)
+ 1. [DataPoint](#DataPoint)
+ 2. [Action](#Action)
+ 1. [Arg](#Arg)
+ 3. [Event](#Event)
+ 4. [DeviceClass](#DeviceClass)
+ 1. [SubDevice](#SubDevice)
+ 5. [Product](#Product)
+ 6. [Property](#Property)
+2. [Data Types](#DataTypes)
+ 1. [DataType](#DataType)
+ 1. [Constraint](#Constraint)
+ 2. [TypeChoice](#TypeChoice)
+ 2. [SimpleType](#SimpleType)
+ 3. [StructType](#StructType)
+ 4. [ArrayType](#ArrayType)
+ 5. [EnumType](#EnumType)
+ 1. ExtendExclude
+3. [Extending (Inheriting)](#Extending)
+ 1. [Extend](#Extend)
+ 1. [Include](#ExtendInclude)
+ 2. [Exclude](#ExtendExclude)
+ 3. [ExtendType](#ExtendType)
+4. [Documentation (Doc)](#Documentation)
---
-**Editor's Note**: TS-0023 needs to be updated to remove "Module", and change the column name of "Module Instance Name" of all device models to "ModuleClass Specialization Name".
## SDT Overview
-The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of the details of a SDT, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software to be adapted accordingly.
+The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of SDT details, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software to be adapted accordingly.
-
+The key to the diagram elements of the UML diagrams and the snippets in the following sections follow this figure:
-The key to the diagram elements of the UML diagrams above and the snippets in the following sections:
-<a name="Domain"></a>
+The syntax used in the diagrams to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
-The syntax used in the diagram to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
- [Design XML schemas using UML](http://www.ibm.com/developerworks/library/x-umlschem/)
- [UML For W3C XML Schema Design](http://www.xml.com/pub/a/2002/08/07/wxs_uml.html)
+
+<a name="BasicComponents"></a>
+## Basic Elements
+
+
+
+<a name="Domain"></a>
### Domain
The *Domain* element allows labeling of different SDT templates for different technologies and/or industry segments ("verticals"): for example eHealth and Building Management might prefer quite different detailed structures/templates. This also helps keep information in human-friendly and manageable blocks. It is assumed that there will be multiple "SDT Templates" and some of them may be completely proprietary.
-It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
- and [Devices](#Devices) in one referencable logical group.
+It can also be used to collect all specified [ModuleClasses](#ModuleClasses), [DeviceClasses](#DeviceClasss), [DataTypes](#DataTypes) and [ProductClasses](#ProductClasses) in one referencable logical group.
#### Attributes
- **id** : The identifier for that *Domain*. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
- **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
-- **Imports** : XML import/include of other XML files. Optional.
+- **Imports** : XML import/include of other XML files / SDT templates. Optional.
+Note, that when using **Imports** one must include the following namespace in the Domain-Element definition, as shown in the example below: ```xmlns:xi="http://www.w3.org/2001/XInclude"```
+- **[DataTypes](#DataType)** : A list of *DataTypes* that are global to the whole domain. They can be referenced from other definitions by the [Extend](#Extend) element. Optional.
- **[ModuleClasses](#ModuleClass)** : A list of those *ModuleClass* components that are global to the whole domain. Optional.
-- **[Devices](#Device)** : a List of *Devices* components. Optional.
+- **[DeviceClasses](#DeviceClass)** : a List of *DeviceClass* components. Optional.
+- **[ProductClasses](#ProductClass)** : a List of *ProductClass* components. Optional.
#### Example
-
- <Domain xmlns:xi="http://www.w3.org/2001/XInclude"
- xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
- id="org.homegatewayinitiative">
- <Doc>Some documentation</Doc>
- <Imports>
- <!-- Import other SDTs via XInclude's include mechanism -->
- <xi:include href="./dal-core.xml" parse="xml" />
- </Imports>
- <ModuleClasses>
- <!-- List of Domain global ModuleClasses goes here -->
- </ModuleClasses>
- <Devices>
- <!-- List of Devices goes here -->
- </Devices>
- </Domain>
+```xml
+<Domain xmlns:xi="http://www.w3.org/2001/XInclude"
+ xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
+ id="org.homegatewayinitiative">
+ <Doc>Some documentation</Doc>
+ <Imports>
+ <!-- Import other SDTs via XInclude's include mechanism -->
+ <xi:include href="anotherSDT.xml" parse="xml" />
+ </Imports>
+ <ModuleClasses>
+ <!-- List of Domain global ModuleClasses goes here -->
+ </ModuleClasses>
+ <DeviceClasses>
+ <!-- List of Devices goes here -->
+ </DeviceClasses>
+</Domain>
+```
---
-<a name="Device"/></a>
+<a name="ModuleClass"/></a>
+### ModuleClass
+Element of [Domain](#Domain) and [Product](#Product).
-### Device
+
-
+*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can extend another *ModuleClass* with additional functionalities.
-The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass).
+Every [DeviceClass](#DeviceClass) can be described by a collection of *ModuleClasses* (functionality).
-For each physical device on the network at least one *Device* **must** be defined. If the physical device is a simple device, i.e. it does not contain embedded devices, e.g. a light switch, it does not include further [SubDevices](#SubDevices). On the other hand, if the physical is a compound device, i.e. it does contain embedded devices that can be addressed separately, the *Device* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices.
+The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [DeviceClass](#DeviceClass).
-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".
+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).
+
+Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "PanUP/DOWN", "Temperature", etc. Those examples make it apparent that various read/write usage of parameters, invoking of actions and waiting for events might be needed in the different *ModuleClasses*, and a guideline for those structures is explained below.
-*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClasses(#ModuleClass) of the same or another [Domain](#Domain).
#### Attributes
-- **id** : The identifier for that *Device*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **name** : Name of the *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
+- **optional**: Boolean that indicates whether a *ModuleClass* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *Device*. Optional.
-- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *Device*. Optional.
-- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
+- **[Doc](#Documentation)** : Documentation for the *ModuleClass*. Optional.
+- **[Extend](#Extend)** : Reference to a another *ModuleClass* which is extended by this *ModuleClass*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *ModuleClass*. Optional.
+- **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
+- **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
+- **[Events](#Event)** : A list of *Event* components. Optional.
#### Example
-
- <Device id="aDevice">
- <Doc>Some documentation</Doc>
- <Properties>
- <!-- The list of Properties for the Device goes here-->
- </Properties>
- <ModuleClasses>
- <!-- List of ModuleClasses local to the Device goes here-->
- </ModuleClasses>
- <SubDevices>
- <!-- List of Sub-Devices of the Device goes here-->
- </SubDevices>
- </Device>
+```xml
+<ModuleClass name="BooleanState">
+ <Doc>Some documentation</Doc>
+ <Actions>
+ <!-- List of Actions goes here-->
+ </Actions>
+ <Events>
+ <!-- List of Events goes here-->
+ </Events>
+ <Data>
+ <!-- List of DataPoints goes here-->
+ </Data>
+</ModuleClass>
+```
---
-<a name="SubDevice"/></a>
+<a name="DataPoint"/></a>
+### DataPoint
+Element of [ModuleClass](#ModuleClass) and [Event](#Event).
-### SubDevice
-*SubDevices* are optional components of a [Device](#Device). They represent physical sub-devices and services inside another device (the *Device*).
+
-*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain).
+A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *[DataType](#DataType)* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof, or an enumeration) which facillitates data integrity.
-
+Note, that all RESTful systems (e.g. CoAP) use only *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
+
+However, *DataPoints* are not the only way of controlling and monitoring devices, so further [Actions](#Action) and [Events](#Event) are described below.
+
+Though *DataPoints* only refer to single data points of a physical device it is possible to describe hierarchies by model the path to the data point in the hierarchy by a path-like structure like to the pathname of a UNIX file system. Here, the root node of the hierarchy is a slash (/ 0x2F) and the segments or nodes along the path are also separated by slashes. The actual datapoint is the last leaf at the path.
+
+In EBNF:
+
+```ebnf
+name = dataPointName | "/" path ;
+path = segment "/" path | dataPointName ;
+segment = string ;
+dataPointName = string ;
+string = (* character string excluding the character "/" *) ;
+```
#### Attributes
-- **id** : The identifier for that *SubDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether a *DataPoint* is optional or mandatory. Optional, the default is *false*.
+- **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Optional. Default: true.
+- **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Optional. Default: true.
+- **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Optional. Default: false.
+- **default** : A default value for the *DataPoint*.
+- - **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
-- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
+- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
+- **[DataType](#DataType)** : The type of the *DataPoint*. It must comply to the *DataType* definition. Required.
#### Example
-
- <SubDevice id="aSubDevice">
- <Doc>Some documentation</Doc>
- <Properties>
- <!-- The list of Properties for the Device goes here-->
- </Properties>
- <ModuleClasses>
- <!-- List of ModuleClasses local to the Device goes here-->
- </ModuleClasses>
- </SubDevice>
+```xml
+<Data>
+ <DataPoint name="attributeName" writable="false">
+ <Doc>Some documentation for the DataPoint</Doc>
+ <DataType>
+ <SimpleType type="string" />
+ </DataType
+ </DataPoint>
+</Data>
+```
---
-<a name="Product"/></a>
-### Product
-
-
+<a name="Action"/></a>
+### Action
-In real life of device manufacturing, there is an important concept of *Product* under a certain *DeviceClass*. For example, oneM2M may specify a generic *DeviceClass* called 'deviceSmartBracelt' with many fancy features (*ModuleClasses*). Based on the same *DeviceClass*, company A may design a *Product* called 'X-Fit' with only the *ModuleClass* of 'stepCounter' and the instantiated *Property* value of 'Manufacturer = Company A', while company B may design a *Product* called 'Y-Wristband' with the *ModuleClasses* of 'stepCounter' and 'heartRateMonitor' and the instantiated *Property* value of 'Manufacturer = Company B'. Those two *Products* are different but follow the same *DeviceClass*.
+Element of [ModuleClass](#ModuleClass).
-On the other hand, a *Product* is **NOT** yet a real device instance of that *DeviceClass*. It may not have an instantiated *Properties* like device-id, date-of-manufacturing, and the firmware/software-version, etc. It can be ordered by the customers, but not necessarily instantiated or manufactured.
+
-In short, a *Product* is a concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a *DeviceClass* but not yet an device instance. Examples are the shopping items in an online digital store that can be ordered (but not necessarily manufactured) by a customer.
+*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ([Args](#Arg), see next section) with the method which checks and executes them, in one step.
-A *Product* can be defined by implementing the functionalities of an existing *DeviceClass* (while removing unimplemented optional *Properties* and *ModuleClasses*), extending from an existing *DeviceClass* (adding new *Properties* and *ModuleClasses*), or from scratch (without basing on any *DeviceClass*).
+Note, that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
#### Attributes
-- **id** : The identifier for that *Product*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-All elements of *DeviceClass* can be reused in *Product*, but the *optional* attribute of those elements is not applicable (ignored if present).
+- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
+- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
+- **[Args](#Arg)** : Zero or more occurances of argument definitions for an *Action*. Optional.
-- **[Doc](#Documentation)** : Documentation for the *Product*. Optional.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *Product*. Optional.
-- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *Product*. Optional.
-- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
+<a name="ActionExample"/></a>
+#### Example
+The following are two examples for actions implementing a getter and a setter for boolean values.
+```xml
+<Action name="get" type="boolean">
+ <Doc>Obtain the current associated state. Example of a getter.</Doc>
+</Action>
+
+<Action name="setTarget">
+ <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
+ <Args>
+ <Arg name="value">
+ <Doc>The desired value of the associated state.</Doc>
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </Arg>
+ </Args>
+</Action>
+```
-- **[DeviceClass](#DeviceClass)** : Reference to a *DeviceClass* which is implemented by this *Product*. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the implemented *DeviceClass*. Optional if in the same domain.
- - **class** : Name of the *DeviceClass* in the [Domain](#Domain) that is extended. Required for this element.
-The element has the following child elements:
- - **ImplementedModuleClasses** : A list of names of the implemented optional [ModuleClasses](#ModuleClass) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [ModuleClasses](#ModuleClass) are implemented. If present, both the listed optional [ModuleClasses](#ModuleClass) and the mandatory [ModuleClass](#ModuleClass) are implemented.
- - **ImplementedProperties** : A list of name-value pairs of the implemented optional device [Properties](#Property) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [Properties](#Property) are implemented. If present, both the listed optional [Properties](#Property) and the mandatory [Properties](#Property) are implemented, and the values of those [Properties](#Property) are initiated as provided. In the case that the value of the [Properties](#Property) should not be initiated, the value can be omitted.
+---
-- **Extends** : Reference to a parent *Product* from which this *Product* is extended. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *Product*. Optional if in the same domain.
- - **class** : *id* of the *Product* in the [Domain](#Domain) that is extended. Required for this element.
+<a name="Arg"/></a>
+### Arg
+Element of [Action](#Action).
-**Note**: New extended *Properties* and *ModuleClasses* **shall** have different names from those in the implemented *DeviceClass* if they're defined in the same *Domain*.
+
+
+The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
-**Editor's Note**: the description of the optionality of the datapoints, properties, actions, events in the implemented ModuleClass is FFS.
+The *Arg* has the following attributes and elements:
-#### XML Example
-```
-<Product id="myMseebProduct">
- <DeviceClass domain="org.exampleDomain" class="MSEEB.root">
- <ImplementedPropertyies>
- <Property name="name" value="product-abc"/>
- <Property name="vendor" value="xyz"/>
- <Property name="SerialNumber"/>
- </ImplementedProperties>
- <ImplementedModuleClasses>
- <MoudleClass name="rootPowerOnOff"/>
- <MoudleClass name="power" />
- </ImplementedModuleClasses>
- </DeviceClass>
- <Properties name="someNewProperty" value="someValue">
- <Doc>...</Doc>
- <SimpleType type="string" />
- </Properties>
- <ModuleClasses name="someNewModuleClass">
- <Actions>
- <!-- List of Actions goes here-->
- </Actions>
- <Events>
- <!-- List of Events goes here-->
- </Events>
- <DataPoints>
- <!-- List of DataPoints goes here-->
- </DataPoints>
- </ModuleClasses>
-</Product>
-```
+#### Attributes
+- **name** : The name of the *Arg* attribute. Required.
+- **optional**: Boolean that indicates whether an *Arg* is optional or mandatory. Optional, the default is *false*.
+- **default** : A default value for the *Arg*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
-#### JSON Example
-```
-{
- "Product": {
- "id": "myMseebProduct",
- "DeviceClass": {
- "domain": "org.exampleDomain",
- "class": "MSEEB.root",
- "ImplementedProperties": [{
- "name": "name",
- "value": "product-abc"
- },
- {
- "name": "Vendor",
- "value": "xyz"
- },
- {
- "name": "SerialNumber"
- }],
- "ImplementedModuleClasses": ["rootPowerOnOff","power"]
- },
- "Properties": [{
- "name": "someNewProperty",
- "value": "someValue",
- "Doc": "...",
- "DataType": "..."
- }],
- "ModuleClasses": [{
- "name": "someNewModuleClass",
- "Actions": [],
- "DataPoints": [],
- "Events": []
- }]
- }
-}
-```
----
-<a name="Property"/></a>
+#### Elements
+- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
+- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
-### Property : Element of a *Device* or *ModuleClass*
+#### Example
+See [example above](#ActionExample).
-
+---
-*Property* elements are used to append to [Devices](#Device) and their [ModuleClass](ModuleClass) elements with arbitrary additional information. For [Devices](#Device) it would be very common for a manufacturer to want to add into the XML file which is describing the device such information as "Manufacturing Site", "Date of Manufacture", "Certification Code", "Energy Label Code", "compatible LAN technology", "URL for the device handbook", "physical limits of operation environments", etc.
+<a name="Event"/></a>
+### Event
+Element of [ModuleClass](#ModuleClass).
-Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specify these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
+
-Since the *Properties* are highly varied, depending on industry segment, no attempt is made in the SDT to constrain the options: however it is highly recommended to provide software-developer-friendly information in the [Doc](#Documentation) field of each Property.
+*Event* elements are needed for automation protocols which "push" information, instead of relying on polling by the software application. A typical example would be a "SensorAlert" where a window sensor immediately transmits a change of its state from "closed" to "open", which could be used in a burglar alarm application, needs to be ready to accept such information immediately, and not wait for a regular polling of the device.
#### Attributes
-- **name**: Name or identifier of a *Property*.
-- **optional**: Boolean that indicates whether a *Property* is optional or mandatory. Optional, the default is *false*.
-- **value**: Text representation of value of a *Property*. Optional.
+- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
+- **optional**: Boolean that indicates whether an *Event* is optional or mandatory. Optional, the default is *false*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Property*. Optional.
-- **DataType** : The data type of the property. This must be a [SimpleType](#SimpleType).
+- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
+- **[Data](#DataPoint)** : A list of *DataPoint* components for an event's payload. Optional.
#### Example
-
- <Property name="ManufacturedDate" value="2015.10.30 10:06">
- <SimpleType type="datetime" />
- </Property>
-
+```xml
+<Event name="stateChanged">
+ <Doc>Some documentation for the Event</Doc>
+ <Data>
+ <DataPoint name="state">
+ <DataType>
+ <SimpleType type="boolean" />
+ </DataType>
+ </DataPoint>
+ </Data>
+</Event>
+```
---
-<a name="ModuleClass"/></a>
-
-### Module and ModuleClass
+<a name="DeviceClass"/></a>
+### DeviceClass
+Element of [Domain](#Domain) and [Product](#Product).
-
+
-**ModuleClass**
+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.
-*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can be extended from another *ModuleClass* with additional functionalities.
+Note, that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass).
-Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).
+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.
-The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [Device](#Device).
-
-In principle there could be an infinite number of *ModuleClasses*, for every kind of functionality found in UPnP, ZigBee and all the other automation protocols ... However that would not simplify the job of software developers at all! Therefore, oneM2M recommends that a finite and convenient number of prototypical *ModuleClasses* are re-used as much as possible (within a Domain at least). oneM2M TS-0023 specifies a set of such standardized ModuleClasses (as well as Device models).
-
-Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "PanUP/DOWN", "ReadTemperature", etc. Those examples make it apparent that various read/write usage of parameters, invoking of actions and waiting for events might be needed in the different *ModuleClasses*, and a guideline for those structures is explained below.
+An example for a compound device is a connected power-strip where each of the sockets can be switched on and off individually. The power-strip itself can provide functions such as "all sockets off" and "overall power consumption".
+*DeviceClasses* may define their own [ModuleClasses](#ModuleClass) or refer to predefined [ModuleClasses](#ModuleClass) of the same or another [Domain](#Domain).
#### Attributes
-- **name** : Name of the *Module* or *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
-- **optional**: Boolean that indicates whether a *Module* or *ModuleClass* is optional or mandatory. Optional, the default is *false*.
+- **id** : The identifier for that *DeviceClass*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Module* or *ModuleClass*. Optional.
-- **Extends** : Reference to a another *ModuleClass* or *Module* which is extended with this *ModuleClass*. Optional.
-The element has the following attributes:
- - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *ModuleClass*. Required for this element.
- - **class** : Name of the *ModuleClass* in the [Domain](#Domain) that is extended. Required for this element.
-- **[Properties](#Property)** : Further meta-data (or properties) about the *Module* or *ModuleClass*. Optional.
-- **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
-- **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
-- **[Events](#Event)** : A list of *Event* components. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *Device*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *Device*. Optional.
+- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
#### Example
-
- <ModuleClass name="BooleanState">
- <Doc>Some documentation</Doc>
- <Actions>
- <!-- List of Actions goes here-->
- </Actions>
- <Events>
- <!-- List of Events goes here-->
- </Events
- <Data>
- <!-- List of DataPoints goes here-->
- </Data>
- </ModuleClass>
+```xml
+<Device id="aDevice">
+ <Doc>Some documentation</Doc>
+ <Properties>
+ <!-- The list of Properties for the Device goes here-->
+ </Properties>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
+ <SubDevices>
+ <!-- List of Sub-Devices of the Device goes here-->
+ </SubDevices>
+</Device>
+```
---
-<a name="DataPoint"/></a>
-
-### DataPoint : Element of *ModuleClass* and *Event*
-
-
-
-A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *type* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof) which facillitates data integrity. Note that all RESTful systems (e.g. CoAP) use only *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
-
-However, *DataPoints* are not the only way of controlling devices, so further [Actions](#Action) and [Events](#Event) are described below.
-
-Though *DataPoints* only refer to single data points of a physical device it is possible to describe hierarchies by model the path to the data point in the hierarchy by a path-like structure like to the pathname of a UNIX file system. Here, the root node of the hierarchy is a slash (/ 0x2F) and the segments or nodes along the path are also separated by slashes. The actual datapoint is the last leaf at the path.
+<a name="SubDevice"/></a>
+### SubDevice
+Element of [DeviceClass](#DeviceClass) and [Product](#Product).
-In EBNF:
+*SubDevices* are optional components of a [DeviceClass](#DeviceClass). They represent physical sub-devices and services inside another device (the *DeviceClass*).
- name = dataPointName | "/" path ;
- path = segment "/" path | dataPointName ;
- segment = string ;
- dataPointName = string ;
- string = (* character string excluding the character "/" *) ;
+*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain).
+
#### Attributes
-- **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether a *DataPoint* is optional or mandatory. Optional, the default is *false*.
-- **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Optional. Default: true.
-- **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Optional. Default: true.
-- **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Optional. Default: false.
+- **id** : The identifier for that *SubDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
-- **[DataType](#DataType)** : The type of the *DataPoint*. It must comply to the *DataType* definition. Required.
+- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
#### Example
-
- <Data>
- <DataPoint name="attributeName" writable="false">
- <Doc>Some documentation for the DataPoint</Doc>
- <DataType>
- <SimpleType type="string" />
- </DataType
- </DataPoint>
- </Data>
+```xml
+<SubDevice id="aSubDevice">
+ <Doc>Some documentation</Doc>
+ <Properties>
+ <!-- The list of Properties for the Device goes here-->
+ </Properties>
+ <ModuleClasses>
+ <!-- List of ModuleClasses local to the Device goes here-->
+ </ModuleClasses>
+</SubDevice>
+```
---
+<a name="ProductClass"/></a>
+### ProductClass
+Element of [Domain](#Domain).
-<a name="Action"/></a>
+
-### Action : Element of *ModuleClass*
+In real life of device manufacturing, there is the important concept of a *ProductClass* for a certain [DeviceClass](#DeviceClass). For example, oneM2M may specify a generic [DeviceClass](#DeviceClass) called *deviceSmartBracelt* with many fancy features (ie. a [ModuleClasses](#ModuleClass). Based on the same [DeviceClass](#DeviceClass), company A may design a *ProductClass* called "X-Fit" with only the [ModuleClass](#ModuleClass) of "stepCounter" and the instantiated [Property](#Property) value of "Manufacturer = Company A", while company B may design a *ProductClass* called "Y-Wristband" with the [ModuleClasseses](#ModuleClass) of "stepCounter" and "heartRateMonitor" and the instantiated [Property](#Property) value of "Manufacturer = Company B". Those two *ProductClasses* are different but follow the same [DeviceClass](#DeviceClass).
-
+On the other hand, a *ProductClass* is **NOT** yet a real device instance of that [DeviceClass](#DeviceClass). It may not have an instantiated [Properties](#Property) like device-id, date-of-manufacturing, and the firmware/software-version, etc. It can be ordered by the customers, but not necessarily instantiated or manufactured.
-*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ("args", see next section) with the method which checks and executes them, in one step.
+In short, a *ProductClass* is a concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a [DeviceClass](#DeviceClass) but not yet an device instance. Examples are the shopping items in an online digital store that can be ordered (but not necessarily manufactured) by a customer.
-Note that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
+A *ProductClass* can be defined by implementing the functionalities of an existing [DeviceClass](#DeviceClass) (while removing unimplemented optional *Properties* and [ModuleClasses](#ModuleClass)), extending from an existing [DeviceClass](#DeviceClass) (adding new [Properties](#Property) and [ModuleClasses](#ModuleClass)), or from scratch (without basing on any [DeviceClass](#DeviceClass)).
#### Attributes
-- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
+- **id** : The identifier for that *ProductClass*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by the manufacturer or implementation domain. Required.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
-- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
-- **Args** : Zero or more occurances of [argument](#Arg) definitions for an *Action*. Optional.
+All elements of [DeviceClass](#DeviceClass) can be reused in *ProductClass*, but the *optional* attribute of those elements is not applicable (ignored if present).
-<a name="ActionExample"/></a>
+- **[Doc](#Documentation)** : Documentation for the *ProductClass*. Optional.
+- **[Properties](#Property)** : Further meta-data (or properties) about the *ProductClass*. Optional.
+- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *ProductClass*. Optional.
+- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
+- **[DeviceClass](#DeviceClass)** : Reference to a *DeviceClass* which is implemented by this *ProductClass*. Optional.
+- **Extends** : Reference to a parent *ProductClass* from which this *ProductClass* is extended. Optional.
+**Note**: New extended *Properties* and *ModuleClasses* **shall** have different names from those in the implemented *DeviceClass* if they're defined in the same *Domain*. Also, when extending a *ProductClass* that has a [DeviceClass](#DeviceClass) defined (or in any other parent in the inheritance hierarchy) then the child *ProductClass* **must not** define another [DeviceClass](#DeviceClass).
#### Example
-The following are two examples for actions implementing a getter and a setter for boolean values.
-
- <Action name="get" type="boolean">
- <Doc>Obtain the current associated state. Example of a getter.</Doc>
- </Action>
-
- <Action name="setTarget">
- <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
- <Args>
- <Arg name="value">
- <Doc>The desired value of the associated state.</Doc>
- <DataType>
- <SimpleType type="boolean" />
- </DataType>
- </Arg>
- </Args>
- </Action>
+```xml
+<ProductClass id="TestProductClass">
+ <Doc>This is a new product</Doc>
+ <Properties>
+ <Property name="name" value="product-abc">
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ <Property name="vendor" value="xyz"/>
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ <Property name="SerialNumber"/>
+ <SimpleType type="string"></SimpleType>
+ </Property>
+ </Properties>
+ <ModuleClasses>
+ <ModuleClass name="aModuleClass">
+ <Extend domain="adomain" entity="aModuleClass" />
+ </ModuleClass>
+ <ModuleClass name="newModuleClass">
+ <!-- List of Actions, Events and DataPoints goes here-->
+ </ModuleClass>
+ </ModuleClasses>
+ <DeviceClass>
+ <Extend domain="adomain" entity="aDeviceClass" />
+ </DeviceClass>
+</ProductClass>
+```
---
-<a name="Event"/></a>
+<a name="Property"/></a>
+### Property
+Element of a [ProductClass](#ProductClass), [DeviceClass](#DeviceClass), [SubDevice](#SubDevice), and [ModuleClass](#ModuleClass).
-### Event : Element of *ModuleClass*
+
-
+*Property* elements are used to append to [ProductClasses](#ProductClass) [DevicesClasses](#DeviceClass) and their [ModuleClass](ModuleClass) elements with arbitrary additional information. For example, for a [ProductClass](#DeviceClass) it would be very common for a manufacturer to want to add into the XML file which is describing the manufacturer appliance such information as "Manufacturing Site", "Date of Manufacture", "Certification Code", "Energy Label Code", "compatible LAN technology", "URL for the device handbook", "physical limits of operation environments", etc.
-*Event* elements are needed for automation protocols which "push" information, instead of relying on polling by the software application. A typical example would be a "SensorAlert" where a window sensor immediately transmits a change of its state from "closed" to "open", which could be used in a burglar alarm application, needs to be ready to accept such information immediately, and not wait for a regular polling of the device.
+Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specify these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
+
+Since the *Properties* are highly varied, depending on industry segment, no attempt is made in the SDT to constrain the options: however it is highly recommended to provide software-developer-friendly information in the [Doc](#Documentation) field of each Property.
#### Attributes
-- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
-- **optional**: Boolean that indicates whether an *Event* is optional or mandatory. Optional, the default is *false*.
+- **name**: Name or identifier of a *Property*.
+- **optional**: Boolean that indicates whether a *Property* is optional or mandatory. Optional, the default is *false*.
+- **value**: Text representation of value of a *Property*. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
-- **[Data](#DataPoint)** : A list of *DataPoint* components for an event's payload. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Property*. Optional.
+- **DataType** : The data type of the property. This must be a [SimpleType](#SimpleType).
#### Example
-
- <Event name="stateChanged">
- <Doc>Some documentation for the Event</Doc>
- <Data>
- <DataPoint name="state">
- <DataType>
- <SimpleType type="boolean" />
- </DataType>
- </DataPoint>
- </Data>
- </Event>
+```xml
+<Property name="ManufacturedDate" value="2015.10.30 10:06">
+ <SimpleType type="datetime" />
+</Property>
+```
---
-<a name="Arg"/></a>
+<a name="DataTypes"/></a>
+## Data Types
-### Arg : Element of *Action*
-
-
-The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
+A data type can be simple integers or string text, or rather complex, as shown in the following diagram:
-The *Arg* has the following attributes and elements:
-
-#### Attributes
-- **name** : The name of the *Arg* attribute. Required.
-
-#### Elements
-- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
-- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
+
-#### Example
-See [example above](#ActionExample).
+The various elements of *DataType* are described in the following sections.
----
+*DataTypes* can be rather complex and it might be reasonable to define them on the [Domain](#Domain) level. This way the only need to be defined once and can be references through the [Extend](#Extend) element later, and also across [Domains](#Domain).
-<a name="Data_Types"/></a>
+<a name="DataType"/></a>
### DataType
-The data type can be simple integers or string text, or rather complex, as shown below:
-
-
-The various elements are described in the sections below.
+Element of a [Domain](#Domain), [Property](#Property), [Action](#Action), [Arg](#Arg), [DataPoint](#DataPoint), [Event](#Event), [StructType](#StructType), and [ArrayType](#ArrayType).
The *DataType* element is a "container" for the various aspects of a type.
#### Attributes
-- **name** : The name of the *DataType*. The name must be set for the [Struct](#Struct) types to distinguish individual fields in that structure. It can be used in other cases. Optional.
+- **name** : The name of the *DataType*. Optional, with the exception that the name must be set for fields in a [Struct](#Struct) to distinguish individual fields in that structure.
- **unitOfMeasure** : Before considering the type of data in detail, there is the option to label the data with the units of measurement. A "Temperature" measurement is meaningless until the units Kelvin, Celcius, Fahrenheit etc are known. Because of the extreme variety of units, a string field is the default annotation method, although of course a SDO could decide to reference a standardized list of units. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
- **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional.
@@ -501,39 +496,42 @@ The *DataType* element is a "container" for the various aspects of a type.
- **[SimpleType](#SimpleType)**
- **[Struct](#StructType)**
- **[Array](#ArrayType)**
+ - **[EnumType](#EnumType)**
- **[Constraint](#Constraint)** : A list of *Constraint* elements. Optional.
---
<a name="Constraint"/></a>
-
-### Constraint : Element of DataType
+### Constraint
+Element of [DataType](#DataType).
-The *Constraint* element is an optional element allowing the manufacturer to provide constraints on the permitted values of measured data or input parameters. It can significantly improve the reliability of software and validation of transmitted data.
+The *Constraint* element is an optional element allowing the manufacturer or organization to provide constraints on the permitted values of measured data or input parameters. It can significantly improve the reliability of software and validation of transmitted data.
#### Attributes
- **name** : The name or ID that identifies the *Constraint*. Required.
- **type** : The basic data type of the constraint. Note that this may be different from the type of the [DataType](#DataType) that this *Constraint* is assigned to. For example, a *Constraint* that specifies a maximum length of a string is of type *integer*. Optional.
- **value** : A pre-assigned value for the constraint, for example the maximum number of characters in a string. Optional.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
#### Elements
-- **[Doc](#Documentation)** : Documentation for the *Cosntraint* Element. Optional.
+- **[Doc](#Documentation)** : Documentation for the *Constraint* Element. Optional.
---
-### TypeChoice : Construct of *DataType*
+### TypeChoice
+Construct of [DataType](#DataType).
- 
+
-The *TypeChoice* construct is required for syntactic reasons in the UML diagram and the choice from the enumerated list simply designates the complexity of the following DataType.
+The *TypeChoice* construct is required for syntactic reasons in the UML diagram and the choice from the enumerated list simply designates the complexity of the following DataType. It is not directly instantiated or addressed.
---
<a name="SimpleType"/></a>
-
-### SimpleType : Element of *TypeChoice*
+### SimpleType
+Element of [DataType](#DataType).
@@ -545,12 +543,13 @@ The *SimpleType* element is required in order for software to understand the for
If not stated otherwise datatypes should comply to the equivalent datatypes defined in [XML Schema Part 2: Datatypes Second Edition](http://www.w3.org/TR/xmlschema-2/#boolean):
+
+
- **boolean** : A boolean value as defined in [http://www.w3.org/TR/xmlschema-2/#boolean](http://www.w3.org/TR/xmlschema-2/#boolean) .
- **byte** : An integer datatype with the range of [0 - 255] as defined in [http://www.w3.org/TR/xmlschema-2/#unsignedByte](http://www.w3.org/TR/xmlschema-2/#unsignedByte) .
- **integer** : An integer value as defined in [http://www.w3.org/TR/xmlschema-2/#integer](http://www.w3.org/TR/xmlschema-2/#integer) .
- **float** : An IEEE single-precision 32-bit floating point type as defined in [http://www.w3.org/TR/xmlschema-2/#float](http://www.w3.org/TR/xmlschema-2/#float) .
- **string** : The string datatype represents character strings as defined in [http://www.w3.org/TR/xmlschema-2/#string](http://www.w3.org/TR/xmlschema-2/#string) .
-- **enum** : A complete and orderd list of items in a collection. Items in an enumeration are separated by commas (, 0x2c) and must be of one of the datatypes defined here. Commas (, 0x2c) and backslashes (\ 0x5c) in enumaration items must be escaped by backslash.
- **date** : A date value as defined in [http://www.w3.org/TR/xmlschema-2/#date](http://www.w3.org/TR/xmlschema-2/#date) .
- **time** : A time value as defined in [http://www.w3.org/TR/xmlschema-2/#time](http://www.w3.org/TR/xmlschema-2/#time) .
- **datetime** : A time value as defined in [http://www.w3.org/TR/xmlschema-2/#dateTime](http://www.w3.org/TR/xmlschema-2/#dateTime) .
@@ -558,38 +557,200 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi
- **uri** : A URI that represents a Uniform Resource Identifier Reference (URI) as defined by as defined in [RFC 2396](http://www.ietf.org/rfc/rfc2396.txt) and amended in [RFC 2732](http://www.ietf.org/rfc/rfc2732.txt) .
- **void** : The data type *void* represents the absence of a value. This data type can be used for [Actions](#Action) that don't return any value.
+
+### Example
+```xml
+<DataPoint name="simpleDataPoint">
+ <DataType>
+ <SimpleType type="string" />
+ </DataType>
+</DataPoint>
+```
---
<a name="StructType"/></a>
-
-### StructType : Element of *TypeChoice*
+### StructType
+Element of [DataType](#DataType).
The *StructType* element can be used to represent an ordered list of diverse DataTypes, which are represented by the *name* attribute of each [DataType](#DataType), and can be used recursively.
#### Elements
-- **[DataType](#DataType)** : A list of DataTypes elements representing the elements of a structure.
-
+- **[DataType](#DataType)** : A list of *DataTypes* elements representing the elements of a structure.
+
+### Example
+```xml
+<DataPoint name="structDataPoint">
+ <DataType name="structured">
+ <Struct>
+ <DataType name="aString">
+ <SimpleType type="string" />
+ </DataType>
+ <DataType name="anInteger">
+ <SimpleType type="integer" />
+ </DataType>
+ </Struct>
+ </DataType>
+</DataPoint>
+```
---
<a name="ArrayType"/></a>
-
-### ArrayType : Element of *TypeChoice*
+### ArrayType
+Element of [DataType](#DataType).
The *ArrayType* element is provided for defining lists of data; the definition is recursive so that multi-dimensional arrays can be described. Note that a Constraint can be used to provide limits on Array size.
#### Elements
-- **[DataType](#DataType)** : A single DataType element that specifies the data type for the elements of the array.
+- **[DataType](#DataType)** : A single *DataType* element that specifies the data type for the elements of the array.
+
+### Example
+```xml
+<DataPoint name="arrayDataPoint">
+ <DataType name="arrayOfInteger">
+ <Array>
+ <DataType>
+ <SimpleType type="integer" />
+ </DataType>
+ </Array>
+ </DataType>
+</DataPoint>
+```
---
-<a name="Documentation"/></a>
+<a name="EnumType"/></a>
+### EnumType
+Element of [DataType](#DataType).
+
+
+
+The *EnumType* element is provided for defining an enumeration data type; it defines a (possibly mixed) typed set of [EnumValues](#EnumValue).
+
+#### Elements
+- **[EnumValue](#EnumValue)** : A list of *EnumValue" element that specifies the data type for the elements of the array.
+
+<a name="EnumTypeExample"/></a>
+#### Example
+```xml
+<DataPoint name="enumDataPoint">
+ <DataType name="enumOfInteger">
+ <Enum>
+ <EnumValue name="red" value="1" type="integer" />
+ <EnumValue name="green" value="2" />
+ <EnumValue name="blue" value="3" />
+ </Enum>
+ </DataType>
+</DataPoint>
+```
+
+---
-### Doc : Element for all Documentation
+<a name="EnumValue"/></a>
+### EnumValue
+Element of [EnumType](#EnumType).
+
+
+
+The *EnumType* element is provided for defining an enumeration data type; it defines a (possibly mixed) typed set of [EnumValues](#EnumValue).
+
+#### Attributes
+- **name** : The name that identifies the *EnumValue*. Required.
+- **value** : An assigned value for the *EnumValue*. Required.
+- **type** : The *BasicType* of the *EnumValue*. An [EnumType](#EnumType) may have *EnumValues* of mixed type. Optional, the default is *integer*.
+- **semanticURI** : An attribute that contains a URI to a semantic description of the element. Optional.
+
+#### Elements
+- **[Doc](#Documentation)** : Documentation for the *EnumValue* Element. Optional.
+
+#### Example
+See [example in *EnumType*](#EnumTypeExample).
+
+---
+
+<a name="Extending"/></a>
+## Extending (Inheriting)
+
+The SDT supports inhering for certain element types. This is done by extending a parent element definition.
+
+By default, this method can be used in a simple way by just extending a whole parent element, but it is also possible to explicitly include or exclude certain elements from the derived element.
+
+Extension across [Domains](#Domain) is supported and encouraged.
+
+
+
+<a name="ExtendExample"/></a>
+#### Example
+The following example defines two [ModuleClasses](#ModuleClass), where the second definition extends to first one, but explicitly excludes one of the [DataPoints](#DataPoint).
+
+```xml
+<ModuleClasses>
+ <ModuleClass name="aModuleClass">
+ <Data>
+ <DataPoint name="dataPoint1">
+ <!-- type definition -->
+ </DataPoint>
+ <DataPoint name="dataPoint2">
+ <!-- type definition -->
+ </DataPoint>
+ </Data>
+ </ModuleClass>
+ <ModuleClass name="anotherModuleClass">
+ <Extend domain="aDomain" entity="aModuleClass">
+ <Exclude name="dataPoint2" type="datapoint" />
+ </Extend>
+ <!-- more local definitions, such as Actions, DataPoints etc -->
+ </ModuleClass>
+</ModuleClasses>
+```
+
+---
+
+<a name="Extend"/></a>
+### Extend
+Element of [ProductClass](#ProductClass), [ModuleClass](#ModuleClass) and [DataType](#DataType).
+
+
+
+The *Extend* element specifies which element to extend. As a simple element it can be used to fully include the referenced element into the derived element, but it is also possible to explicitly include or exclude certain elements. Please note, that it is only possible to either **include** or **exclude** elements.
+
+#### Attributes
+- **domain** : Identifier / Reference of the [Domain](#Domain) of the extended element. Required.
+- **entity** : Name of the element in the [Domain](#Domain) that is extended. Required.
+
+#### Elements
+- **ExtendChoice** : This element is actual an element from the following list of extend choices. Please note, that it is only possible to either **include** or **exclude** elements.
+ - **[Include](#ExtendInclude)**
+ - **[Exclude](#ExtendExclude)**
+
+#### Example
+See [example in *Extending (Inheriting)*](#ExtendExample).
+
+---
+
+<a name="ExtendInclude"/></a>
+### Include
+
+---
+
+<a name="ExtendExclude"/></a>
+### Exclude
+
+
+---
+
+<a name="ExtendType"/></a>
+### ExendType
+
+---
+
+<a name="Documentation"/></a>
+## Documentation (Doc)
+Element for documentation in all elements.
@@ -618,3 +779,7 @@ The intended use for each element is:
- **paragraph** : Structure the text in paragraphs.
- **image** : Include an image in the text. The image is loaded from the specified URL and must include a caption text.
+
+
+
+
diff --git a/SDT/schema4.0/docs/SDT_UML.uxf b/SDT/schema4.0/docs/SDT_UML.uxf
index 75d38b49ed36663de6960bf095fb1e4361ff7aec..3346d4985df1e8896a66f06be011ece45a171ed5 100644
--- a/SDT/schema4.0/docs/SDT_UML.uxf
+++ b/SDT/schema4.0/docs/SDT_UML.uxf
@@ -1,14 +1,14 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.3.0">
<help_text/>
- <zoom_level>10</zoom_level>
+ <zoom_level>8</zoom_level>
<element>
<id>UMLNote</id>
<coordinates>
- <x>1390</x>
- <y>1690</y>
- <w>290</w>
- <h>260</h>
+ <x>1168</x>
+ <y>1352</y>
+ <w>232</w>
+ <h>208</h>
</coordinates>
<panel_attributes>bg=#FAF8C8
fontsize=12
@@ -27,8 +27,8 @@ Subclassing
Cardinalities:
0,1 : zero or one
1 : exact one
-0..* : zero or many
-1..* : at least one or many
+0..n : zero or many
+1..n : at least one or many
group=1</panel_attributes>
<additional_attributes/>
@@ -36,14 +36,14 @@ group=1</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1520</x>
- <y>1790</y>
- <w>110</w>
- <h>40</h>
+ <x>1272</x>
+ <y>1432</y>
+ <w>88</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
fontsize=10
-m1=0..*
+0..n
group=1</panel_attributes>
<additional_attributes>90.0;20.0;10.0;20.0</additional_attributes>
@@ -51,10 +51,10 @@ group=1</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1520</x>
- <y>1830</y>
- <w>110</w>
- <h>30</h>
+ <x>1272</x>
+ <y>1464</y>
+ <w>88</w>
+ <h>24</h>
</coordinates>
<panel_attributes>lt=<<-
fontsize=10
@@ -64,10 +64,10 @@ group=1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1530</x>
- <y>1230</y>
- <w>150</w>
- <h>220</h>
+ <x>1280</x>
+ <y>984</y>
+ <w>120</w>
+ <h>176</h>
</coordinates>
<panel_attributes><<enumeration>>
BasicType
@@ -88,10 +88,10 @@ void</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>910</x>
- <y>1310</y>
- <w>140</w>
- <h>80</h>
+ <x>784</x>
+ <y>1048</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<.
m1= 0..1
@@ -101,10 +101,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>910</x>
- <y>1230</y>
- <w>140</w>
- <h>80</h>
+ <x>784</x>
+ <y>984</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<.
m1=0..1
@@ -114,10 +114,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>430</x>
- <y>1230</y>
- <w>190</w>
- <h>150</h>
+ <x>400</x>
+ <y>984</y>
+ <w>152</w>
+ <h>120</h>
</coordinates>
<panel_attributes>DataType
--
@@ -134,10 +134,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>610</x>
- <y>1180</y>
- <w>680</w>
- <h>120</h>
+ <x>544</x>
+ <y>944</y>
+ <w>544</w>
+ <h>96</h>
</coordinates>
<panel_attributes>lt=<<.
m2=1..n
@@ -147,10 +147,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>610</x>
- <y>1180</y>
- <w>680</w>
- <h>180</h>
+ <x>544</x>
+ <y>944</y>
+ <w>544</w>
+ <h>144</h>
</coordinates>
<panel_attributes>lt=<<.
m2=1
@@ -160,10 +160,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1030</x>
- <y>1350</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>1080</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>SimpleType
--
@@ -174,10 +174,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1210</x>
- <y>1380</y>
- <w>340</w>
- <h>40</h>
+ <x>1024</x>
+ <y>1104</y>
+ <w>272</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<<-
m1= 1
@@ -187,10 +187,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1030</x>
- <y>1470</y>
- <w>190</w>
- <h>110</h>
+ <x>880</x>
+ <y>1176</y>
+ <w>152</w>
+ <h>88</h>
</coordinates>
<panel_attributes>Constraint
--
@@ -205,10 +205,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>610</x>
- <y>1330</y>
- <w>440</w>
- <h>180</h>
+ <x>544</x>
+ <y>1064</y>
+ <w>352</w>
+ <h>144</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -218,10 +218,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1210</x>
- <y>1440</y>
- <w>420</w>
- <h>140</h>
+ <x>1024</x>
+ <y>1152</y>
+ <w>336</w>
+ <h>112</h>
</coordinates>
<panel_attributes>lt=<<-
m1=1
@@ -231,10 +231,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1030</x>
- <y>1230</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>984</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>StructType
--
@@ -245,10 +245,10 @@ fg=blue</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1030</x>
- <y>1290</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>1032</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>ArrayType
--
@@ -259,10 +259,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>910</x>
- <y>1280</y>
- <w>140</w>
- <h>50</h>
+ <x>784</x>
+ <y>1024</y>
+ <w>112</w>
+ <h>40</h>
</coordinates>
<panel_attributes>lt=<<.
m1= 0..1
@@ -273,10 +273,10 @@ fontsize=12
<element>
<id>UMLClass</id>
<coordinates>
- <x>430</x>
- <y>1090</y>
- <w>1250</w>
- <h>40</h>
+ <x>400</x>
+ <y>872</y>
+ <w>1000</w>
+ <h>32</h>
</coordinates>
<panel_attributes>halign=center
SDT 4.0 - DataType
@@ -288,10 +288,10 @@ lw=0.1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>70</x>
+ <x>112</x>
<y>0</y>
- <w>1610</w>
- <h>40</h>
+ <w>1288</w>
+ <h>32</h>
</coordinates>
<panel_attributes>SDT 4.0 - Basic Elements
halign=center
@@ -303,10 +303,10 @@ lw=0.1</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>780</x>
- <y>130</y>
- <w>240</w>
- <h>180</h>
+ <x>680</x>
+ <y>104</y>
+ <w>192</w>
+ <h>144</h>
</coordinates>
<panel_attributes>ModuleClass
--
@@ -326,10 +326,10 @@ fg=blue
<element>
<id>UMLClass</id>
<coordinates>
- <x>1130</x>
- <y>130</y>
- <w>220</w>
- <h>130</h>
+ <x>960</x>
+ <y>104</y>
+ <w>176</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Action
--
@@ -345,10 +345,10 @@ fg=blue</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1470</x>
- <y>220</y>
- <w>210</w>
- <h>130</h>
+ <x>1232</x>
+ <y>176</y>
+ <w>168</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Arg
--
@@ -364,10 +364,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1340</x>
- <y>220</y>
- <w>150</w>
- <h>40</h>
+ <x>1128</x>
+ <y>176</y>
+ <w>120</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
@@ -377,10 +377,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>90</x>
- <y>130</y>
- <w>230</w>
- <h>160</h>
+ <x>128</x>
+ <y>104</y>
+ <w>184</w>
+ <h>128</h>
</coordinates>
<panel_attributes>Domain
--
@@ -398,10 +398,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>130</y>
- <w>170</w>
- <h>80</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -411,10 +411,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>420</x>
- <y>440</y>
- <w>220</w>
- <h>110</h>
+ <x>392</x>
+ <y>352</y>
+ <w>176</w>
+ <h>88</h>
</coordinates>
<panel_attributes>SubDevice
--
@@ -429,10 +429,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>250</y>
- <w>70</w>
- <h>90</h>
+ <x>560</x>
+ <y>200</y>
+ <w>56</w>
+ <h>72</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -442,10 +442,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>320</y>
- <w>170</w>
- <h>190</h>
+ <x>560</x>
+ <y>256</y>
+ <w>136</w>
+ <h>152</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
@@ -455,10 +455,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1470</x>
- <y>500</y>
- <w>210</w>
- <h>50</h>
+ <x>1232</x>
+ <y>400</y>
+ <w>168</w>
+ <h>40</h>
</coordinates>
<panel_attributes>Doc
--
@@ -468,10 +468,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1010</x>
- <y>130</y>
- <w>140</w>
- <h>70</h>
+ <x>864</x>
+ <y>104</y>
+ <w>112</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
@@ -481,10 +481,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1410</x>
- <y>500</y>
- <w>80</w>
- <h>40</h>
+ <x>1184</x>
+ <y>400</y>
+ <w>64</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..1
@@ -494,10 +494,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1010</x>
- <y>190</y>
- <w>140</w>
- <h>120</h>
+ <x>864</x>
+ <y>152</y>
+ <w>112</w>
+ <h>96</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
@@ -507,10 +507,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1130</x>
- <y>270</y>
- <w>220</w>
- <h>180</h>
+ <x>960</x>
+ <y>216</y>
+ <w>176</w>
+ <h>144</h>
</coordinates>
<panel_attributes>DataPoint
--
@@ -531,10 +531,10 @@ fg=blue
<element>
<id>UMLClass</id>
<coordinates>
- <x>1130</x>
- <y>460</y>
- <w>220</w>
- <h>110</h>
+ <x>960</x>
+ <y>368</y>
+ <w>176</w>
+ <h>88</h>
</coordinates>
<panel_attributes>Event
--
@@ -549,10 +549,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1010</x>
- <y>290</y>
- <w>140</w>
- <h>210</h>
+ <x>864</x>
+ <y>232</y>
+ <w>112</w>
+ <h>168</h>
</coordinates>
<panel_attributes>lt=<.
m1= 0..n
@@ -562,10 +562,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>130</y>
- <w>170</w>
- <h>420</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>336</h>
</coordinates>
<panel_attributes>lt=<.
@@ -575,10 +575,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>420</x>
- <y>300</y>
- <w>220</w>
- <h>130</h>
+ <x>392</x>
+ <y>240</y>
+ <w>176</w>
+ <h>104</h>
</coordinates>
<panel_attributes>DeviceClass
--
@@ -594,10 +594,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>400</y>
- <w>80</w>
- <h>80</h>
+ <x>560</x>
+ <y>320</y>
+ <w>64</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -607,10 +607,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>130</y>
- <w>170</w>
- <h>280</h>
+ <x>560</x>
+ <y>104</y>
+ <w>136</w>
+ <h>224</h>
</coordinates>
<panel_attributes>lt=<.
fontsize=12</panel_attributes>
@@ -619,10 +619,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>320</y>
- <w>170</w>
- <h>70</h>
+ <x>560</x>
+ <y>256</y>
+ <w>136</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.</panel_attributes>
<additional_attributes>150.0;10.0;80.0;10.0;80.0;50.0;10.0;50.0</additional_attributes>
@@ -630,10 +630,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>780</x>
- <y>320</y>
- <w>240</w>
- <h>130</h>
+ <x>680</x>
+ <y>256</y>
+ <w>192</w>
+ <h>104</h>
</coordinates>
<panel_attributes>Property
--
@@ -650,10 +650,10 @@ transparency=80</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1340</x>
- <y>130</y>
- <w>70</w>
- <h>400</h>
+ <x>1128</x>
+ <y>104</y>
+ <w>56</w>
+ <h>320</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -663,10 +663,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1010</x>
- <y>290</y>
- <w>70</w>
- <h>70</h>
+ <x>864</x>
+ <y>232</y>
+ <w>56</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -676,10 +676,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>730</x>
- <y>1240</y>
- <w>190</w>
- <h>110</h>
+ <x>640</x>
+ <y>992</y>
+ <w>152</w>
+ <h>88</h>
</coordinates>
<panel_attributes><<enumeration>>
TypeChoice
@@ -695,10 +695,10 @@ Enum : EnumType
<element>
<id>Relation</id>
<coordinates>
- <x>610</x>
- <y>1250</y>
- <w>140</w>
- <h>80</h>
+ <x>544</x>
+ <y>1000</y>
+ <w>112</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<-
m1= 1
@@ -708,10 +708,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>210</y>
- <w>170</w>
- <h>140</h>
+ <x>560</x>
+ <y>168</y>
+ <w>136</w>
+ <h>112</h>
</coordinates>
<panel_attributes>lt=<.
fontsize=12</panel_attributes>
@@ -720,10 +720,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>310</x>
- <y>90</y>
- <w>490</w>
- <h>110</h>
+ <x>304</x>
+ <y>72</y>
+ <w>392</w>
+ <h>88</h>
</coordinates>
<panel_attributes>lt=<.
</panel_attributes>
@@ -732,10 +732,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>630</x>
- <y>230</y>
- <w>80</w>
- <h>240</h>
+ <x>560</x>
+ <y>184</y>
+ <w>64</w>
+ <h>192</h>
</coordinates>
<panel_attributes>lt=<.
@@ -745,10 +745,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1030</x>
- <y>1410</y>
- <w>190</w>
- <h>50</h>
+ <x>880</x>
+ <y>1128</y>
+ <w>152</w>
+ <h>40</h>
</coordinates>
<panel_attributes>EnumType
--
@@ -759,10 +759,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>910</x>
- <y>1320</y>
- <w>140</w>
- <h>130</h>
+ <x>784</x>
+ <y>1056</y>
+ <w>112</w>
+ <h>104</h>
</coordinates>
<panel_attributes>lt=<<.
m1=0..1
@@ -772,10 +772,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1280</x>
- <y>1430</y>
- <w>210</w>
- <h>110</h>
+ <x>1080</x>
+ <y>1144</y>
+ <w>168</w>
+ <h>88</h>
</coordinates>
<panel_attributes>EnumValue
--
@@ -790,10 +790,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1210</x>
- <y>1430</y>
- <w>90</w>
- <h>40</h>
+ <x>1024</x>
+ <y>1144</y>
+ <w>72</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<<.
m1=1..n
@@ -803,10 +803,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1480</x>
- <y>1440</y>
- <w>110</w>
- <h>80</h>
+ <x>1240</x>
+ <y>1152</y>
+ <w>88</w>
+ <h>64</h>
</coordinates>
<panel_attributes>lt=<<-
m1=0..1
@@ -816,10 +816,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>490</x>
- <y>780</y>
- <w>220</w>
- <h>80</h>
+ <x>448</x>
+ <y>624</y>
+ <w>176</w>
+ <h>64</h>
</coordinates>
<panel_attributes>Extend
--
@@ -833,10 +833,10 @@ fg=blue
<element>
<id>UMLClass</id>
<coordinates>
- <x>1110</x>
- <y>780</y>
- <w>240</w>
- <h>70</h>
+ <x>944</x>
+ <y>624</y>
+ <w>192</w>
+ <h>56</h>
</coordinates>
<panel_attributes>Exclude
--
@@ -848,10 +848,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1020</x>
- <y>780</y>
- <w>110</w>
- <h>70</h>
+ <x>872</x>
+ <y>624</y>
+ <w>88</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
m1= 1..n
@@ -862,10 +862,10 @@ fontsize=12
<element>
<id>Relation</id>
<coordinates>
- <x>430</x>
- <y>780</y>
- <w>80</w>
- <h>40</h>
+ <x>400</x>
+ <y>624</y>
+ <w>64</w>
+ <h>32</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..1
@@ -875,10 +875,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1460</x>
- <y>780</y>
- <w>220</w>
- <h>160</h>
+ <x>1224</x>
+ <y>624</y>
+ <w>176</w>
+ <h>128</h>
</coordinates>
<panel_attributes><<enumeration>>
ExtendType
@@ -896,10 +896,10 @@ subdevice
<element>
<id>Relation</id>
<coordinates>
- <x>1340</x>
- <y>780</y>
- <w>140</w>
- <h>70</h>
+ <x>1128</x>
+ <y>624</y>
+ <w>112</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<<-
m1=0..1
@@ -909,10 +909,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>1110</x>
- <y>860</y>
- <w>240</w>
- <h>70</h>
+ <x>944</x>
+ <y>688</y>
+ <w>192</w>
+ <h>56</h>
</coordinates>
<panel_attributes>Include
--
@@ -924,10 +924,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>1020</x>
- <y>840</y>
- <w>110</w>
- <h>60</h>
+ <x>872</x>
+ <y>672</y>
+ <w>88</w>
+ <h>48</h>
</coordinates>
<panel_attributes>lt=<.
m1= 1..n
@@ -938,10 +938,10 @@ fontsize=12
<element>
<id>Relation</id>
<coordinates>
- <x>1340</x>
- <y>780</y>
- <w>140</w>
- <h>150</h>
+ <x>1128</x>
+ <y>624</y>
+ <w>112</w>
+ <h>120</h>
</coordinates>
<panel_attributes>lt=-
@@ -951,10 +951,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>810</x>
- <y>780</y>
- <w>220</w>
- <h>80</h>
+ <x>704</x>
+ <y>624</y>
+ <w>176</w>
+ <h>64</h>
</coordinates>
<panel_attributes><<enumeration>>
ExtendChoice
@@ -969,10 +969,10 @@ Includes : Include
<element>
<id>Relation</id>
<coordinates>
- <x>700</x>
- <y>790</y>
- <w>130</w>
- <h>70</h>
+ <x>616</x>
+ <y>632</y>
+ <w>104</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<<-
m1=0..1
@@ -983,10 +983,10 @@ fontsize=12
<element>
<id>UMLClass</id>
<coordinates>
- <x>420</x>
- <y>130</y>
- <w>220</w>
- <h>160</h>
+ <x>392</x>
+ <y>104</y>
+ <w>176</w>
+ <h>128</h>
</coordinates>
<panel_attributes>ProductClass
--
@@ -1004,10 +1004,10 @@ fg=blue</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>310</x>
- <y>270</y>
- <w>130</w>
- <h>70</h>
+ <x>304</x>
+ <y>216</y>
+ <w>104</w>
+ <h>56</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -1017,10 +1017,10 @@ fontsize=12</panel_attributes>
<element>
<id>Relation</id>
<coordinates>
- <x>310</x>
- <y>130</y>
- <w>130</w>
- <h>130</h>
+ <x>304</x>
+ <y>104</y>
+ <w>104</w>
+ <h>104</h>
</coordinates>
<panel_attributes>lt=<.
m1=0..n
@@ -1030,10 +1030,10 @@ fontsize=12</panel_attributes>
<element>
<id>UMLClass</id>
<coordinates>
- <x>430</x>
- <y>670</y>
- <w>1250</w>
- <h>40</h>
+ <x>400</x>
+ <y>536</y>
+ <w>1000</w>
+ <h>32</h>
</coordinates>
<panel_attributes>halign=center
SDT 4.0 - Extend
diff --git a/SDT/schema4.0/docs/UML Diagram.md b/SDT/schema4.0/docs/UML Diagram.md
index 15a0f0b5cf5bc944ed25fb07b925157e027fc1aa..653717445648c072f09c1149924bb1c736e41da5 100644
--- a/SDT/schema4.0/docs/UML Diagram.md
+++ b/SDT/schema4.0/docs/UML Diagram.md
@@ -1,6 +1,11 @@
# UML Diagram of the SDT 4.0
-The source for the diagrams below is [here](SDT_UML.uxf).
+The source for the diagrams below can be found [here (SDT_UML.uxf)](SDT_UML.uxf).
+
+## Key
+
+
+
## Basic Elements
@@ -9,6 +14,6 @@ The source for the diagrams below is [here](SDT_UML.uxf).
-## Key
+## Extend
-
+
diff --git a/SDT/schema4.0/docs/images/Action.png b/SDT/schema4.0/docs/images/Action.png
index e0ef5763eb818538d8e0652652e79c221e7eedbd..3b2b58e715328d08c6fab9d9d010002d01b74e5e 100644
Binary files a/SDT/schema4.0/docs/images/Action.png and b/SDT/schema4.0/docs/images/Action.png differ
diff --git a/SDT/schema4.0/docs/images/Arg.png b/SDT/schema4.0/docs/images/Arg.png
index 4df9eb09ff0855c2523e8fb2f31448a44d675d9b..86993aa56736837004cd01db2d73360d56401ab5 100644
Binary files a/SDT/schema4.0/docs/images/Arg.png and b/SDT/schema4.0/docs/images/Arg.png differ
diff --git a/SDT/schema4.0/docs/images/Array.png b/SDT/schema4.0/docs/images/Array.png
index 6935adc0c1390c7cfd08bd4593f83b9f0b545db6..30982dc73b44c1033c96314b66f5df7be8fda1c7 100644
Binary files a/SDT/schema4.0/docs/images/Array.png and b/SDT/schema4.0/docs/images/Array.png differ
diff --git a/SDT/schema4.0/docs/images/BasicType.png b/SDT/schema4.0/docs/images/BasicType.png
new file mode 100644
index 0000000000000000000000000000000000000000..45dcb9d3c2211a3e6743afb94b04fd196c79231e
Binary files /dev/null and b/SDT/schema4.0/docs/images/BasicType.png differ
diff --git a/SDT/schema4.0/docs/images/Constraint.png b/SDT/schema4.0/docs/images/Constraint.png
index 4293b90e6c7c8224987fb836a703072bb625acfb..fbb39f318aa566b156b47629a3672d414585fb0b 100644
Binary files a/SDT/schema4.0/docs/images/Constraint.png and b/SDT/schema4.0/docs/images/Constraint.png differ
diff --git a/SDT/schema4.0/docs/images/DataPoint.png b/SDT/schema4.0/docs/images/DataPoint.png
index 69ca53b5cdde67940fd3e584fdb6ef807bc3d9bf..1117872599502c1684ba72ae7c24a9470f77377f 100644
Binary files a/SDT/schema4.0/docs/images/DataPoint.png and b/SDT/schema4.0/docs/images/DataPoint.png differ
diff --git a/SDT/schema4.0/docs/images/DataType.png b/SDT/schema4.0/docs/images/DataType.png
index 331498883c24a8d3160603b0725a25d5bac18eac..8db0da0b4302c8cd15a4ffe4a18ebb09dd9a1534 100644
Binary files a/SDT/schema4.0/docs/images/DataType.png and b/SDT/schema4.0/docs/images/DataType.png differ
diff --git a/SDT/schema4.0/docs/images/Device.png b/SDT/schema4.0/docs/images/Device.png
deleted file mode 100644
index 39ac44b0ab73abcabae53fbaf6641aba0dd3da50..0000000000000000000000000000000000000000
Binary files a/SDT/schema4.0/docs/images/Device.png and /dev/null differ
diff --git a/SDT/schema4.0/docs/images/DeviceClass.png b/SDT/schema4.0/docs/images/DeviceClass.png
new file mode 100644
index 0000000000000000000000000000000000000000..0b774eea9434d12592d003dd609d3f550974f33b
Binary files /dev/null and b/SDT/schema4.0/docs/images/DeviceClass.png differ
diff --git a/SDT/schema4.0/docs/images/Domain.png b/SDT/schema4.0/docs/images/Domain.png
index 1b70166e755a694b0ee73d171dd59e8c25c2a7e9..afcbcde446a7b70da3efa2928ac7644b3b3a3f23 100644
Binary files a/SDT/schema4.0/docs/images/Domain.png and b/SDT/schema4.0/docs/images/Domain.png differ
diff --git a/SDT/schema4.0/docs/images/Enum.png b/SDT/schema4.0/docs/images/Enum.png
new file mode 100644
index 0000000000000000000000000000000000000000..db3738a8b77db61aefae50fafaec58079d1d0556
Binary files /dev/null and b/SDT/schema4.0/docs/images/Enum.png differ
diff --git a/SDT/schema4.0/docs/images/EnumValue.png b/SDT/schema4.0/docs/images/EnumValue.png
new file mode 100644
index 0000000000000000000000000000000000000000..e2fc189d10e2037adc5505c68ef35639c430bf84
Binary files /dev/null and b/SDT/schema4.0/docs/images/EnumValue.png differ
diff --git a/SDT/schema4.0/docs/images/Event.png b/SDT/schema4.0/docs/images/Event.png
index 7506c40b4d3387733195ca2242de40837f05fb46..3842ccb14d0a42a75809f8d2953ef63a2aee9713 100644
Binary files a/SDT/schema4.0/docs/images/Event.png and b/SDT/schema4.0/docs/images/Event.png differ
diff --git a/SDT/schema4.0/docs/images/Extend.png b/SDT/schema4.0/docs/images/Extend.png
new file mode 100644
index 0000000000000000000000000000000000000000..8fc8725a3e244f98d95f5fee13a9cdf3c25b1484
Binary files /dev/null and b/SDT/schema4.0/docs/images/Extend.png differ
diff --git a/SDT/schema4.0/docs/images/ModuleClass.png b/SDT/schema4.0/docs/images/ModuleClass.png
index 1878593c1d8999ba7e891c77d6494489d8b1dbee..3c8fa19e10746abafa6c34400c6ab3a5744f8b50 100644
Binary files a/SDT/schema4.0/docs/images/ModuleClass.png and b/SDT/schema4.0/docs/images/ModuleClass.png differ
diff --git a/SDT/schema4.0/docs/images/Product.png b/SDT/schema4.0/docs/images/Product.png
index 2b870b7189ba3f9aafb804a24d9dbdfc44b93fd9..5da397e839cd889f8032684474cd97fd0666db1b 100644
Binary files a/SDT/schema4.0/docs/images/Product.png and b/SDT/schema4.0/docs/images/Product.png differ
diff --git a/SDT/schema4.0/docs/images/Property.png b/SDT/schema4.0/docs/images/Property.png
index 89581586826c13719185f3ad75aad5392efdd6e6..972617c89d229e5dfa1e489b17174f81c2031984 100644
Binary files a/SDT/schema4.0/docs/images/Property.png and b/SDT/schema4.0/docs/images/Property.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png b/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png
index 7631a92344a860d5a4d0efff3eebd358939db848..188558e7d6854fb8c58b881e6fa414cb3bb6fe7e 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png and b/SDT/schema4.0/docs/images/SDT_UML_Basic_Elements.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_DataType.png b/SDT/schema4.0/docs/images/SDT_UML_DataType.png
index 6e59eb7c014802aa3c76b307d6a62bf885efdd86..113771b84a82d00cff2f78639cabb21f475afa13 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_DataType.png and b/SDT/schema4.0/docs/images/SDT_UML_DataType.png differ
diff --git a/SDT/schema4.0/docs/images/SDT_UML_Key.png b/SDT/schema4.0/docs/images/SDT_UML_Key.png
index 47960a5b026770b4c088efea11feba383abb94c9..b6fb00800ef8684fc4b0379c62fb552356719539 100644
Binary files a/SDT/schema4.0/docs/images/SDT_UML_Key.png and b/SDT/schema4.0/docs/images/SDT_UML_Key.png differ
diff --git a/SDT/schema4.0/docs/images/SimpleType.png b/SDT/schema4.0/docs/images/SimpleType.png
index 3e7d5b08ef7747985a993fec9d87da5374d23397..4a3c7b61e4edad95d5d78220f982bc720484a08a 100644
Binary files a/SDT/schema4.0/docs/images/SimpleType.png and b/SDT/schema4.0/docs/images/SimpleType.png differ
diff --git a/SDT/schema4.0/docs/images/Struct.png b/SDT/schema4.0/docs/images/Struct.png
index 854645418669bd142b8637443a6516b7eb6548c4..4e4c9984f6418980683ab633aec15699eee686fd 100644
Binary files a/SDT/schema4.0/docs/images/Struct.png and b/SDT/schema4.0/docs/images/Struct.png differ
diff --git a/SDT/schema4.0/docs/images/SubDevice.png b/SDT/schema4.0/docs/images/SubDevice.png
index e77637fd4681b6b6076e93d6bf9654f7b2499b84..50e497d33523029e67129c5138ef93f932d75e0e 100644
Binary files a/SDT/schema4.0/docs/images/SubDevice.png and b/SDT/schema4.0/docs/images/SubDevice.png differ
diff --git a/SDT/schema4.0/docs/images/TypeChoice.png b/SDT/schema4.0/docs/images/TypeChoice.png
index 3606b755f4bb18642f60f49f481a572b99a508ab..b2e48820501f4821232d751ec40b011c48db213a 100644
Binary files a/SDT/schema4.0/docs/images/TypeChoice.png and b/SDT/schema4.0/docs/images/TypeChoice.png differ