"" → OK
" " → ERROR
"snoopy" → ERROR
"http://example.org/dataset" → OK
"http://example.org/dataset#graph" → OK
"http://example.org/dataset" → OK
"http://example.org/dataset#graph?Aaa" → OK
"http://example.org/dataset%23graph" → ERROR

Any valid absolute IRI should be permitted, including other schemes than http/https, like urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66.

"http://example.org/dataset%23graph" → ERROR

I think this should be OK too, as IRIs serve as identifiers in this case and therefore the Simple String Comparison for equivalence apples. (But @afs probably knows for sure.)

Maybe better leaf it up to the back-end, as it already has sophisticated methods to check that?

Any valid absolute IRI should be permitted, including other schemes than http/https, like urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66.

Haven't tried on this PR, but a quick test on the browser console accepts "urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66" too.

new URL("urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66")
URL { href: "urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66", origin: "null", protocol: "urn:", username: "", password: "", host: "", hostname: "", port: "", pathname: "uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66", search: "" }

I think this should be OK too, as IRIs serve as identifiers in this case and therefore the Simple String Comparison for equivalence apples. (But @afs probably knows for sure.)

👍

Maybe better leaf it up to the back-end, as it already has sophisticated methods to check that?

In some other systems I've seen the UI sending a request to the backend to validate (e.g. Jenkins does that)... this way validation was only done in the backend, and the UI simply relied on the response being OK or NOK + the error explanation.

It's harder to test without the backend, and has an extra cost on the server, but could be a solution here too.
So that should pass the validation without issues.

Happy to implement either way. I think this new version at least improves the previous one. Not sure if there are some corner cases covered by the backend that are not handled correctly in JS though...

Thanks @jmkeil !

Not sure what would be the best solution. But the simplest solution I could think of would be to just do the request with the encoded graph name IRI and the back-end would complain, if it is invalid. Of course, that would have the draw back that the user might send a large payload only to learn about an invalid input. This could be avoided by sending a trial request with empty payload to test the graph name IRI. That way, no changes of the back-end are needed. Would that be feasible from the testing-perspective?

Would that be feasible from the testing-perspective?

I think that's doable too. Let's wait to see if @afs has other ideas or suggestions.

Thanks @jmkeil !