long lists in results

[giacomociti]

A shape with a long list, for example this one in the playground, validates with no problems. But as soon as you make the data graph invalid (try in the example setting zero in the data graph), the library throws a 'Maximum call stack size exceeded' trying to clone the whole shape in the result.

I think in this function we should somehow limit the amount of data to be copied in the report.

[tpluscode]

Do we even need the full list copied to the report?

[giacomociti]

I think there's no such requirement in the spec. Still, when the source shape is a blank node, I find it useful to provide a concise description. But to make it really concise, we should either shorten, empty or remove lists. I think a reasonable balance of perf and information depends also on the associated error message. If we merge this proposal, we would have at least a few list items in the message and we may get rid of the list in the sourceShape

[tpluscode]

Re #129, I was also thinking to propose a configuration option where you'd define how many items of a list to keep (might default to 3 but maybe a little higher too)

Then, maybe you'd use the same limit when copying the list to the report, adding a note like

_:report a sh:ValidationReport ;
    sh:result [
        rdf:type sh:ValidationResult ;
        sh:resultSeverity sh:Violation ;
        sh:sourceConstraintComponent sh:InConstraintComponent ;
        sh:sourceShape [
            sh:path <http://example.org/number> ;
            sh:in ( 1 2 3 ) ;
+                       rdfs:comment "4997 elements removed from the report for brevity. Please refer the original shape" ;
        ] ;
        sh:focusNode <http://example.org/foo> ;
        sh:resultPath <http://example.org/number> ;
        sh:value 0 ;
        sh:resultMessage "Value is not one of the allowed values: 1, 2, 3 (and 4997 more)" ;
    ] ;
    sh:conforms false .

sh:Violation a sh:Severity .

[giacomociti]

I like the rdfs:comment. I'm not convinced about sh:in ( 1 2 3 ), maybe we could omit it because the sh:resultMessage is enough as a quick reminder of the allowed values

[tpluscode]

Then the comment would need to be simplified as sh:in has been removed from the report for brevity. Please refer the original shape

[giacomociti]

the issue should be addressed by #129