DataSchema strictness

[dodomorandi]

During the development of the builder for DataSchema and the relative supertypes (we are not modelling data using inheritance, but the abstract concept is applicable anyway), we realized that there are combinations of optional fields that should be avoided. In fact, the specification does not provide a clean way to handle these situation, therefore we decide to take a strict subset of the DataSchema spec in order to prevent ambiguous behaviors.

Here the rules we decide to follow:

• type and oneOf are mutually exclusive. As a consequence, only instances of DataSchema can use oneOf, subtypes cannot.
• const and oneOf are mutually exclusive. The reason behind this is that if a constant value is specified, it does not make sense to provide different possible representations.
• type, const and enum are mutually exclusive. In theory, type could express the content of const/enum when provided, but it is a redundant information in the best situation and a conflicting information in the worst. Therefore the type of DataSchema is inferred by const/enum and the instance should not be a subtype. We are making this situation impossible with the builder, and we are going to ignore the type field and eventual subtype fields when parsing WoT-TD data. Note: as a consequence of the initial claim, const and enum are mutually exclusive as well.
• oneOf, const and enum are mutually exclusive. The reason is analogous to the previous point.
• readOnly and writeOnly are mutually exclusive, because of their intrinsic logic.
• const and writeOnly are mutually exclusive, because a constant value cannot be written. Moreover, if const is used, readOnly is implied.

We understand that we are arbitrarily creating these rules, but without these constraints it will be necessary to validate conflicting data, making the process extremely ambiguous and unreliable. We really believe that a stricter specification is needed in order to guarantee interoperability across different implementations.