-
Notifications
You must be signed in to change notification settings - Fork 28
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
Module fails when importing an external XSD #11
Comments
I'm seeing this error too |
Hi @TrevorMW,
And this works fine, xsd is loaded with imports. Dirty example code: var xsd = require('libxml-xsd');
var path = require('path');
var initialCWD = path.resolve(''); //keeping that to put it back afterwards
process.chdir(path.resolve(__dirname, '../../resources')); //this changes cwd for a directory where I put a metadata.xsd and xml.xsd. metadata.xsd includes xml.xsd
xsd.parseFile(path.resolve('./metadata.xsd'), function (err, schema) {
if (err) {
console.log(err);
return;
}
console.log('loaded');
process.chdir(initialCWD); //getting cwd back
schema.validateFile(path.resolve(__dirname, '../../test/metadata-export-20160825.xml'), function(err, validationErrors){
if (err) {
console.log(err);
return;
}
if (validationErrors){
console.log(validationErrors);
return;
}
});
}); What can cause issues is that changing cwd while performing async operations can induce path-related race conditions. If any code relying on cwd executes between xsd.parseFile and its callback execution, things can break (assuming it's really async). A solution may be to delegate the validation code to a separate process. |
+1 for changing this behavior to follow XSD specs, not custom quirck. PLEASE IMHO: This is incorrect and unexpected: XSD includes are supported but relative paths must be given from the execution directory, usually the root of the project. |
Hi guys, same problem here... |
The motivation for this change was to correct the behavior of XSD includes/imports (Issue albanm#11). Paths to included schemas should be resolved relative to the XSD file, not the execution directory. This was only a problem for the top level XSD - nested includes were resolved relative to the files that included them. Setting the `baseUrl` option to the path of the top level XSD file fixes the unexpected behavior. Tests have been updated so that they work with includes relative to the schema files.
This test schema fails at this line
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd" />
while trying to load, and emits warnings and errors like this
I/O warning : failed to load external entity "xml.xsd"
and
Schemas parser error : attribute use (unknown), attribute 'ref': The QName value '{http://www.w3.org/XML/1998/namespace}lang'
From what I can gather it has something to do with the library not being able to pull in the correct xml:lang definition correctly, possibly due to throttling by the w3c??
any suggestions?
The text was updated successfully, but these errors were encountered: