Support validation of input files

[GoogleCodeExporter]

Hi there, 
According to [1], currently, docbkx doesn't validate input documents. The 
message at [1] suggests either using a separate validation plugin or doing it 
via ant in a preProcess step. Neither of these seem attractive and both would 
bloat each doc projects's pom with logic that is generic to all documents. 

By default (but with some way to disable it) docbkx should validate the 
document before it attempts to build it.

The validation should probably come AFTER preProcess in case preProcess builds 
bits of the doc that should be there in order for it to be valid.

[1] 
https://groups.google.com/group/docbkx-tools-users/browse_thread/thread/6d0376d7
987149a0/d897a63bc40ed1e8?lnk=gst&q=validate#d897a63bc40ed1e8

Original issue reported on code.google.com by crame...@gmail.com on 24 Mar 2011 at 9:29

[GoogleCodeExporter]

it is maybe not too hard to implement, here is a good link 
(http://www.edankert.com/validate.html)
) talking about the different parser implementations (we are using 2 of them in 
the plugin)

Original comment by MimilO...@gmail.com on 25 Mar 2011 at 7:26

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

That talks about xsd and dtd...does it include RelaxNG? (I've only glanced at 
it). We'd want to validate against the DocBook RelaxNG schema and ideally have 
the option of validating against embedded schematron rules too. I believe nvdl 
(e.g. http://jnvdl.sourceforge.net/ ) does that. 

Another detail to consider is that some users will use a DocBook variant, so 
there has to be a way to specify a customized version of the DocBook schema in 
the same way it does now with the xslts.

Thanks,
David

Original comment by crame...@gmail.com on 25 Mar 2011 at 11:07

[GoogleCodeExporter]

Looking at jing-trang, there are open issues both to support nvdl and mavenize 
the project, though the mavenize one is ranked low priority :-(

https://code.google.com/p/jing-trang/issues/list

David

Original comment by crame...@gmail.com on 25 Mar 2011 at 11:16

[GoogleCodeExporter]

How do you imagine this feature?
- a specific maven goal? (with its specific settings)
-- this can be runned without the processing phase
-- this duplicates the file source set (maybe some users want to have different 
file set?)
- an additionnal parameter (validate -> true/false) into the generate-* goals?
--  if we need to add parameters for the validation, the settings section may 
become ugly
- stop the goal at the first invalid file or list all invalid files with all 
errors?

What will be validated?
- the generated book/article (the file with the XInclude already resolved and 
dumped)
-- the simplest way to do it (imho), but the errors can be difficult to read by 
the user (how to report the original line number, etc)
- each source file?
-- the best way to do it from the user point of view (imho)

By the way, i looked through the code to the XInclude part ; since xom seems to 
be a compile depedency, why do not always use xom? why fallback to the Xerces 
impl?

Regards

Original comment by vincent....@gmail.com on 5 Nov 2013 at 7:36