The <flexContainer> is different from the normal <container> resource in many ways:
- A <container> resource does not store actual values in the resource itself. Child-resources of <container>, ie. <contentInstance> or further <container> resources, do. In contrast, a <flexContainer> specialisation holds the actual values itself.
- A <flexContainer> itself cannot directly be instantiated, it only is the logical basis for further specialisations (very much like a base class in OOP). It defines a number of attributes that support these specialisations, for example the containerDefinition attribute contains an identifier that defines the actual type of a particular <flexContainer> resource. A <flexContainer> specialisation then specifies a well-defined structure that may contain a rather complex structure of data points.
The mentioned Devices and ModuleClasses from TS-0023 are such specialisations, e.g. the temperature. These specialisations have a well-defined structure with semantics, constraints etc.
- A big advantage of a <flexContainer> is that it can be updated, while <contentInstance>'s in a <container> can only be added or deleted. This also means that, if an application only needs the current status of a device and is not interested in older data values, a single <flexContainer> specialisation is (more or less) everything that application needs.
- All the data points contained in a <flexContainer> specialisation are read and written at the same time. In some cases this reduces a lot of communication overhead and reduces the chance of race conditions when reading or writing many data points.
To the SDT: The Smart Device Template is a specification method to define "Lego" blocks of functionalities, so-called "ModuleClasses". These ModuleClasses can then be taken in order to construct prototypical "Devices".
The mentioned oneM2M specification "TS-0023 : Home Appliances Information Model and Mapping" specifies a number of these ModuleClasses and Devices as well as the mapping to the <flexContainer> specialisations. That means that for the definition of a "temperature" functionality/ModuleClass there is a oneM2M <hd:temperature> resource available.
When you want to create a new Device definition using the SDT then I would suggest that you first look at the list of already defined ModuleClasses and Devices in TS-0023. If the functionality you need is not available then you can define your own ModuleClass and Device by writing your own SDT file.
The SDT definition is available at https://git.onem2m.org/MAS/SDT.
The latest version of the SDT for the ModuleClasses and Devices defined in TS-0023 is available at https://git.onem2m.org/MAS/Home-Appliances.
A tool to generate the necessary XSD from your SDT definition can be found at https://github.com/Homegateway/SDTTool.
Two more notes:
- Whether a CSE allows for self-defined <flexContainer> specialisations depends on the CSE implementation and policies.
- As of this writing (April 2019) oneM2M works on a new version of the SDT that supports, for example, product definitions, better inheritance, and further semantic support. oneM2M also works on a new version of the TS-0023 specification to support cross-domain IoT scenarios and devices, and not only the home domain.