Editorial clean up around constraints


I recently worked on some cleaning up of Sections 2.3 and 3. The 
constraint properties such as sh:class were previously only defined in 
the direction of property constraints, but this is now generalized so 
that the same definitions can also be used in other contexts, such as 
when used as inverse property constraints or node constraint.

Notable changes include:

- Introduced the term "Constraint Component" to talk about a property or 
group of properties that are used together in a constraint. Examples 
include the component of sh:class or the component of sh:pattern + 
sh:flags. I borrowed this term from Peter's proposal and thank him for 
that (I previously used "constraint type" for the same concept, but 
never liked it; Proposal 3 has been updated accordingly).

- Introduced the term "value node" to refer to the nodes produced by 
property constraints, inverse property constraints or node constraints. 
See beginning of Section 3 for definitions.

- That term made many definitions much simpler, because we no longer 
need to repeat the rules on how to retrieve the values and how to 
construct validation results.

- Section 3 has been reorganized so that semantically related constraint 
components have been grouped together. We now have subsections for value 
types, cardinalities, value ranges, string-based constraints, property 
pair constraints, logical constraints, shape-based constraints and "others".

- Only section 3.1 is consistently refactored to the new format yet - I 
wanted to collect feedback before I go further. I hope nobody objects to 
this long-overdue clean-up, so I'll probably continue, time permitting :)

Latest version (as usual): http://w3c.github.io/data-shapes/shacl/

Notable diff: 


Received on Tuesday, 22 March 2016 01:43:59 UTC