Check data schema algorithm and strings

[relu91]

This issue is derived from my review in #239. I saw that the check data schema algorithm does not perform any check if that DataSchema is equal to string. In principle, I can understand why: any value in JS can be represented in a string. However, I wonder if a more strict check may make life easier for application developers.

Following, the algorithm a property with string data schema can even return something like the following:

{
   "name":"Jhon",
   // .... other properties
}

Consequently, WoT developers should inspect beforehand if that property was mistakenly represented as a string while is actually an object. If we strictly check the type in the check data schema algorithm we mitigate this type of errors, while also maintaining the ability to return an object serialized as a string:

"{ 'name':'Jhon', // .... other properties }"

[zolkis]

This as the other side as well: what if the developer intention was to convey an object as string?
However, implementations should check strings for security reasons and we need some guidance on that.

[relu91]

This as the other side as well: what if the developer intention was to convey an object as string?

As I said, we'll still be able to cover this use-case. For example, nothing stops the dev to return this "{ 'name':'Jhon', // .... other properties }" as a string.

[danielpeintner]

I wonder whether the check data schema algorithm can be simplified as a whole, not only for string.

At the moment we try to rudimentary describe what a JSON schema validator should do. In fact we could simplify the whole prose saying that the data schema provided should be checked against the payload.

Do you think doing so would provide to much burden on some implementations?

An alternative would be that we require that any processor must at least check the requirements written the check data schema algorithm section but it is encouraged to do a proper JSON schema check...