Linux command line tool validating XSD 1.1? - command-line

Is there any command line tool that validates XML against a XSD version 1.1?
Xmllint does not validate version 1.1.

I found a handy wrapper around Xerces-J: https://www.dropbox.com/s/939jv39ihnluem0/xsd11-validator.jar
java -jar xsd11-validator.jar -sf my.xsd -if my.xml
You can update the Xerces-J lib by unzipping the jar, dropping the new Xerces-J in it, then rezipping it to a jar
Reference
Edit: Updated download link

XSD 1.1 is currently supported by Saxon and by Xerces J. Both should run without trouble under Linux.

xmllint unfortunately could not support XML Schema 1.1 but alternatively it supports RelaxNG based Schema (including all the advancements similar to the XML Schema 1.1).
Following is the procedure could be used to overcome xmllint limitations:
implement your validation XML Schema version 1.1 based on Oxygen Editor reverse generator (based on already existing XML files).
it could be downloaded from here with the 1 month license free
resulting XSD 1.1 file will not be accepted by xmllint with the following error messages:
xmllint --schema user.xsd --noout user.xml
user.xsd:565: element element: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}element': Invalid value for maxOccurs (must be 0 or 1).
user.xsd:741: element element: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}element': Invalid value for maxOccurs (must be 0 or 1).
WXS schema user.xsd failed to compile
however the xml schema could be converted into relaxng schema with the help of RNGConv tool which is a part of the Kohsuke Kawaguchi's MSV project by
applying following conversion command:
java -jar rngconv-20060319/rngconv.jar user.xsd > user.rng
resulting relaxng schema file could be used with the xmllint:
xmllint --relaxng user.rng --noout user.xml
user.xml validates

I answered this question over here at AskUbuntu.
It includes working links to the Xerces-J wrapper xsd11-validator.jar and a comfortable bash script for easy usage.

Related

SchemaCrawler 16.12 version command line not creating my htmlx output

I am using the latest version of schemacrawler (16.1.2) to generate SVG diagrams embedded in HTML output. However it is not creating the diagrams but only printing the table information in text form. If I use an older version of schemacrawler, it works fine. I have Graphviz installed on my machine. What am I doing wrong that is not outputting the diagram?
For Version 16.1.2 this version of the command line I use is not working
source schemacrawler.sh --server=postgresql --host=hostname --database=db_name --user=username --password=password_name --info-level=standard --schemas=schema_name --command=schema --outputformat=htmlx --log-level=CONFIG > schemaGraph.html
For Version 14.17, this version of the command works fine for me
source schemacrawler.sh -server=postgresql -host=hostname -database=db_name -user=username -password=password_name -infolevel=minimum -command=schema -outputformat=htmlx -loglevel=CONFIG > schemaGraph.html
Please try --output-format and see if it works.

False positive "Missing include" xslt error in eclipse

I have an xslt file in my eclipse project.
The xslt is run using a custom processor, which contains some xslt files as an in-jar resource. The xslt linter does not see those resources, and signals an error.
The offending line in the xslt code:
<xsl:include href="xslt/functions.xslt"/>
The error message:
Missing include: xslt/functions.xslt
I guess that the xslt path for the linter is somehow configureable, but cannot find where and how.
Where and how?
If using the Eclipse XSL Editor (there are also other XSLT editors for Eclipse):
Window > Preferences: XML > XSL > Validation
or on project level:
Project > Properties: Validation > XSLT Validation
It is possible with the XML-Catalog-function "Rewrite Entry" and the imports having a prefix which identifies the folder you want to take the import from.
Window > Preferences : XML > XML Catalog > Rewrite Entry
You have to provide a URI key type and the prefix of the href-value.
Rewrite it with a "file://xxxx" value and the import gets resolved.
Example:
<xsl:include href="imp://xslt/functions.xslt"/>
catalog-rewrite-entry for eclipse
Entry element: Rewrite
Start string: imp://
Rewrite prefix: file:///home/xxx/project/importfolder
Key type: URI

calling XQuery Update from the command line after update to oXygen 17.1

We have for the past year been running a batch script I wrote to call a series of XQuery Updates from the Windows command line using Saxon. It worked fine while we were on oXygen 16, but after all the machines in our department were upgraded to oXygen 17.1, the script is now throwing an error that I can't seem to fix. Any thoughts would be greatly appreciated.
This used to work when oXygen 16 was installed:
java -cp "C:\Program Files\Oxygen XML Editor 16\lib\saxon9ee.jar" net.sf.saxon.Query -update:on -t -q:"C:\Users\%USERNAME%\Documents\SVN Working Copies\trunk\rbscXSL\Locations2015\AbID2dsc-items.xq"
I have confirmed that the .jar file is in the same relative location (with the oXygen version number being the only change to the path) and has the same name as before. Nevertheless, after updating the class path to "C:\Program Files\Oxygen XML Editor 17\lib\saxon9ee.jar" the script throws the following error:
Saxon-EE 9.6.0.7J from Saxonica
Java version 1.8.0_92
java.lang.UnsupportedOperationException: XQuery Update is not supported in this Saxon Configuration
at net.sf.saxon.s9api.XQueryCompiler.setUpdatingEnabled(XQueryCompiler.java:212)
at net.sf.saxon.Query.doQuery(Query.java:281)
at net.sf.saxon.Query.main(Query.java:111)
Fatal error during query: java.lang.UnsupportedOperationException: XQuery Update is not supported in this Saxon Configuration
The filename, directory name, or volume label syntax is incorrect.
Java 8 is installed on my machine. I have also ensured that the XQuery Update still works when called from within the oXygen editor.
After reading up on http://www.saxonica.com/documentation9.6/index.html#!using-xquery/commandline and http://www.saxonica.com/documentation9.6/index.html#!conformance/update, I added the -tree:linked flag and the -qversion:1.0 flag (they result in the same error message):
java -cp "C:\Program Files\Oxygen XML Editor 17\lib\saxon9ee.jar" net.sf.saxon.Query -qversion:1.0 -tree:linked -update:on -t -q:"C:\Users\%USERNAME%\Documents\SVN Working Copies\trunk\rbscXSL\Locations2015\AbID2dsc-items.xq"
According to the documentation, XQuery Update should run if the -update:on flag is set, which it is, and the XML is read in using the doc() or collection() function, which is also the case--these are the variables from my XQuery file:
declare variable $EAD as document-node()* := doc("sample_input.xml");
declare variable $ITEMS as document-node()* := doc("sample_input.AbID.xml");
I'm at a loss what else to try. If anyone can see what's going wrong here, I'd greatly appreciate any pointers!
Do you have your own Saxon-EE license, or are you relying on the license that comes with oXygen? The oXygen license does not cover use of Saxon-EE outside of oXygen itself (so it doesn't cover the way you are running Saxon from the command line). Perhaps you found a loophole in the way oXygen handles the Saxon activation that worked in earlier releases but has since been fixed, either in oXygen or in Saxon.

Command line compiler for XTend

Hi allI've found XTend (http://xtend-lang.org) and it really sounds great! But, I can't see any standalone command line compiler for this language. It seems only to run under eclipse. I've done some research, and found some people saying, that it has a command line compiler, but I can't find a download link.
Does the compiler exist, standalone, or do you need eclipse to use it?
Regards
It is not documented, but there is indeed a command line compiler in the Xtend code base - the same one used by the Maven plug-in (that is documented in the Xtend homepage).
If Maven plug-in does not work for you, then you could download the standalone jar version directly from the Maven repository at http://build.eclipse.org/common/xtend/maven/org/eclipse/xtend/org.eclipse.xtend.standalone/2.3.1/ (for version 2.3.1), and execute the org.eclipse.xtend.core.compiler.batch.Main class from it.
This class executes the xtend compiler, and usage information can be displayed (also readable from the source file).
You can use the xtend standalone compiler. For my case I copied the following .jar files to a folder named xtendc:
com.google.guava_21.0.0.v20170206-1425.jar
com.google.inject_3.0.0.v201312141243.jar
javax.inject_1.0.0.v20091030.jar
org.antlr.runtime_3.2.0.v201101311130.jar
org.apache.log4j_1.2.15.v201012070815.jar
org.eclipse.emf.common_2.15.0.v20180914-1817.jar
org.eclipse.emf.ecore.xmi_2.15.0.v20180706-1146.jar
org.eclipse.emf.ecore_2.16.0.v20181124-0637.jar
org.eclipse.equinox.common_3.10.200.v20181021-1645.jar
org.eclipse.jdt.core_3.16.0.v20181130-1748.jar
org.eclipse.xtend.core_2.16.0.v20181203-1347.jar
org.eclipse.xtend.lib.macro_2.16.0.v20181203-0507.jar
org.eclipse.xtext.common.types_2.16.0.v20181203-0528.jar
org.eclipse.xtext.util_2.16.0.v20181203-0514.jar
org.eclipse.xtext.xbase.lib_2.16.0.v20181203-0507.jar
org.eclipse.xtext.xbase_2.16.0.v20181203-0528.jar
org.eclipse.xtext_2.16.0.v20181203-0514.jar
org.objectweb.asm_7.0.0.v20181030-2244.jar
And then, in that folder I executed the CLI main class of the batch compiler:
java -cp "*" org.eclipse.xtend.core.compiler.batch.Main -d <path-to-xtend-gen-folder> -useCurrentClassLoader <path-to-src-folder>
CLI usage of main class is documented to be as following:
Usage: Main <options> <source directories>
where possible options include:
-d <directory> Specify where to place generated xtend files
-tp <path> Temp directory to hold generated stubs and classes
-cp <path> Specify where to find user class files
-encoding <encoding> Specify character encoding used by source files
-javaSourceVersion <version> Create Java Source compatible to this version. Can be: 1.5, 1.6, 1.7, 1.8, 9, 10
-noSuppressWarningsAnnotation Don't put #SuppressWarnings() into generated Java Code
-generateGeneratedAnnotation Put #Generated into generated Java Code
-includeDateInGeneratedAnnnotation If -generateGeneratedAnnotation is used, add the current date/time.
-generateAnnotationComment <string> If -generateGeneratedAnnotation is used, add a comment.
-useCurrentClassLoader Use current classloader as parent classloader
-writeTraceFiles Write Trace-Files
so you will need to pass your classpath there.

xjc errors out when using scd in binding customization

When customizing a binding using scd, non-Sun jaxb plugins are not recognized
For example, this does NOT work:
<jaxb:bindings
scd="/~fpml:TradeHeader">
<ext:interfaces>
example.TradeHeaderDelegateInterface
</ext:interfaces>
</jaxb:bindings>
However, this works:
<jaxb:bindings
schemaLocation="../schemas/fpml-5-1/fpml-doc-5-1.xsd"
node="/xsd:schema//xsd:complexType[#name='TradeHeader']">
<ext:interfaces>
example.TradeHeaderDelegateInterface
</ext:interfaces>
</jaxb:bindings>
and, this works:
<jaxb:bindings
scd="/~fpml:CommodityMarketDisruption//fpml:marketDisruptionEvent">
<jaxb:property name="marketDisruptionEvent"/>
</jaxb:bindings>
which makes me think that scd and third party plugins don't get along:
The error I get is:
[ERROR] Error while parsing schema(s).Location [ file:/C:/projects/domain-fpml-5-1/src/main/resources/xjb/fpml-5-1.xjb{40,19}].
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'ext:interfaces'.
My .xjb file does declare the namespace for the "ext" prefix, so that's not the issue.
Has anyone worked with xjc plugins (e.g. the jaxb commons ones like Copyable etc.) and gotten it to work with scd based customization?
My xjc version is: 2.2.2 and I'm using the maven-jaxb2-plugin (version 0.8.0) plugin to generate bindings.
Thanks for any help,
aravind
maven-jaxb22-plugin:jar:0.8.1:runtime, com.sun.xml.bind:jaxb-impl:jar:2.2.5-b10:runtime, com.sun.xml.bind:jaxb-xjc:jar:2.2.5-b10:runtime] still exhibit this issue.
From looking at the xjc source code (some time ago) this is NOT an easy fix, because the customizations are not "imported" into the target xsd and the processing occurs in the context of the matched component.
This is the case with the Schema parser where by the schema is "imported" into the bindings context so all the namespaces are valid.
I have reverted all customizations back to schema style. I remember this had painful implications when trying to do both wsdl and xsd in the same bindings file.