diff --git a/SDT/schema4.0/docs/.gitignore b/SDT/schema4.0/docs/.gitignore index 8c2004ec4a2c39b30570f54485d4e18383311ca0..098beee23159dafe80282cdcd4fa14d05b253e17 100644 --- a/SDT/schema4.0/docs/.gitignore +++ b/SDT/schema4.0/docs/.gitignore @@ -1,2 +1,3 @@ /.Introduction.md.html /.SDT_Components.md.html +/.SDT_JSON.md.html diff --git a/SDT/schema4.0/docs/SDT_Components.md b/SDT/schema4.0/docs/SDT_Components.md index 7bf080a5551ce168d41871fe45669a35304c2093..a1188edc40575bbb2dfc8c9f737c04a9c055e83e 100644 --- a/SDT/schema4.0/docs/SDT_Components.md +++ b/SDT/schema4.0/docs/SDT_Components.md @@ -79,13 +79,13 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)  -The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClassess](#ModuleClass). +The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClasses](#ModuleClass). For each physical device on the network at least one *Device* **must** be defined. If the physical device is a simple device, i.e. it does not contain embedded devices, e.g. a light switch, it does not include further [SubDevices](#SubDevices). On the other hand, if the physical is a compound device, i.e. it does contain embedded devices that can be addressed separately, the *Device* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices. An example for a compound device is a connected power-strip where each of the sockets can be switched on and off individually. The power-strip itself can provide functions such as "all sockets off" and "overall power consumption". -*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClassesClasses of the same or another [Domain](Domain). +*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClasses(#ModuleClass) of the same or another [Domain](#Domain). #### Attributes - **id** : The identifier for that *Device*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required. @@ -179,7 +179,7 @@ Since the *Properties* are highly varied, depending on industry segment, no atte **ModuleClass** -*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can be extended from another pre-defined *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). A *ModuleClass* can be extended from another *ModuleClass* with additional functionalities. Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).