Re: ISSUE-211: Should we turn sh:property and sh:sparql into constraint components?

I have meanwhile created a branch that implements the change described 
below, and the definitions are now more consistent.

The branch can be compared to the base at

     https://github.com/w3c/data-shapes/compare/restructuring

The diff looks scary on GitHub because it also includes the other 
restructuring that I had indicated in the meeting. The terminology is 
now consistently using

- constraint: any condition
- constraint component: parameters of a constraint
- shape: a constraint that is about focus nodes
- property constraint: a constraint that is about a property at a focus node

and the flow of section 2 starts with the commonalities of all 
constraints before talking about the differences between shapes and 
property constraints. While doing this restructuring I mostly just moved 
existing text around without invalidating what was already painfully 
reviewed and refined before.

On this branch I did make a change that should clarify the various 
corner cases that were previously pointed out (by Peter among others): 
Now, a shapes graph is ill-formed if it contains any ill-formed node. A 
constraint is ill-formed if it has more than one constraint type, i.e. 
shapes and property constraints are *disjoint*. And property constraints 
are now clearly identifies by incoming sh:property links. Then, the 
definition of validation states that if an ill-formed shapes graph is 
encountered, then the result is undefined and some implementations MAY 
produce a failure. In Peter's proposal ill-defined shapes graphs always 
cause failures but I believe the working group had discussed this before 
and concluded that this would require too much overhead from an 
implementation to walk through all syntax rules. I am open to changing 
this policy though if people feel differently now.

Other changes on this branch are general improvements and clean up. I 
have not yet had the time to compare with the definitions from Peter's 
draft for potential reuse.

My suggestion is to move this branch into production, but I need some 
feedback before doing this. @Dimitris, in case you plan any edits, I 
leave it to your judgement whether you want to continue on that branch 
to simplify merging later. I hope you agree this new structure is better 
than what we had before, even if only a step in the right direction.

Thanks,
Holger

PS: I will be traveling from tomorrow onwards yet I will try to be on 
the Wednesday WG call, if that happens.


On 16/12/2016 13:29, Holger Knublauch wrote:
> One aspect where the design proposed by Dimitris is nicer is that 
> everything is uniformly treated as a constraint component. So not only 
> sh:minCount is backed by a constraint component but also sh:property 
> and sh:sparql. I think this would be a worthwhile way of defining them 
> and the cost of this change is low. I cannot think of changes this 
> would have for users.
>
> So basically, the new sh:PropertyConstraintComponent would be defined 
> to perform validation of the focus node against all property 
> constraints (the values of sh:property). All resulting validation 
> results would be copied into the results graph. (This is BTW different 
> from sh:shape, where the nested results are *not* becoming top-level 
> results but only values for sh:detail).
>
> And sh:SPARQLConstraintComponent would be defined to execute the given 
> SPARQL query and use the resulting validation results.
>
> After this change, we can simplify the definition of validation to be 
> about all components of the given constraint.
>
> How does this sound (as a belated compromise)?
>
> (I did not raise a formal issue yet but if there is support then we 
> can for example make an addendum to the resolution of ISSUE-211).
>
> Holger
>

Received on Saturday, 17 December 2016 03:07:27 UTC