Add formal validation process

[mmccool]

Both discovery and scripting (for Partial TDs) need a "formal validation" of TDs (and Partial TDs) that they are passed.
It would be better if the (minimum) validation process was defined clearly and formally in one place, and IMO that should be in the TD spec.

At the very least the validation should be against the JSON Schema (although there is the ongoing annoyance that JSON Schemas are not formal specs...).

See

• Define requirements and add section for validation wot-discovery#99
• Consider to add one or more validation steps to assure TD consistency wot-scripting-api#238

[relu91]

Related also to partial TD validation:
w3c/wot-scripting-api#287
w3c/wot-scripting-api#289

[egekorkan]

Btw, playground has some additional checks at https://github.com/thingweb/thingweb-playground/blob/master/packages/core/shared.js

These are actual things that need to be checked but cannot be done with a JSON Schema.

[mmccool]

My proposal (from the F2F, in my presentation, slide 6):

Define "Syntactic Validation":

• Define a subset of assertions that can be validated just by using JSON Schema (we already know this subset)
• This does not cover extensions, since the spec and JSON Schema also allow for random additional properties... however, we can define this to be exactly equivalent to what is checked by JSON Schema without actually depending on it formally.
• When/If JSON Schema becomes an actual standard, we can swap it in as a normative spec. In the meantime we can mentioned (informally) that JSON Schema checking can be used in practice to check the set of assertions we identify. To actually identify all the assertions though we might have to put some kind of marker on them (e.g. "(syntactic)").
• For directories this form of validation would be MANDATORY
• Probably need to include the additional checks that Ege mentions somewhere too. Maybe we list these checks explictly in the spec?

Define "Semantic Validation":

• Based on SHACL... which we should actually provide formally, and unlike JSON Schema it IS a standard, and so we can use it normatively.
• Can be used by directories supporting semantic queries; these can also validate extensions if the SHACL can be accessed
  (TD SHACL also needs to be fetchable).
• For directories, this form of validation would be OPTIONAL in general, but MANDATORY for those that
  do SPARQL.
• We would have to tag all assertions that can be checked this way (e.g. with "(semantic)").

Note there will probably be a number of assertions that can't be checked by either mechanism, e.g. behavioural assertions. These can just be unlabelled.

[mmccool]

(Discussed in the F2F):

Checking for "required" elements defined in a TM would be useful, but requires fetching the TM, which might be a privacy risk. So when we define validation formally, perhaps this could be under "extended validation", which should only be applied in contexts where privacy is not an issue (e.g. during development, but not in deployment). Similar issues arise for validating extensions (e.g. semantic extensions, etc.; for example, by fetching SHACL definitions or JSON Schemas associated with extensions).

[mmccool]

BTW this also means the "type" relation pointing at TMs should be to a "fixed" URL, since we will consider things with the same URL to be the same "type" and things with different URLs to be different. The expectation is that non-development systems, i.e. gateways, would "know" a set of TM URLs and would not have to fetch them. This also implies though that directory validators (a service running in gateways/hubs...) would not normally fetch TMs to validate this, but it might be recommended as a "extra" validation step during development.

[takuki]

The issue was taken care of by PR #1085.
@mmccool is going to create another issue for remaining improvements.