SDT issueshttps://git.onem2m.org/MAS/SDT/-/issues2019-06-22T02:03:59Zhttps://git.onem2m.org/MAS/SDT/-/issues/17Replace SubDevice by Device references / support bottomless device hierarchies?2019-06-22T02:03:59ZAndreas KraftReplace SubDevice by Device references / support bottomless device hierarchies?A question that is asked from time to time is why SDT is limited to one level of SubDevices. We had this discussion in the HGI at that time and found no real good requirement to have a non-restricted device hierarchy. Yes, in theory it i...A question that is asked from time to time is why SDT is limited to one level of SubDevices. We had this discussion in the HGI at that time and found no real good requirement to have a non-restricted device hierarchy. Yes, in theory it is nice to not be limited to a two-level device hierarchy, but in practice I have yet to find this a real limitation.
The question is whether we should take the opportunity to change this or whether the current solution is still good enough.
One possible change could be to make sub-devices first-class citizens / devices, and then reference those devices from another device.
What are your opinions about this?
https://git.onem2m.org/MAS/SDT/-/issues/16Align naming of SubDevice to DeviceClass2019-06-22T02:03:59ZAndreas KraftAlign naming of SubDevice to DeviceClass"Device" will be renamed to "DeviceClass" in SDT 4.0.
Shouldn't "SubDevice" be renamed to "SubDeviceClass" as well?"Device" will be renamed to "DeviceClass" in SDT 4.0.
Shouldn't "SubDevice" be renamed to "SubDeviceClass" as well?https://git.onem2m.org/MAS/SDT/-/issues/15Change XSD namespace from http://homegatewayinitiative.org/xml/dal/3.0 to ???2019-06-22T02:03:59ZAndreas KraftChange XSD namespace from http://homegatewayinitiative.org/xml/dal/3.0 to ???In version 3.x the SDT conforms to the name space of "http://homegatewayinitiative.org/xml/dal/3.0".
Shouldn't we change this to something oneM2M-related?
Suggestions?
- http://www.onem2m.org/xml/sdt/4.0
In version 3.x the SDT conforms to the name space of "http://homegatewayinitiative.org/xml/dal/3.0".
Shouldn't we change this to something oneM2M-related?
Suggestions?
- http://www.onem2m.org/xml/sdt/4.0
https://git.onem2m.org/MAS/SDT/-/issues/14New rule for creating new Device definitions2019-06-22T02:03:59ZAndreas KraftNew rule for creating new Device definitionsWe need to define a rule in TS-0023 (and perhaps in a "best practice" page in the online documentation) how to create a new Device definition for a Device. At least the following possibilities are open
- Create a new Device definition...We need to define a rule in TS-0023 (and perhaps in a "best practice" page in the online documentation) how to create a new Device definition for a Device. At least the following possibilities are open
- Create a new Device definition with a new name: when there are no or not many similarities to an existing Device definition
- Update an existing Device definition: when the new Device definition is very similar to an existing Device definition, and when the new Device definition would only add optional ModuleClasses.
With SDT 4, where Device inheritance is supported, there is another choice:
- Inherit from a similar Device, and add new and remove not wanted ModuleClasses.
https://git.onem2m.org/MAS/SDT/-/issues/13Inconsistent multiplicity notation in UML diagram2019-06-22T02:03:59ZAndreas KraftInconsistent multiplicity notation in UML diagramThe multiplicity of component relationship in the UML diagram of SDT 3 is different from the notation used in oneM2M. This shows in the current WI-87 branch: the notation used to add the "Product" component ("0..1") is different from the...The multiplicity of component relationship in the UML diagram of SDT 3 is different from the notation used in oneM2M. This shows in the current WI-87 branch: the notation used to add the "Product" component ("0..1") is different from the rest of the diagram ("0,1").
I would suggest to align this and to use the oneM2M notation consistently.
If agreed I can make a CR for that.https://git.onem2m.org/MAS/SDT/-/issues/12Renaming of SubDevice as well?2019-06-22T02:03:59ZAndreas KraftRenaming of SubDevice as well?Since *Device* will be renamed to *DeviceClass*, shouldn't we rename *SubDevice* to *SubDeviceClass* as well? There is a separate section in TS-0023 that defines Sub-Devices, after all.Since *Device* will be renamed to *DeviceClass*, shouldn't we rename *SubDevice* to *SubDeviceClass* as well? There is a separate section in TS-0023 that defines Sub-Devices, after all.https://git.onem2m.org/MAS/SDT/-/issues/11HGI history2019-06-22T02:03:59ZYongjing ZhangHGI historyThere are lot of HGI trails in the current SDT specification, such as "HGI believes ...", "HGI suggests..." in several MD files. Should we update it to 'oneM2M' for SDT4.0? Would there be any copyright issue if we do so? Or should we jus...There are lot of HGI trails in the current SDT specification, such as "HGI believes ...", "HGI suggests..." in several MD files. Should we update it to 'oneM2M' for SDT4.0? Would there be any copyright issue if we do so? Or should we just remove or rephrase those sentences?Andreas KraftAndreas Krafthttps://git.onem2m.org/MAS/SDT/-/issues/10Editing style betweeing referencing and font tyle2019-06-22T02:03:59ZYongjing ZhangEditing style betweeing referencing and font tyleIn current SDT_Components.md, when describing the definition of Elements or Attributes, sometimes it uses *italic* style when referring to the pre-defined terms, while sometimes it uses inline references (anchor).
Is there a clear ru...In current SDT_Components.md, when describing the definition of Elements or Attributes, sometimes it uses *italic* style when referring to the pre-defined terms, while sometimes it uses inline references (anchor).
Is there a clear rule for that?Andreas KraftAndreas Krafthttps://git.onem2m.org/MAS/SDT/-/issues/9Overriding and hiding of data points and actions in inModuleClass inheritance2019-06-22T02:03:59ZAndreas KraftOverriding and hiding of data points and actions in inModuleClass inheritanceIn SDT version 3, when a Module inherits from a ModuleClass, it inherits all the data points, actions etc from its parent.
To support the upcoming *Product* feature it might be useful to
- override existing data points etc in orde...In SDT version 3, when a Module inherits from a ModuleClass, it inherits all the data points, actions etc from its parent.
To support the upcoming *Product* feature it might be useful to
- override existing data points etc in order to change, for example, optionality. The overriding could be done explicitly for only a certain number of attributes of a data point, e.g. assigning a new optionality, unit of measure. We could (but I am not sure about this) also support a kind of *final* state for a data point etc, which would mean that the sub-element must not be changed when subclassing.
- hide existing (optional) data points etc in order to remove them from a sub-classed ModuleClass. I am not sure how to do this in a simple way. Perhaps we need define a section where all hidden / not-inherited elements are stated.
https://git.onem2m.org/MAS/SDT/-/issues/8'@name' in 'Module' vs in 'ModuleClass'2019-06-22T02:04:00ZYongjing Zhang'@name' in 'Module' vs in 'ModuleClass'According to current definition, 'Module' is the subclass of 'ModuleClass'. So a 'Module' should inherit the '@name' attribute from 'ModuleClass'.
In the example of 'mseed.xml', 'extends' from ModuleClass "BooleanState", the 'name' at...According to current definition, 'Module' is the subclass of 'ModuleClass'. So a 'Module' should inherit the '@name' attribute from 'ModuleClass'.
In the example of 'mseed.xml', 'extends' from ModuleClass "BooleanState", the 'name' attribute is overridden as "power". Does this mean the Module "power" no longer contain the attribute 'name'="BooleanState", but only 'name'="Power"?
<Modules>
<Module name="power">
<extends domain="hgi.dal.core" class="BooleanState"/>
</Module>
</Modules>
Or should it be modeled as an extended attribute: "ModuleInstanceName" (according to TS-0023, or find another similar term) so as to keep the original *type* information (i.e. "BooleanState") in the Module subclass? In this case, "Module" really becomes something more than "ModuleClass".
<Modules>
<Module instanceName="power">
<extends domain="hgi.dal.core" class="BooleanState"/>
</Module>
</Modules>https://git.onem2m.org/MAS/SDT/-/issues/7'id' vs 'name' vs ' type'2019-06-22T02:03:59ZYongjing Zhang'id' vs 'name' vs ' type'In current SDT model, '@id:ID', '@id:Name' and '@name:Text' are all used as sort of identifiers for 'Device', 'ModuleClass', 'Module', 'Property', 'Action', 'DataPoint', 'Event' etc.
In my understanding, all of them are supposed to be...In current SDT model, '@id:ID', '@id:Name' and '@name:Text' are all used as sort of identifiers for 'Device', 'ModuleClass', 'Module', 'Property', 'Action', 'DataPoint', 'Event' etc.
In my understanding, all of them are supposed to be unique (in its given context, e.g. two ModuleClasses in the same Domain shouldn't use the same 'name'). And many of them are more like a 'type' definition (in JSON schema).
Shouldn't we align the terms into just one (id, name, or type)?
I understand the datatypes of those attributes are defined differently (xs:ID, xs:Name for @id, while undefined for '@name'?), but is that necessary? Even though the types are different, the terms could be aligned I guess.Andreas KraftAndreas Krafthttps://git.onem2m.org/MAS/SDT/-/issues/6Introducing Concept of ‘Product’2019-06-22T02:03:59ZYongjing ZhangIntroducing Concept of ‘Product’Rationale:
-In real life of device manufacturing, there is an important concept of ‘Product’ (or Product Model/Type) for each specific type of devices.
E.g. Huawei FIT vs Huawei Watch 2
-A ‘Product’ is NOT the ‘Device Model’ as de...Rationale:
-In real life of device manufacturing, there is an important concept of ‘Product’ (or Product Model/Type) for each specific type of devices.
E.g. Huawei FIT vs Huawei Watch 2
-A ‘Product’ is NOT the ‘Device Model’ as defined in TS-0023, which is too generic and can be mapped to different vendors’ implementations, NOR a device instance of that ‘device model’ with an instantiated id, date of manufacturing, and the firmware/software version, etc. It can be ‘ordered’ by the customers, but not necessarily instantiated/manufactured.
-A ‘Product’ is a specialized model/type of ‘Device Model’ that has a specific/deterministic implementation - meaning selected Properties/Actions/Events among the optionals, and partially populated values of the properties like the manufacturer id, type, memory size, etc.
-A ‘Product’ may also extend the standardized ‘Device Model’ with additional ‘Modules’.
Suggestion: to introduce the concept of ‘Product’ in SDT4.0
-One (not oneM2M) can use SDT4.0 to specify its own ‘Product Models’ which are specialized from oneM2M ‘Device Models’, use it to generate oneM2M compatible resource mapping in an automated way, and exchange the ‘Product Models’ with business partners.
[MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT](/uploads/77d2706276585241dc311d2856645756/MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT)
https://git.onem2m.org/MAS/SDT/-/issues/5JSON Serialization2019-06-22T02:04:00ZYongjing ZhangJSON SerializationRationale:
-JSON Serialization is becoming more and more popular in RESTful implementations (comparing to XML)
--Pros: better readability, concise (also support binary encoding - CBOR)
--Cons: less schema validation capability
-oneM2...Rationale:
-JSON Serialization is becoming more and more popular in RESTful implementations (comparing to XML)
--Pros: better readability, concise (also support binary encoding - CBOR)
--Cons: less schema validation capability
-oneM2M native protocol bindings support JSON already
Suggestion: to add JSON Serialization in SDT4.0
FFS: JSON Schema limitations?https://git.onem2m.org/MAS/SDT/-/issues/4Constraints/ data type facets2019-06-22T02:04:00ZYongjing ZhangConstraints/ data type facetsSDT3.0 support explicit ‘Constraint’ for SimpleTypes, but it’s not clear whether/how it can be useful for data validation
Discussion:
-The semantics of ‘name’ attribute can be arbitrary, seems not verifiable, unless we specify them.
...SDT3.0 support explicit ‘Constraint’ for SimpleTypes, but it’s not clear whether/how it can be useful for data validation
Discussion:
-The semantics of ‘name’ attribute can be arbitrary, seems not verifiable, unless we specify them.
-How about leveraging the ‘Facets’ for ‘Simple Types’ of the XML Schema?
[MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT](/uploads/77d2706276585241dc311d2856645756/MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT)https://git.onem2m.org/MAS/SDT/-/issues/3Inheritance capability (extension) for ModuleClass and Device Md2019-06-22T02:04:00ZYongjing ZhangInheritance capability (extension) for ModuleClass and Device MdSDT3.0 uses the ‘extends’ to support the inheritance of ‘Modules’ & ‘ModuleClass’.
Discussion:
-Introduce the same mechanism for ‘Device Models’ in SDT4.0?
-Why not simply use ‘xsd:extension’ from XML Schema?
e.g. <extension base=...SDT3.0 uses the ‘extends’ to support the inheritance of ‘Modules’ & ‘ModuleClass’.
Discussion:
-Introduce the same mechanism for ‘Device Models’ in SDT4.0?
-Why not simply use ‘xsd:extension’ from XML Schema?
e.g. <extension base=“domain-x:ModuleClass-y">
[MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT](/uploads/77d2706276585241dc311d2856645756/MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT)https://git.onem2m.org/MAS/SDT/-/issues/2‘Device’ vs ‘Device Model’2019-06-22T02:04:00ZYongjing Zhang‘Device’ vs ‘Device Model’In SDT3.0 vocabulary, a class/type of device is called ‘Device’, while in TS-0023 (HAIM), ‘Device Model’ is used instead.
-Theses two terms are interchangeable in principle, and ‘Device Model’ seems more like a ‘type/class’ comparing t...In SDT3.0 vocabulary, a class/type of device is called ‘Device’, while in TS-0023 (HAIM), ‘Device Model’ is used instead.
-Theses two terms are interchangeable in principle, and ‘Device Model’ seems more like a ‘type/class’ comparing to ‘Device’.
Suggestion: to change ‘Device’ to ‘DeviceModel’ (or 'DeviceClass') in SDT4.0
-Backward compatibility may be a problem?
https://git.onem2m.org/MAS/SDT/-/issues/1‘Module – ModuleClass’ relationship2019-06-22T02:04:00ZYongjing Zhang‘Module – ModuleClass’ relationshipMisleading description in current SDT3.0: “The relationship between a ModuleClass and a Module is very similar to the specification of a class and an instantiated object in an object oriented programming language.”
Actually it’s clear...Misleading description in current SDT3.0: “The relationship between a ModuleClass and a Module is very similar to the specification of a class and an instantiated object in an object oriented programming language.”
Actually it’s clearly defined as ‘subclassing’ according to the UML diagram
(but it’s not explicitly reflected in the xsd either)
Suggestion: to revise the text to “… a superclass and a subclass …”
[MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT](/uploads/77d2706276585241dc311d2856645756/MAS-2018-0051R01-SDT_4_0_ehancement_discussion.PPT)
Yongjing ZhangYongjing Zhang