Using full version of jing with NVDL support

[LdBeth]

following #238

The NVDL validation would work transparently by setting relax-ng-grammar to the NVDL file if replacing the docbook-xslTNG-1.11.1/libs/lib/jing-20220510.jar by the jar available from the official jing release https://github.com/relaxng/jing-trang/releases/tag/V20220510

@ndw Could you consider shipping the full version of jing with Schematron and NVDL capability with DocBook xslTNG?

And maybe change the name relax-ng-grammar to something more suggestive, since NVDL or Schematron will also be an option.

[LdBeth]

Well I guess one reason for not including Schematron from jing is because it is still using XSLT 1.0 for validation.

[ndw]

Curiously, I seem to have lost docbook-xslTNG-x.y.z.zip from the release starting in 1.11.2. I'll need to fix that.

But I thought jing-20220510.jar in the distribution was the same as the official version. On casual inspection, I don't see how they differ. What am I missing?

[ndw]

Hmm. Apparently it's just the 1.11.2 release that's missing the distribution zip file. Huh. Not going to worry about that now, I guess.

[LdBeth]

Well I didn't find 1.11.2 distribution so was still using 1.11.1, I guess it was only the XSLT file got updated?

A simple comparison by diff shows they are not the same jar:

Binary files ../../../jing-20220510/bin/jing.jar and jing-20220510.jar.bak differ

What I exactly did was symlink the jing.jar to jing-20220510.jar, which could affect how the dependences are resolved.

[ndw]

The jar's differ, but when I unpacked them and compared the content, they seemed the same. I assume jar metadata could be different. I believe the jar I'm including is one that I got from Maven for the 20220510 Maven release.

[ndw]

I've confirmed that the version in the distribution is exactly the version distributed by Maven for jing-20220510: https://repo1.maven.org/maven2/org/relaxng/jing/20220510/

I think that's the same as the version you identified on GitHub except that it was probably constructed by two different jar commands over the same .class files.

I think that resolves this issue. If you disagree, please reopen it.

[LdBeth]

Umm, the jar shipped with distribution also works for validation inside docbook-xslTNG, the only difference is the jar shipped with xslTNG cannot be used to validate with NVDL as a command line program while the GitHub distributed one can, which caused my wrong impression, and it seems due to the xml-apis.jar version difference.

I agree that this issue is resolved. Thanks for spending time investigate.

[ndw]

The weird inconsistencies in different versions of xml-apis.jar freak me out a bit. I'll see if I can use the same one that the GitHub distribution of trang uses. If we randomly picked two different versions, I expect there's no reason we can't randomly pick the same version!

[LdBeth]

The error I got was:

$ java -jar ../docbook-xslTNG-1.11.1/libs/lib/jing-20220510.jar ../docbook-5.2/dbk.nvdl lab-color.dbk
fatal: exception "java.lang.IllegalAccessException" thrown: java.lang.IllegalAccessException: class com.thaiopensource.validate.schematron.ISOSchemaReaderImpl cannot access class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl (in module java.xml) because module java.xml does not export com.sun.org.apache.xalan.internal.xsltc.trax to unnamed module @4a499116: class com.thaiopensource.validate.schematron.ISOSchemaReaderImpl cannot access class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl (in module java.xml) because module java.xml does not export com.sun.org.apache.xalan.internal.xsltc.trax to unnamed module @4a499116

It seems more like an issue on how the java modules are packaged, rather than the version difference I previously suspected.

[ndw]

For some reason the Sun copies of the Xalan classes are getting instantiated to do the transformation. It might be possible to get the right thing to happen (or a better thing) with some system property or another, but it's been a loooong time since I thought about that.

[ndw]

Curiously, I can't reproduce this:

$ java -jar /tmp/docbook-xslTNG-1.11.1/libs/lib/jing-20220510.jar ../docbook/build/stage/docbook-5.2CR5/docbook.nvdl test.xml
ERROR:  'Namespace for prefix 'db' has not been declared.'
fatal: exception "java.lang.RuntimeException" thrown: Namespace for prefix 'db' has not been declared.

Where that copy of docbook.nvdl is:

<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
       startMode="docbook">

<mode name="docbook">
  <namespace ns="http://docbook.org/ns/docbook">
    <validate schema="rng/docbook.rng" useMode="attach"/>
    <validate schema="sch/docbook.sch" useMode="attach"/>
  </namespace>
</mode>

<mode name="attach">
  <anyNamespace>
    <attach/>
  </anyNamespace>
</mode>

</rules>

The problem about the namespace prefix db is related to the schematron file. If I take the Schematron validation out of the NVDL file, it passes fine. The Schematron file begins:

<s:schema xmlns:db="http://docbook.org/ns/docbook"
          xmlns:rng="http://relaxng.org/ns/structure/1.0"
          xmlns:s="http://purl.oclc.org/dsdl/schematron"
          queryBinding="xslt2">
   <s:ns prefix="db" uri="http://docbook.org/ns/docbook"/>
   <s:ns prefix="xlink" uri="http://www.w3.org/1999/xlink"/>
   <s:ns prefix="trans" uri="http://docbook.org/ns/transclusion"/>
   <s:pattern>
   ...

That looks like it has the db prefix defined. I'm guessing that Jing doesn't recognize http://purl.oclc.org/dsdl/schematron as the Schematron namespace, maybe? Or maybe the queryBinding xslt2 confuses it?

Hard to say, but I don't see any evidence that it's a bug in the stylesheet distribution or a bug that I could workaround by calling things diffrently.

I'm inclined to close this bug again, but let me know if you're still working on it.

See also: https://so.nwalsh.com/2023/02/17-xml-apis

[LdBeth]

I think this issue can be closed, since it turns to be site specific configuration related.