Our experience shows that delivery on a web server with a WAR file doesn't easily allow for write-access to the file system.

I created a function that resolves the includes recursively and returns the full .xsd, then I send that new node to validate:xsd.

Seems to resolve the issue for now.

Regards,

France

On Wed, Jul 17, 2013 at 7:31 AM, Christian Grün <christian.gruen@gmail.com> wrote:

Hi France,

thanks, the example was helpful. As we use standard Java code to
validate XML documents, the validation process can only access
retrieve documents from default URLs. If the URL is relative, it will
be resolved from the current working directory Java has been started
from.

However, one solution is to temporarily write the relevant database
files to disk before validating the document, and removing them again
after the process. The attached TestXsd.xqm file indicates how this
can be done.

If you want to avoid spamming your current working directory, you can
also write all files to a temporary directory. In this case, you’ll
also have to update the schema locations in the specified schema file.
TestXsd-temp.xqm presents a solution for this alternative.

I agree that it would feel more elegant if validation would
exclusively work on database resources, but at least I’m quite sure
that the proposed shouldn’t introduce any remarkable slowdown.

> NOTE: When I look at the file in BaseX GUI, I see the .xsd file

> renamed as lower caps [...]

True; we have an open issue in our bug tracker that addresses this
inconsistency [1]. We hope to get it fixed until the final 7.7 release
(which is planned to be aligned with this year’s Balisage Conference
in Montréal… ;).

Christian

[1] https://github.com/BaseXdb/basex/issues/564

--
France Baril
Architecte documentaire / Documentation architect
france.baril@architextus.com
(514) 572-0341