How does xsi:schemaLocation work with IntelliJ IDEA? - java

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?

Related

xerces jar name changes behaviour

I have an older application that uses a jar named xerces.jar. Looking at this I can see that it is the same as xercesImpl-2.9.1.jar from the maven repository.
When I run the application the xml validation behaves differently depending on if the jar is named xerces.jar or xercesImpl-2.9.1.jar.
I suspect there is something going on with the order that it it found on the classpath but I don't fully understand what is going on.
Any ideas as to what is going on?
The particular change is this:
The start tag looks like:
<Message xmlns="http://www.foo.com/messaging" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" release="006" version="010" xsi:schemaLocation="file:///C:/SOME/PATH">
When the jar is named "xerces.jar" this accepted when the app validates against a specific schema. When the jar is named "xercesImpl-2.9.1.jar" then it gives the error: Attribute 'xsi:schemaLocation' is not allowed to appear in element

"Use <jaxb:property> to resolve this conflict" error while converting xsd to java objects using jaxb

I am trying to unmarshall elements of xds file to java oblects. I am using Jaxb mavan plugin and Eclipse IDE.
My .xsd file is can be found from
EiPayload
EiEnrollment
EiClasses
Here is my file structure and error,
Need some help to debug this error..!

Disclaimer: I am a lead dev of the ogc-schemas and the w3c-schemas projects.
You have problems with GML 3.2.1 and XLink 1.0. I've implemented bindings for these schemas in the ogc-schemas and the w3c-schemas project. Here you go:
gml-v_3_2_1.xjb
xlink-v_1_0.xjb
But better use the provided JAR artifacts as episodes.

Error using XJC with xml.xsd import: "Failed to read schema document 'xml.xsd'"

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.)

XSD to Java custom datatype

I have xsd which contain the following: type="EAIschema:eCodes" where eCodes is another schema. When I compile it using xjc it returns:
"Cannot resolve the name 'EAIschema:eCodes' to a(n) 'type definition' component"
I want to know how to solve this problem

I'm not 100% sure about the error message, but it looks to me as if the JAXB classes for the other XSD were missing. If your XSD uses data structures of the other XSD then your JAXB classes will need those JAXB classes.
Solution: generate/ add the JAXB classes for the other XSD to your classpath.
If those classes are in a separate JAR, make sure it contains an episode file.

When the XJC tool is converting the XML schema(s) to Java classes it will automatically pull in imported/included schemas based on their system id. It those schemas are not available at the specified system id (or its not specified) then you could use an XML catalog.
For More Information
http://blog.bdoughan.com/2011/10/jaxb-xjc-imported-schemas-and-xml.html

XML Schema V 1.1 Assertions not working in Xerces-J

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.

Categories