SDT 4 0 enhancement discussion Group Name MAS

SDT 4. 0 enhancement discussion Group Name: MAS WG Source: Yongjing Zhang, Huawei, zhangyongjing@huawei. com Meeting Date: 2018 -05 -22

Issues for consideration 1. 2. 3. 4. 5. 6. Confusion of ‘Module – Module. Class’ relationship Naming of ‘Device’ vs ‘Device Model’ Inheritance and ‘extension’ Constraints JSON serialization Concept of ‘Product’ © 2017 one. M 2 M Partners <Document number> 2

Issue #1: ‘Module – Module. Class’ relationship • Misleading description in SDT 3. 0: “The relationship between a Module. Class 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 …”

Issue #2: ‘Device’ vs ‘Device Model’ • In SDT 3. 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 ‘Device. Model’ in SDT 4. 0 – Backward compatibility may be a problem?

Issue #3: Inheritance capability • SDT 3. 0 uses the ‘extends’ to support the inheritance of ‘Modules’ & ‘Module. Class’. Schema: Example Instance: • Discussion: ─ Introduce the same mechanism for ‘Device Models’ in SDT 4. 0? ─ Why not simply use ‘xsd: extension’ from XML Schema? • e. g. <extension base=“domain-x: Module. Class-y">

Issue #4: Constraints/ data type facets • SDT 3. 0 support explicit ‘Constraint’ for Simple. Types, but it’s not clear whether/how it can be useful for data validation Example Instance: Schema: • 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?

Issue #5: JSON Serialization • 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 – one. M 2 M native protocol bindings support JSON already • Suggestion: to add JSON Serialization in SDT 4. 0 – FFS: JSON Schema limitations?

Issue #6: 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 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 SDT 4. 0 – One (not one. M 2 M) can use SDT 4. 0 to specify its own ‘Product Models’ which are specialized from one. M 2 M ‘Device Models’, use it to general one. M 2 M compatible resource mapping in an automated way, and exchange the ‘Product Models’ with business partners.

Backup