Evaluate Data Schema Constraints

[danielpeintner]

I believe we need to be careful about constraints (e.g., forbidding nested structures).

Ikea Tradfri has nested objects, see https://github.com/glenndehaan/ikea-tradfri-coap-docs#payload
e.g., switching on a lamp

{
  "3311": [
    {
      "5850": 1, // on / off
      "5851": 254, // dimmer (1 to 254)
      "5706": "f1e0b5", // color in HEX (Don't use in combination with: color X and/or color Y)
      "5709": 65535, // color X (Only use in combination with color Y)
      "5710": 65535, // color Y (Only use in combination with color X)
      "5712": 10 // transition time (fade time)
    }
  ]
}

Note: Tradfri uses COAP

[mlagally]

This example has a nesting level of 3.
We should make sure to define constraints that work in practice.
Let's try to find more examples.

[mmccool]

I agree that forbidding data models nesting to one level of nesting is unnecessarily restrictive and will cause more interoperability problems than it will solve. There are several additional examples for OCF devices that use greater nesting, and actually, TD themselves are a complex JSON file with deep nesting, so...

It is also not that big a deal to parse nested JSON structures on memory-limited devices; with an efficient parser a stack with only a few bytes per level would be needed. Handling the (required...) strings for descriptions will take more space, typically.

It might still, however, be useful to define a finite level of nesting. The real question is how we figure out what it should be. I would guess arbitrarily however that a nesting level of 10 (say) would cover nearly all the payloads for practical devices without unduly stressing even small devices.

[mmccool]

I should also mention that we want people to be able to use standard libraries for JSON, etc. If we add constraints "to make things simpler" then people might have to implement special libraries to be conformant, which would be a burden, and might even lead to undesirable things like having two JSON libraries on a device (one general-purpose, one special-cased).

[egekorkan]

Philips Hue seems to really like 2 nested levels. Example can be found here

[benfrancis]

Does a profile really need to define additional constraints for the Thing Description itself, or should it focus on defining the data format for data payloads as part of a protocol binding definition?

[zolkis]

This seems to be related to database normalization from cloud management pov.
I think in practice there is limited depth for nesting which falls within reasonable limits to be representable in a relational database. Whereas many constraints in the Profile spec make sense, I don't see the nesting constraint fully warranted.

[benfrancis]

There seems to be a consensus here that a constraint on nested data structures (as currently defined by section 5.1.3.1) is not desirable.

[benfrancis]

See also my comments in #10 and extensive review feedback in #93 (review)

[benfrancis]

See also comments in #37

[benfrancis]

Note: This is a subset of the discussion in #10

[sebastiankb]

I just found this guideline for device twins in Azure:

Depth: The maximum depth of JSON objects in tags, desired properties, and reported properties is 10.

[mlagally]

@sebastiankb
Thanks for providing this link, which shows practical system limits of a real world IoT system.
If we want to provide OOTBI with this system, we have to make sure the profile constraints are within these limits.

[sebastiankb]

@mlagally
Just to avoid misunderstanding. It is more an example that IoT solutions have different limitations. E.g., Azure seems to have nested data schema definitions with a depth of 10. Another platform will perhaps have a limitation of 5. The current WoT profile draft only allows a depth of 2! . How will you make a decision that is agreeable to all?

[mlagally]

We have removed these constraints, suggest we close the issue.
At some point we have to discuss a constrained profile and should create a new issue for that.