forked from albanm/node-libxml-xsd
-
Notifications
You must be signed in to change notification settings - Fork 0
/
readme.hbs
85 lines (55 loc) · 3.55 KB
/
readme.hbs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
node-libxml-xsd
===============
[![Build status](https://travis-ci.org/albanm/node-libxml-xsd.svg)](https://travis-ci.org/albanm/node-libxml-xsd)
[![Code Climate](https://codeclimate.com/github/albanm/node-libxml-xsd/badges/gpa.svg)](https://codeclimate.com/github/albanm/node-libxml-xsd)
[![NPM version](https://badge.fury.io/js/libxml-xsd.svg)](http://badge.fury.io/js/libxml-xsd)
*XSD validation for node.js using [libxml](http://xmlsoft.org/)*
Installation
------------
npm install libxml-xsd
On windows there are several prerequisites that need to be met before an install will work.
[Windows-Build-Tools](https://github.com/felixrieseberg/windows-build-tools) is a great helper module for this task.
npm install --global --production windows-build-tools
npm install libxml-xsd
Basic usage
-----------
```js
var xsd = require('libxml-xsd');
xsd.parseFile(schemaPath, function(err, schema){
schema.validate(documentString, function(err, validationErrors){
// err contains any technical error
// validationError is an array, null if the validation is ok
});
});
```
Libxmljs integration
--------------------
Node-libxml-xsd depends on [libxmljs](https://github.com/polotek/libxmljs/issues/226) that bundles libxml.
The libxmljs module required by node-libxml-xsd is exposed as ```require('libxml-xsd').libxmljs```. This prevents depending on libxmljs twice which is not optimal and source of weird bugs.
It is possible to work with libxmljs documents instead of strings as inputs to the *parse()* and *validate()* functions.
Imports and includes
--------------------
XSD includes are supported but relative paths must be given from the execution directory, usually the root of the project.
Includes are resolved when parsing the schema. Therefore the parsing task becomes IO bound, which is why you should not use synchronous parsing when you expect some includes.
Sync or async
-------------
The same *parse()* and *validate()* functions can be used in synchronous mode simply by removing the callback parameter.
In this case if a technical error occurs it will be thrown and validation errors will be returned.
```js
var xsd = require('libxml-xsd');
var schema = xsd.parse(schemaString);
var validationErrors = schema.validate(documentString);
```
The asynchronous functions use the [libuv work queue](http://nikhilm.github.io/uvbook/threads.html#libuv-work-queue)
to provide parallelized computation in node.js worker threads. This makes it non-blocking for the main event loop of node.js.
Note that libxmljs parsing doesn't use the work queue, so only a part of the process is actually parallelized.
The tasks being mostly CPU bound and very fast it is not a big problem to use synchronous mode.
But remember that if you use some includes the parsing task becomes IO bound.
Environment compatibility
-------------------------
For now 64bits linux and 32bits windows are confirmed. Other environments are probably ok, but not checked. Please report an issue if you encounter some difficulties.
Node-libxml-xsd depends on [node-gyp](https://github.com/TooTallNate/node-gyp), you will need to meet its requirements. This can be a bit painful mostly for windows users. The node-gyp version bundled in your npm will have to be greater than 0.13.0, so you might have to follow [these instructions to upgrade](https://github.com/TooTallNate/node-gyp/wiki/Updating-npm's-bundled-node-gyp). There is no system dependancy otherwise as libxml is bundled by libxmljs.
API Reference
=============
{{>main}}
*documented by [jsdoc-to-markdown](https://github.com/75lb/jsdoc-to-markdown)*.