I able to validate my XML config file against it's XML V 1.1 schema in the Oxygen XML Developer Editor.
If my schema violates an assertion constraint, such as an element's number attribute being larger than than a specific value, it won't validate the xml config file.
<assert test="6 >= #Number" />
Yet, my assertions are being ignored when I parse the config file in java against the schema.
I am using Xerces-J 2.11.0-xml-schema-1.1-beta.
I am including the following jars in my project
cupv10K-runtime.jar
icu4j.jar
xerceslmpl.jar
sml-apis.jar
org.eclipse.wst.xml.xpath2.processor_2.1.1v201204060055.jar
Is there another jar that I need to include?
Any advice on why it is ignoring the asserts would be unbelievably helpful.
Many thanks in advance.
Cheers,
Drew
I use the following command line, and I have not experienced problems in applying a test to an attribute of the current element:
$ export XERCESJ=$HOME/xerces-j/xerces-2_11_0-xml-schema-1.1-beta
$ java -classpath $XERCESJ/cupv10k-runtime.jar:/usr/share/java/org.eclipse.wst.xml.xpath2.processor-2.1.100.jar:/usr/share/java/xercesImpl-xsd11-2.12-beta-r1667115.jar:$XERCESJ/xml-apis.jar:$XERCESJ/xercesSamples.jar jaxp.SourceValidator -xsd11 -i my_instance.xml
The XSD 1.1 syntax is fine, and the condition of the test is enforced.
Related
I am a little confused with how does xml xsi:schemaLocation works.
I am using Maven + IDEA to create a Spring project.
If miss org.springframework.spring-beans in my dependency, IDEA will warn me some error.
If I add this jar, warn will disappear.
Maybe it is not important, but it like a black magic to me, can any one help me how does this work?
Those XSDs are in fact included in the jar provided by spring. You can check this by doing a double shift and typing in the XSD's filename. So if you don't include the jar, your maven project cannot locate the XSD in your classpath.
The XSD you mentioned can be found here, as part of the spring-beans module
IntelliJ IDEA is helpfully indicating that it cannot location the XSD that it needs to validate the Spring project.
It turns the default namespace (beans/#xmls) red because it uses that along with the paired value of the namespace given by xsi:schemaLocation (also red) in order to find the governing XSD. Note that this does not necessarily have to be at the URL given by the paired value xsi:schemaLocation (https://www.springframework.org/schema/beans/spring-beans.xsd). Other mechanisms, including as XML Catalogs, can aid in the resolution of where the actual XSD can be found.
In this case, IDEA knows to check JARs on the classpath for the needed XSD.
See also:
How to link XML to XSD using schemaLocation or noNamespaceSchemaLocation?
xmlns, xmlns:xsi, xsi:schemaLocation, and targetNamespace?
How to reference a local XML Schema file correctly?
Must an XML namespace name URI be retrievable?
Netbeans seems to reject some XSD tags supported by XSD 1.1, for example "assert":
cvc-complex-type.2.4.a : Invalid content found from the element
'xs:assert'. One of the values
'{"http://www.w3.org/2001/XMLSchema":attribute,
"http://www.w3.org/2001/XMLSchema":attributeGroup,
"http://www.w3.org/2001/XMLSchema":anyAttribute}' is expected. [205]
I tried to use some of these examples without success. What can I do to resolve my problem?
As far as I know, I have nothing to do to specify in the XSD schema that I use some features of XSD 1.1:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
It depends exactly what you mean by "use XSD 1.1 in NetBeans 8.2", but I assume you want to use the context menu entry Validate XML in NetBeans against some *.xsd file with XSD 1.1 features (such as assert). If I do that I see the same "cvc-complex-type.2.4.a : Invalid content found..." error that you report.
There is no way to customize the validator used by the Validate XML command, and apparently it uses the JDK's javax.xml API for validation. NetBeans 8.2 uses Java 8, but even with JDK 9 there is no way to validate XSD 1.1 features:
Java 9.
...The big news is that finally we get the internal ports of Xerces
updated. Oracle (and Sun before them) have been really slack in
neglecting this so long: Java was stuck using Xerces 2.7.n for 11
years for goodness sake. The new ports are equivalent to Apache
Xerces 2.11.0. (NOTE: XSD is still 1.0 only, the XSD 1.1 updates have
not been put in place, but this probably reflects Apache Xerces’ slow
pace to make the changes official.)
The same problem occurs when using Apache NetBeans 9.0 RC1 so this issue will probably not get resolved until either:
NetBeans uses a JDK which uses a version of Xerces that supports the validation of XSD 1.1 features.
NetBeans uses a different approach for XSD validation.
I also don't see any NetBeans plugins that will help. Of course there are still third-party tools and (possibly) configuration for Maven projects that may help, but I don't see a solution using only NetBeans.
We can see many tutorials that shows how to produce soap webservice using xsd in spring-boot. Is it possible to create soap webservice without xsd and from plain Java code using spring-boot-webservice module like we do using #webservice annotation in jax-ws
Guides like this start with an xsd file because they use xjc to create java classes from the XSD definition. xjc creates classes with JaxB annotations (javax.xml.bind.annotation). JaxB is an xml binding specification that has been part of the JDK since 1.6, and it requires that all types from the xsd exist as java classes.
I suggest that you do a tutorial that starts with an xsd an take a look at the auto generated classes. There is nothing to prevent you from writing you own classes instead of generating them from a wsdl, and if you don't refer to external schemas I prefer to do the code only approach (I hate xml configuration).
If you look at the tutorial, the gradle task "getJaxb" will create .java files into "build/generated-sources" compile them and copy them into "build/classes" if you copy the *.java files into "src/main/java" (keep the package structure) and delete delete/disable the "genJaxb" task in gradle, and delete your build folder, everything still works (it actually works better since you normally have red lines in your IDE because the XML beans don't exist until you run the generator the first time).
Now all you need to do is master the JaxB annotations, so you can write your own beans.
I am trying to generate the schema classes from wsdl using the JAXB xjc tool and I am facing the below message:
xjc -verbose -wsdl https://xyz/wsdl.aspx
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location
However, I have tried to with a different wsdl url as below:
xjc -verbose -wsdl http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl
parsing a schema...
compiling a schema...
[INFO] generating code
unknown location
com\cdyne\ws\weatherws\ArrayOfForecast.java
com\cdyne\ws\weatherws\ArrayOfWeatherDescription.java
com\cdyne\ws\weatherws\Forecast.java
etc....
For this 'Weather' wsdl, though I have noticed that there is 'unknown location', the command could successfully generate the schema classes.
I have tried to google and refer the below site, but could not find anything helpful on this subject.
https://jaxb.java.net/2.2.4/docs/xjc.html
I did not understand clearly from xjc log (which says 'unknown location') on what is the exact issue ?
If it is an issue then how could it generate the schema classes for the second 'Weather' wsdl url ?
How do I fix the issue and generate schema files for the first url (https://xyz/wsdl.aspx) ?
I tried to use 'jaxb2-maven-plugin' inside the eclipse, but did not generate any files without any errors. Is it also for the same reason ?
It's most likely complaining about the url <wsdlsoap:address location="..." /> and can't reach the service. This element is within the wsdl:port element which is found within wsdl:service element.
I'm trying to run xjc on a Third-party's schema files (it's Amazon.com's product API). Well I'm running into trouble because with one of the files, default.xsd, xjc is borking on the following import (it's the first one right after the schema declaration):
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd" />
I'm not an expert on XML, but I thought xml.xsd was part of the "core" XML/XSD library and that XJC would know the details of this library by default. But when I run the task I get this error:
[WARNING] schema_reference.4: Failed to read schema document
'xml.xsd', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not
. line 9 of file:/C:/temp/amazon/default.xsd
[ERROR] src-resolve: Cannot resolve the name 'xml:lang' to a(n)
'attribute declaration' component. line 119 of
file:/C:/temp/amazon/default.xsd
I tried downloading the xml.xsd file from http://www.w3.org/2001/03/xml.xsd to the directory with these schema files and running the command again, but xml.xsd doesn't validate:
[ERROR] schema_reference.4: Failed to read schema document
'file:/C:/temp/amazon/xml.xsd', because 1) could not find the
document; 2) the document could not be read; 3) the root element of
the document is not . unknown location
I was about to start going down the rabbit hole of why this wouldn't be validated, but decided to hold off since I think I'm missing something really simple or small. Do I need to manually include the xml.xsd import or am I missing something else?
The urls for the schema I am working with are currently here:
http://g-ecx.images-amazon.com/images/G/01/mwsportal/doc/en_US/products/default.xsd
and here
http://g-ecx.images-amazon.com/images/G/01/mwsportal/doc/en_US/products/ProductsAPI_Response.xsd
And I'm simply using:
xjc dirname
together at once or
xjc filename
to try to parse them one-by-one
I downloaded your XSD files to mimic the error and indeed, when downloaded as is they give exactly the error you reported.
It wasn't immediately obvious what was happening. Yes, the XML namespace http://www.w3.org/XML/1998/namespace is special and reserved. You do not have to declare it for it to be in existence, but the xml.xsd file is used for Schema compliance, so that these predefined types are also defined in the XSD Schema, so that the types can be used in using schemas.
So my first thoughts were with the XML namespace needing to be declared as xmlns:xml="http://www.w3.org/XML/1998/namespace" (normally this is never needed) for XJC to behave normally, but that didn't change much.
After a bit going back and forth, I decided to run xjc with the option -nv, which turns of certain strict validation rules. This time, the error I received was a bit clearer and immediately pointed to the cause, and the obvious solution:
[ERROR] failed to retrieve 'file:/D:/Projects/xyz/XMLSchema.dtd': java.io.FileNotFoundException: D:\Projects\xyz\XMLSchema.dtd (The system cannot find the file specified)
line 2 of file:/D:/Projects/xyz/xml.xsd
Apparently, XJC tries to download the DTD referenced by the DOCTYPE declaration:
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" >
Actually, this isn't XJC, but the XML parser that precedes XSD validation. The XML parser used is a validating parser, which means it tries to find the DTD and if it cannot, it breaks. The error you received is not very helpful, but correct, as in XML terms, an XML file that points to a DTD is not a valid XML file (but it can be a well-formed XML file and non-validating XML processors, not to be confused with XSD schema validation, will simply load the XML).
Solution
However, the DTD is not required for the XML to be considered correct. You can either download the XMLSchma DTD, or, easier, simply remove that line and the processing will succeed, with or without the -nv switch.
You can use catalogs to fix this type of errors:
Assume one or more of your schemas reference a resource via invalid URL.
Find this resource (is probably available from some alternative location) and save it locally.
Create a catalog file to rewrite the URL. You can rewrite via namespace or via file location:
PUBLIC "http://www.w3.org/XML/1998/namespace" "w3c/2001/03/xml.xsd"
REWRITE_SYSTEM "http://www.w3.org/2001/03/xml.xsd" "w3c/2001/03/xml.xsd"
(Local file location is w3c/2001/03/xml.xsd.)
Use it as xjc -catalog mycatalog.cat ...
You can do the same fo DTDs as well. I normally rewrite just "http://www.w3.org" -> "w3c" and keep the folder structure the same as on the server.
Using -nv is a good idea, works better with catalogs in any case:
https://github.com/highsource/maven-jaxb2-plugin/wiki/Catalogs-in-Strict-Mode
Links:
https://github.com/highsource/maven-jaxb2-plugin/wiki/Using-Catalogs
https://jaxb.java.net/guide/Fixing_broken_references_in_schema.html
http://blog.bdoughan.com/2011/10/jaxb-xjc-imported-schemas-and-xml.html
https://github.com/highsource/w3c-schemas (I'm the author of this one.)