ISSUE-41: Suggested results and validator vocabulary changes

As a status update, I am still in the process of implementing ISSUE-41. 
This is quite time consuming because it causes a number of follow-up 
changes that in turn cause test cases to break etc. While I have updated 
the implementation and tests, I have not yet had time to update the spec 
or to experiment with further optimizations such as merging validators. 
I am also busy with lots of other (paid) work this week.

Meanwhile I have committed the updated vocabulary file (TTL) to a branch

     https://github.com/w3c/data-shapes/tree/ISSUE-41

One of the changes that followed logically was a generalization of the 
results vocabulary. Currently we have

- sh:focusNode
- sh:subject
- sh:predicate
- sh:object

focusNode and subject (for property constraints) and object (for inv 
prop constraints) are usually the same node anyway. sh:predicate only 
changes "direction" depending on the context. Given that we now would 
also have paths, this whole approach no longer seems to make sense.

My suggestion is to drop sh:subject/predicate/object and instead only have

- sh:focusNode ($this)
- sh:path
- sh:value (?value)

sh:focusNode and sh:path can be auto-populated, simplifying the SELECT 
clauses of the various validators.

The other change I have started on the branch is to merge the validator 
properties. Currently we have sh:nodeValidator, sh:propertyValidator and 
sh:inversePropertyValidator. While we could theoretically add 
sh:pathValidator, we also want the ability to have a single (default) 
validator. So the suggested design only has a unified property called 
sh:validator and each validator instance can point to its context via a 
property sh:constraintType (sh:PropertyConstraint etc). Then, validators 
for PathConstraints can also be used for PropertyConstraints, and if no 
constraintType is specified then it will be the default validator. This 
approach seems to provide great code reuse while still keeping the 
flexibility to overload and optimize queries for certain cases, i.e. the 
best of both worlds.

Does anyone see problems so far? Could someone (Dimitris?) confirm that 
this is in the right direction? (I need to know because all these pieces 
now belong together and need to be refactored together. In the interest 
of making progress I would prefer not to have to go through a formal 
ISSUE tracker process for these vocabulary changes).

Thanks,
Holger

Received on Tuesday, 14 June 2016 02:10:24 UTC