David Maus

This also does not work for BaseX: I can import the pipeline-for-svrl.xsl, BaseX seems to properly resolve the imported compile/compile-2.0.xsl but does lookup the result as another import-uri.

```xquery version "3.1"; import module namespace schxslt = "https://doi.org/10.5281/zenodo.1495494"; let $document := let $schema := Always true let $stylesheet := return xslt:transform($schema, $stylesheet) ```

Thus: - I don't provide a import-uri - I don't provide a way to customize the report unless someone asks for it Alternative: - Provide import-uri include, expand, compile but...

...but that doesn'nt solve the problem. I also need to provide ```schxslt:resolve-compiler-uri($queryBinding as xs:string) as xs:string```.

Postponed. For a casual user of eXist it is way to fiddly.

This is a deliberate choice. It appears to be a common usage pattern.

This might be a problem with [schxslt/schxslt-java](https://github.com/schxslt/schxslt-java)'s Resolver implementation.

Yes, resolving the URIs relative to the source document makes sense. To be exact: Currently SchXslt resolves the URIs relative to the validation stylesheets location.

This sounds useful and is (I think) related to #75 -- At least in that we need to finde a way to stop validation and return a result. That is:...

Turns out this is not easy to do in XSLT for n > 1. I could see this implemented in a commandline or web application using a processor specific custom...