Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long lists in results #131

Closed
giacomociti opened this issue Apr 15, 2024 · 6 comments
Closed

long lists in results #131

giacomociti opened this issue Apr 15, 2024 · 6 comments

Comments

@giacomociti
Copy link
Contributor

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
Copy link
Collaborator

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

@giacomociti
Copy link
Contributor Author

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
Copy link
Collaborator

tpluscode commented Apr 15, 2024

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
Copy link
Contributor Author

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
Copy link
Collaborator

tpluscode commented Apr 17, 2024

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
Copy link
Contributor Author

the issue should be addressed by #129

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants