Check data schema algorithm handle string DataSchema new fields.

[relu91]

In the next TD release, string DataSchema will contain also those four new properties (see https://github.com/w3c/wot-thing-description/pull/896):

1. minLength
2. maxLength
3. contentEncoding
4. contentMediaType

Should we take that into account?

Derived from #239

[egekorkan]

Just a small point, multipleOf will be for number and integer.

[relu91]

Thanks! updated 👍

[zolkis]

In don't like the names contentEncoding and contentMediaType, as in the Web Platform APIs the simple names encoding and mediaType refer to content and are already standard.

[danielpeintner]

In the next TD release, string DataSchema will contain also those four new properties (see w3c/wot-thing-description#896):

I wonder whether we can get away with some more generic statements that data should be checked/validated against the given dataSchema instead of trying to keep up with any addition that gets added in the TD spec.

[egekorkan]

These terms are from JSON Schema tough

[danielpeintner]

Coming back to the discussion whether a WoT runtime should or can check data it reports.

I wonder whether technically this can be guaranteed. The data may come from sources/bindings the runtime does not have enough knowledge. I mean a WOT runtime can do its best to check according to the provided data but a plugged in binding with a fancy data representation is simple not checkable by the runtime.

e.g., node-wot allows you to plugin in any binding. The data, its format et cetera is opaque to the node-wot runtime. How can I check CBOR/EXI/XYZ data if I don't even have the necessary parser.

Also in the plain JSON case I wonder whether we want to require regex parsers etc.

[egekorkan]

So for the plain JSON case, a library like ajv works really well for the validation like seen here: https://github.com/eclipse/thingweb.node-wot/blob/4e8852420b6da137bd460f3a1c83d4ce1b1593fc/examples/templates/exposed-thing/src/base.ts#L126

Regarding the fancy binding, that binding should do at least basic validation, like checking that it is indeed CBOR/EXI/XYZ. This should be required I would say. If we want to make it more complicated ( :blush: ), we can think of something like the ContentSerdes of node-wot but for validators.

[relu91]

In my mind, if there is a DataSchema defined the protocol binding is required to provide that data as a JavaScript object. Later the runtime can check it using ajv as @egekorkan mentioned above. Of course the protocol binding might fail, (i.e. it does not have an implementation to parse CBOR or the data was actually an image/png). Some exotic protocols might just exchange bytes and be totally opache. In that case TD designer should be aware of this limitation and do not define a DataSchema for that Web Thing (or for some of its affordances).

I recall that in the node-wot modbus implementation the only form contentType accepted for DataSchema traslation is application/octet-stream. Not only, the DataSchema should be an ArrayDataSchema; all the other will fail to parse.

[danielpeintner]

Isn't this somewhat related to (same as?) https://github.com/w3c/wot-scripting-api/issues/240 ?