I feel the problem is the same.
The issue is just that the resolver for imports and includes (both XSD and XSL) in BaseX seems not being able to resolve relative uris. We fixed temporarely by creating a folder with all schemas and stylesheets locally to the BazeX dist folder and transforming all imports/include uris to absolute. This is quite annoying and it becomes difficult when dealing with multiple deployment sites and we try to come around with entity references but anyway in my op it's not safe to fiddle on xsd, wsdls and xslt that come with they'r own (relative uri based) linking architecture.
Actually the resolver seems to work with relative uris only if they are "file:" uris and expressed relatively to the folder from where you launched BaseX itself.
Saxon and JAXP reference impl do it right I can validate from Java (or Linux command line) even with XSDs that are downloaded from the net and link other files relatively to the remote URIs.
As a final remark if I ask for the explicit resolution with resolve-uri("importedfile.xsd", base-uri(doc(importingfile.xsd))) the returned URI is correct. I get the proper absolute URI of the imported schema file. So it really looks like in the backoffice of validate/transform functions the resolver is mismatching something.
Hope that my two cents can help out.
Greetings,
M.

On 01/28/2013 10:00 PM, Wendell Piez wrote:

Hi, I've run into a similar problem to the one described (I think) below: I can invoke XSLT in BaseX (fantastic) but I get compiler errors if the stylesheet relies on xsl:import or xsl:include (not so good). As I understand it, the JAXP interface (supported by Saxon and Xalan) allows you to provide your own URIResolver class, which is (I imagine) the way to fix this. But I'm no Java programmer. It would be very (very) nice to be able to do this right. My apologies if this post is no help but only a "me too". :-) Cheers, Wendell On Fri, Jan 25, 2013 at 4:41 PM, Christian Grün <christian.gruen@gmail.com> wrote:

Yes, I see this is a problem, and I’ve encountered similar use cases, but I'm currently not sure how to fix this properly. The issue is that BaseX relies on external schema validation, so we don’t have direct access to the code executing the validation. It could well be that Java’s validator interface provides some methods to set/modify the path to the current base uri. If you – or someone else – has time, ideas and/or experience how to fix this, suggestions and patches are welcome (see [1] for the source code).

A similar observation applies here: the error handling in the mentioned class could be revised in order to catch more than just the first error [2]. Feel free to ask if you have more questions, Christian [1] https://github.com/BaseXdb/basex/blob/master/src/main/java/org/basex/query/func/FNValidate.java#L95 [2] https://github.com/BaseXdb/basex/blob/master/src/main/java/org/basex/query/func/FNValidate.java#L183 _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

-- Wendell Piez | http://www.wendellpiez.com XML | XSLT | electronic publishing Eat Your Vegetables _____oo_________o_o___ooooo____ooooooo_^ _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk