xmlet / xsdparser Goto Github PK

Hi,
if a element contains a namespace in the type attribute which refers to another schema, then the reference can't be resolved. Please find a sample attached.
xsd_1 uses a type which is defined in xsd_2. This reference can't be resolved.

Code:
public static void main(final String[] args) { final String path = "xsd_1.xml"; final XsdParser parser = new XsdParser(path); System.out.println(parser.getUnsolvedReferences().size()); }

It would be great if you could make the reference resolving namespace sensitive.

Thank you,
Kai

XSDTest.zip

Hi,

We have the following XSD:

<xsd:complexType name="fooType"> <xsd:sequence> <xsd:element name="id" type="FooIDType"/> </xsd:sequence> </xsd:complexType>
<xsd:simpleType name="FooIDType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(XX|YY|ZZ):[a-zA-Z0-9]{4,10}"/> </xsd:restriction> </xsd:simpleType>

When I call getXsdComplexType() on the XsdElement for "id" in the fooType, then we encounter an ClassCastException because the underlaying type is a XsdSimpleType. I had expected the getXsdComplexType() method to return null.

java.lang.ClassCastException: org.xmlet.xsdparser.xsdelements.XsdSimpleType cannot be cast to org.xmlet.xsdparser.xsdelements.XsdComplexType at org.xmlet.xsdparser.xsdelements.XsdElement.getXsdType(XsdElement.java:297) at org.xmlet.xsdparser.xsdelements.XsdElement.getXsdComplexType(XsdElement.java:288) at nl.svb.sem.correspondentiemanager.xsd.model.XsdStructure.findComplexForElement(XsdStructure.java:76)

Describe the bug
The build fails with OpenJDK 11

Expected behavior

T E S T S

Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525)
Caused by: java.lang.RuntimeException: Class java/lang/UnknownError could not be instrumented.
at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:140)
at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:101)
at org.jacoco.agent.rt.internal_c13123e.PreMain.createRuntime(PreMain.java:55)
at org.jacoco.agent.rt.internal_c13123e.PreMain.premain(PreMain.java:47)
... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
at java.base/java.lang.Class.getField(Class.java:1999)
at org.jacoco.agent.rt.internal_c13123e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138)
... 9 more
*** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at ./src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed
/bin/sh: line 1: 7182 Abort trap: 6 /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java -javaagent:/Users/mg61dd/.m2/repository/org/jacoco/org.jacoco.agent/0.8.1/org.jacoco.agent-0.8.1-runtime.jar=destfile=/Users/mg61dd/workspace/XsdParser/target/jacoco.exec -jar /Users/mg61dd/workspace/XsdParser/target/surefire/surefirebooter8702145386574356607.jar /Users/mg61dd/workspace/XsdParser/target/surefire/surefire7793138380492632711tmp /Users/mg61dd/workspace/XsdParser/target/surefire/surefire_02303034023949158715tmp
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Library Version
What is the version that you are using?
master bt-ranch
Additional context
Upgrading to jacoco 0.8.4 solved that issue

If there is an xs:element definition as follows:

<xs:element name="someThing" substitutionGroup="someCategory">
		<xs:complexType>
[...]

Then the call element.getXsdComplexType returns null.

What I expect is that the element.getXsdComplexType call returns the xs:complexType element, as happens when the substitutionGroup attribute is removed from the xs:element.

I have the following xsd fragment

					<xs:element name="F20" type="F20_Type">
						<xs:annotation>
							<xs:appinfo>
								<info:Tag value="20"/>
								<info:LogicalType value="TRN"/>
							</xs:appinfo>
							<xs:documentation source="Name" xml:lang="EN">Sender's Reference</xs:documentation>
						</xs:annotation>
					</xs:element>

So I added the appInfo extension via an import

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:info="urn:swift:xsd:appInfo" xmlns="urn:swift:xsd:fin.103.2021" targetNamespace="urn:swift:xsd:fin.103.2021" elementFormDefault="qualified">
	<xs:import schemaLocation="appInfo.xsd" namespace="urn:swift:xsd:appInfo" />

Where appInfo.xsd contains these extensions.

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:swift:xsd:appInfo" targetNamespace="urn:swift:xsd:appInfo">
    <xs:complexType name="LogicalType">
        <xs:attribute name="value" type="xs:string"/>
    </xs:complexType>
    <xs:complexType name="Tag">
        <xs:attribute name="value" type="xs:string"/>
    </xs:complexType>
</xs:schema>

However when I parse the XSD I got in the xsdAppInfo

with this ( scala ) code

    Option(xsdElement.getAnnotation).foreach(xsdAnnotation =>
      Option(xsdAnnotation.getAppInfoList).foreach(xsdAppinfo=>
        println(xsdAppinfo)))

Question : should the xsdAppInfo contain the embedded elements and types ? Or does the XsdParser stop at this level ?
Hope you can help.
Your software has become very useful for us.

After upgrade to jacoco 0.8.4 and using OpenJdk 11 ( /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java ) one of the tests fails.

testDocumentationWithCDATA(org.xmlet.xsdparser.IssuesTest) Time elapsed: 0.009 sec <<< FAILURE!
org.junit.ComparisonFailure: expected:<> but was:<>
at org.junit.Assert.assertEquals(Assert.java:117)
at org.junit.Assert.assertEquals(Assert.java:146)
at org.xmlet.xsdparser.IssuesTest.testDocumentationWithCDATA(IssuesTest.java:76)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Running org.xmlet.xsdparser.CommentsTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Describe the bug
I parse the unitsML schema, containing a type like

<xsd:complexType name="NameType">
		<xsd:annotation>
			<xsd:documentation>Type for name.  Used for names in units, quantities, and prefixes.</xsd:documentation>
		</xsd:annotation>
		<xsd:simpleContent>
			<xsd:extension base="xsd:token">
				<xsd:attribute ref="xml:lang"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>

I then try to get the attribute using

 final XsdExtension xsdExtension = simpleContent.getXsdExtension();
xsdExtension.getXsdAttributes(). xsdAttributes.forEach(xsdAttribute -> { ... };

But get no attribute

Expected behavior

Get the attributes nested on the xsd extension

Additional context
The schema is found here https://schema.unitsml.org/docs/unitsmllite/unitsmllite-v0.9.18/

PS: Is there something like a user group for xmlet?

Hello,

currently XsdParser uses doc.getFirstChild(); to get the XSD root.
This fails terribly with all kinds of schema which have a comment or text node.

My proposal is to use

return doc.getDocumentElement();

Bye, Carsten

Hello,
first thanks for the very fast response on issue #24! Everything s fine, just left a star.
But I found another problem while parsing a xsd with subdirectories: I attached a example zip to reproduce the problem.
issue28_xsd.zip
Parsing the issue_28.xsd shows a

java.lang.NullPointerException
	at org.xmlet.xsdparser.core.XsdParserCore.lambda$null$7(XsdParserCore.java:144)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
	at org.xmlet.xsdparser.core.XsdParserCore.lambda$resolveOtherNamespaceRefs$8(XsdParserCore.java:123)
	at java.util.HashMap$KeySet.forEach(HashMap.java:933)

using 1.0.33-SNAPSHOT.
The problem is the import of issue_28b.xsd from issue_28.xsd (with subdirectory issue_28) and from issue_28a.xsd (without subdirectory). If the schemaLocation is specified with an absolute file, it's working.
I looked in the source code and found

    private Map<String, List<ReferenceBase>> parseElements = new HashMap<>();
    private Map<String, List<UnsolvedReference>> unsolvedElements = new HashMap<>();
    List<String> schemaLocations = new ArrayList<>();
    Map<String, String> schemaLocationsMap = new HashMap<>();
    protected String currentFile;

After debugging I saw, thew the keys in schemaLocations sometimes have the directory in it, sometimes not. So I'd suggest using URI instead:

    private Map<URL, List<ReferenceBase>> parseElements = new HashMap<>();
    private Map<URL, List<UnsolvedReference>> unsolvedElements = new HashMap<>();
    List<URL> schemaLocations = new ArrayList<>();
    protected URL currentFile;

because the URLs are normalized. (The schemaLocationsMap not necessary an more). Instead of string manipulation to create a new filename, using
url = new URL(currentFile, importedFileName);
is easier.

If I can help you with more explanations or java code, please let me know.

Description

When parsing a specific, quite complex XML Schema (see attachment), a NullPointerException is raised:

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.matches(String)" because "filePath" is null
	at org.xmlet.xsdparser.core.XsdParserCore.isRelativePath(XsdParserCore.java:492)
	at org.xmlet.xsdparser.core.XsdParserCore.lambda$resolveOtherNamespaceRefs$8(XsdParserCore.java:148)
	at java.base/java.util.HashMap$KeySet.forEach(HashMap.java:1008)
	at org.xmlet.xsdparser.core.XsdParserCore.resolveOtherNamespaceRefs(XsdParserCore.java:109)
	at org.xmlet.xsdparser.core.XsdParserCore.resolveRefs(XsdParserCore.java:93)
	at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:66)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:38)

It looks like XsdParser performs a isRelativePath() on a null value because of a previous variable (unsolvedElementSchema) being null (see XsdParserCore on line 139). Debugging the code led me to XsdAbstractElement.java:

    public XsdSchema getXsdSchema(){
        XsdSchema schema = null;

        try {
            schema = getXsdSchema(this, new ArrayList<>());
        }
         catch (ParentAvailableException e){
            return null; ////////////// this one ultimately causes the parsing process to crash
         }

        if (schema == null){
            throw new ParsingException("The parent is null while searching for the XsdSchema. Please submit an issue with the xsd file being parsed to the project page.");
        }

        return schema;
    }

I tried to find a fix myself but wasn't able to entirely comprehend the code so far. Your help is very much appreciated!

Expected behavior

The files have been tested as valid (XML Spy) and could be read in with a former version of XsdParser, which was 1.0.28.

Library Version

1.2.0

Additional context

The XML Schema that fails to parse is BICEPS_MessageModel.xsd.
BICEPS_MessageModel.zip

Hi,

We are using the XsdParser class with the XSD files inside src/main/resources directory. When the code and XSDs are packaged together inside a jar and run, the code is able to read the XSD, but can't find the nested XSD inside an xs:include. Do you have any recommendations on this type of error?

Code:

URL schemaFileURL = this.getClass().getClassLoader().getResource("Sample.xsd");
String schemaFilePath = schemaFileURL.toURI().toString();
XsdParser parser = new XsdParser(schemaFilePath);

Sample.xsd:

<xs:schema elementFormDefault="qualified">
	<xs:include schemaLocation="Nested.xsd"/>
</xs:schema>

Both Sample.xsd and Nested.xsd are placed directly in src/main/resources.

Thanks in advance,

Daniel

Describe the bug
In the case of a restriction inside a complexContent, I'm not able to get the base complexType

Expected behavior
Hello
I'm working on a interactive xsd to xml builder, and inside my xsd there is a complexType witch define a complex content that restrict an other base complexType, but unfortunately i couldn't get this base complexType. the class XsdRestriction has a method getSimpleType, but doesn't have a methode getComplexType. Unlike the XsdExtension class that posses getBaseAsComplexType method.
Thanks.
Library Version
1.2.0

Additional context
xsd:complexContent
<xsd:restriction base="dm:RelationalColumn">
<xsd:attribute name="orphanRemoval" type="xsd:boolean" use="prohibited"/>
<xsd:attribute name="unique" type="xsd:boolean" use="prohibited"/>
<xsd:attribute name="index" type="xsd:boolean" use="prohibited"/>
<xsd:attribute name="massUpdate" type="xsd:boolean" use="prohibited"/>
</xsd:restriction>
</xsd:complexContent>

Could you please make xmlet available for Java 8 too ? Thanks

Hello,
Thank you for this helpfull library.
While parsing a (rather complex) schema with the venetian blind pattern, I observed problem with the parent - children relationship of complex types.
First a working correct example:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" atributeFormDefault="qualified">
	<xsd:complexType name="CT1">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="CT2">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

creates the structure (for the code see below)

----------------------------------------------------------
ComplexType CT1#1209358542
 -> children=XsdElement#479442206 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> parent=XsdSchema#2081368312 {attributeFormDefault=qualified, xmlns:xsd=http://www.w3.org/2001/XMLSchema, elementFormDefault=qualified, xmlns=nsallg, targetNamespace=nsallg, xmlns:allg=nsallg}
 -> -> children of parent=XsdComplexType#1209358542 {name=CT1}
 -> -> children of parent=XsdComplexType#1182469998 {name=CT2}
 -> grandparent=null
----------------------------------------------------------
ComplexType CT2#1182469998
 -> children=XsdElement#1195473402 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> parent=XsdSchema#2081368312 {attributeFormDefault=qualified, xmlns:xsd=http://www.w3.org/2001/XMLSchema, elementFormDefault=qualified, xmlns=nsallg, targetNamespace=nsallg, xmlns:allg=nsallg}
 -> -> children of parent=XsdComplexType#1209358542 {name=CT1}
 -> -> children of parent=XsdComplexType#1182469998 {name=CT2}
 -> grandparent=null
----------------------------------------------------------

This is what I expect: a Schema -> ComplexType -> Element structure
Now the problem: In the following xsd a complex type is used in an element type.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" atributeFormDefault="qualified">
	<xsd:complexType name="CT1">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
 			<xsd:element name="CT2Element" type="CT2" minOccurs="0" maxOccurs="unbounded" />
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="CT2">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

the structure is strange: CT1 is correct, but it looks like CT2 has a russian doll and not a venetian blind structure.

----------------------------------------------------------
ComplexType CT1#1541298091
 -> children=XsdElement#2075981552 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> children=XsdElement#729867689 {minOccurs=0, name=CT2Element, maxOccurs=unbounded, type=CT2}
 -> parent=XsdSchema#1287658623 {attributeFormDefault=qualified, xmlns:xsd=http://www.w3.org/2001/XMLSchema, elementFormDefault=qualified, xmlns=nsallg, targetNamespace=nsallg, xmlns:allg=nsallg}
 -> -> children of parent=XsdComplexType#1541298091 {name=CT1}
 -> -> children of parent=XsdComplexType#919063521 {name=CT2}
 -> grandparent=null
----------------------------------------------------------
ComplexType CT2#919063521
 -> children=XsdElement#449240381 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> parent=XsdElement#729867689 {minOccurs=0, name=CT2Element, maxOccurs=unbounded, type=CT2}
 -> grandparent=XsdSequence#1445534206 {}
----------------------------------------------------------

It's getting messy when a complex type is used in the same element in a recursive way:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" atributeFormDefault="qualified">
	<xsd:complexType name="CT1">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
 			<xsd:element name="CT1Element" type="CT1" minOccurs="0" maxOccurs="unbounded" />
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="CT2">
		<xsd:sequence>
			<xsd:element name="Nr" type="xsd:string" minOccurs="0" maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

the result is:

----------------------------------------------------------
ComplexType CT1#628402659
 -> children=XsdElement#1071550332 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> children=XsdElement#299395997 {minOccurs=0, name=CT1Element, maxOccurs=unbounded, type=CT1}
 -> parent=XsdElement#299395997 {minOccurs=0, name=CT1Element, maxOccurs=unbounded, type=CT1}
 -> grandparent=XsdSequence#288887829 {}
----------------------------------------------------------
ComplexType CT2#1524026401
 -> children=XsdElement#134271077 {minOccurs=0, name=Nr, maxOccurs=1, type=xsd:string}
 -> parent=XsdSchema#1762731246 {attributeFormDefault=qualified, xmlns:xsd=http://www.w3.org/2001/XMLSchema, elementFormDefault=qualified, xmlns=nsallg, targetNamespace=nsallg, xmlns:allg=nsallg}
 -> -> children of parent=XsdComplexType#628402659 {name=CT1}
 -> -> children of parent=XsdComplexType#1524026401 {name=CT2}
 -> grandparent=null

You can see a circular reference in CT1 between children ind parent. I don't think it was expected this way.

Here's the source code for the tests:

	public void parseSchema(String schemafile) {
		XsdParser parser = new XsdParser(schemafile);
		List<XsdSchema> schemas = parser.getResultXsdSchemas().collect(Collectors.toList());
		for (XsdSchema schema : schemas) {
			List<XsdComplexType> cts = schema.getChildrenComplexTypes().collect(Collectors.toList());
			for (XsdComplexType ct : cts) {
				System.out.println("----------------------------------------------------------");
				System.out.println("ComplexType " + ct.getName() + "#" + System.identityHashCode(ct));
				ct.getXsdElements().forEach(e -> System.out.println(" -> children=" + getInfo(e)));
				System.out.println(" -> parent=" + getInfo(ct.getParent()));
				ct.getParent()
						.getXsdElements()
						.forEach(e -> System.out.println(" -> -> children of parent=" + getInfo(e)));
				System.out.println(" -> grandparent=" + (ct.getParent() != null ? getInfo(ct.getParent().getParent()) : "null"));
			}
		}
        }
	private String getInfo(XsdAbstractElement xae) {
		if (xae == null) {
			return "null";
		} else {
			StringBuilder sb = new StringBuilder();
			sb.append(xae.getClass().getSimpleName() + "#" + System.identityHashCode(xae) + " " + xae.getAttributesMap());
			return sb.toString();
		}
	}

Hi,
your parser can't resolve substitutionGroup references. Is this planned or unplanned behavior?

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="name" type="xs:string"/>
<xs:element name="navn" substitutionGroup="name"/>
<xs:complexType name="custinfo">
  <xs:sequence>
    <xs:element ref="name"/>
  </xs:sequence>
</xs:complexType>
<xs:element name="customer" type="custinfo"/>
<xs:element name="kunde" substitutionGroup="customer"/>
</xs:schema>

Best regards,
Kai

Hi,

My schema fails parsing with "The top level element of a XSD file should be the xsd:schema node" at XsdParserJar::parseJarFile.

I know my schema is valid because it successfully runs when I use the XsdParser with a local path. When I changed it to use the XsdParserJar with the files packaged within the .jar it fails. I removed all comments and text above the root xsd:schema node in all the .xsd files, but it still fails.

I notice the XsdParser checks all its children in XsdParser::getSchemaNode and returns the first schema node, but in the XsdParserJar::getSchemaNode only the first child node is returned.

I think this difference is caused by only fixing the issue reported here: #7 for the XsdParser.

Would it be possible to fix this for the XsdParserJar too?

Thanks!
Milena

Describe the bug
If a tag has multiple patterns, only the last pattern is used.

Expected behavior
The restriction has all patterns included.

Library Version
1.2.4

Additional context
Multiple pattern are a part of the schema: https://www.w3.org/TR/xmlschema-2/#src-multiple-patterns
SDMXCommon_xsd.txt

And it's a nice lib :)

Hi there, i am pretty new to this XSD Parsing stuff,

when I try to parse my XSD File, the Parser (or the underlaying framework) throws this error:

org.xmlet.xsdparser.xsdelements.exceptions.ParsingException: Nicht unterstützt: http://javax.xml.XMLConstants/property/accessExternalDTD

However, i've come across the "ParserConfig" - is there a chance/possibilty to make this work with this one?

And: Is there a more detailed documentation ?
Thanks!

<xs:simpleType name="Authorisation1Code">
        <xs:annotation>
            <xs:documentation source="Name" xml:lang="EN">Authorisation1Code</xs:documentation>
            <xs:documentation source="Definition" xml:lang="EN">Specifies the level of approval depending on a number of factors, including payment type, threshold amount or local country or operations practice.</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="AUTH">
                <xs:annotation>
                    <xs:documentation source="Name" xml:lang="EN">PreAuthorisedFile</xs:documentation>
                    <xs:documentation source="Definition" xml:lang="EN">Indicates a file has been pre authorised or approved within the originating customer environment and no further approval is required.</xs:documentation>
                </xs:annotation>
            </xs:enumeration>
            <xs:enumeration value="FDET">
                <xs:annotation>
                    <xs:documentation source="Name" xml:lang="EN">FileLevelAuthorisationDetails</xs:documentation>
                    <xs:documentation source="Definition" xml:lang="EN">Indicates that a file requires additional file level approval, with the ability to view both the payment information block and supporting customer credit transaction detail.</xs:documentation>
                </xs:annotation>
            </xs:enumeration>
            <xs:enumeration value="FSUM">
                <xs:annotation>
                    <xs:documentation source="Name" xml:lang="EN">FileLevelAuthorisationSummary</xs:documentation>
                    <xs:documentation source="Definition" xml:lang="EN">Indicates that a file requires additional file level approval, with the ability to view only the payment information block level information.</xs:documentation>
                </xs:annotation>
            </xs:enumeration>
            <xs:enumeration value="ILEV">
                <xs:annotation>
                    <xs:documentation source="Name" xml:lang="EN">InstructionLevelAuthorisation</xs:documentation>
                    <xs:documentation source="Definition" xml:lang="EN">Indicates that a file requires all customer transactions to be authorised or approved.</xs:documentation>
                </xs:annotation>
            </xs:enumeration>
        </xs:restriction>
    </xs:simpleType>

looks like the XsdEnumeration.getAnnotation returns null.
while XsdEnumeration.getValue returns "AUTH".
Rings a bell ? I didn't try yet to isolate this any further.

in the elements tree always get one empty item inside the app inof list in the annotation node.
is there a way to get the value of it.
xs:annotation
xs:appinfo
<info:MetaType value="Text"/>
<info:LogicalType value="Text"/>
<info:FinFormat value="16x"/>
</xs:appinfo>
</xs:annotation>

First of all, I would like to thank you for providing this very usuful xsd parser.

Describe the bug
Upgrading xsdParser version from 1.2.4 to 1.2.6, the return type of method getPattern() has been changed. (from single value to list).
Here is the commit introducing the breaking change :
859d897
This broke my software's build.

Expected behavior
Creating new method for new return type, flag the old one as deprecated and wait some time before removal.
Maybe using some sort of convention for breaking changes, for instance as in
semantic versioning
(Changing the major version when a new release is not backward compatible)

Library Version
Upgrading from 1.2.4 to 1.2.6

Additional context
Here is a sample of the code that broke :
AutodocAttribute line 95

Thanks again!

Describe the bug
When parsing the OCX Schema, one gets a null pointer exception.

Expected behavior
No Null Pointer Exception

Library Version
3f5edef

Additional context

On https://github.com/skfcz/XsdParser you find

• one test case with data
• a fix

and additional code to access the XsdAttributes default value

The official US accounting standard XSD schema can't be parsed.
You can download schema on: https://xbrl.fasb.org/us-gaap/2021/us-gaap-2021-01-31.zip

At run time, the parser throws:

java.lang.RuntimeException: Namespace for prefix 'xlink' has not been declared.
at java.xml/com.sun.org.apache.xml.internal.serializer.SerializerBase.getNamespaceURI(SerializerBase.java:784)
at java.xml/com.sun.org.apache.xml.internal.serializer.SerializerBase.addAttribute(SerializerBase.java:379)
at java.xml/com.sun.org.apache.xml.internal.serializer.ToUnknownStream.addAttribute(ToUnknownStream.java:269)
at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:199)
at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.DOM2TO.parse(DOM2TO.java:92)
at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:712)
at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:774)
at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:370)
at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdRawContentParse(XsdAbstractElement.java:369)

Today it is not possible to parse XSDs inside jars (you get "FIleNotFoundException").

The check for File.exists() in XsdParser.parseFile() could be change to:
if (!(filePath.startsWith("jar:") || filePath.startsWith("file:")) && !new File(filePath).exists()){
throw new FileNotFoundException();
}

Then you could use: new XsdParser(RandomClass.class.getResource(filename).toExternalForm()) to use an XSD-file bundled inside a JAR-file (optionally it could have a constructor with an InputStream).

Hi,
once again an issue. I currently working with your lib and I really like it! Thank you for creating it.

Here is a sample xsd:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:element name="root" type="extendedType" />	
	<xsd:complexType name="baseType">
		<xsd:attribute name="attributeOne" type="xsd:string" use="required" />
	</xsd:complexType>
	<xsd:complexType name="extendedType">
		<xsd:complexContent>
			<xsd:extension base="baseType">
				<xsd:sequence>
					<xsd:element name="additionElement" type="xsd:string"/>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>
</xsd:schema>

When I now try to resolve the reference, I can see that the base attribute of the XsdExtension of extendedType contains a unsolved reference. The reference pointing correctly to baseType. This is not shown in the parser.getUnsolvedReferences().

Additional, can you please check the getBase method in the XsdExtension class. It's returning a XsdElement, but according to the documentation, also complex and simple types are allowed.

Thanks and best regards,
Kai

Describe the bug
When parsed, the order of xsd:elements and xsd:groups in a sequence are not respected.

E.g.,

    <xsd:sequence>
          <xsd:element name="elem1" type="xsd:decimal" />
          <xsd:group ref="myGroup" />
          <xsd:element name="elem2" type="Currency" />
    </xsd:sequence>

When running sequence.getElements() on the parsed result, this returns a list of three NamedConcreteElements, but in the wrong order:

• element named elem1
• element named elem2
• group named myGroup

I assume it is due to a bug in the following method defined in the XsdMultipleElements class:

    public void replaceUnsolvedElements(NamedConcreteElement elementWrapper) {
        if (elementWrapper.getElement() instanceof XsdElement){
            super.replaceUnsolvedElements(elementWrapper);
        }

        if (elementWrapper.getElement() instanceof XsdGroup){
            elements.add(elementWrapper);

            this.elements.removeIf(element ->
               element instanceof UnsolvedReference && compareReference(elementWrapper, (UnsolvedReference) element)
            );
        }
    }

Here groups are added to the end of the list while resolving references.

Expected behavior
I would expect the order to be retained.

Library Version
1.2.4

Hello,

I have problems with including an xsd file via an import.

My main XSD contains the following import:
<xs:import schemaLocation="dependency/second.xsd" namespace="second"/>

The import points to an XSD file located in a subfolder ("dependency") of the folder with the main XSD.

📁resources
|L 📁dependency
|  L second.xsd
L main.xsd

Other parsers (for example JAXB) can find and process the other imported second file without problems.

With XsdParser I get the following error when reading my main.xsd:

Sep. 25, 2019 7:41:39 AFTER. org.xmlet.xsdparser.core.XsdParser parseFile
SEVERE: Exception while parsing.
java.io.FileNotFoundException
	at org.xmlet.xsdparser.core.XsdParser.parseFile(XsdParser.java:77)
	at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:58)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:35)
	at Main.main(Main.java:17)

Exception in thread "main" java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.get(Optional.java:148)
	at org.xmlet.xsdparser.core.XsdParserCore.lambda$null$12(XsdParserCore.java:177)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at org.xmlet.xsdparser.core.XsdParserCore.lambda$resolveInnerRefs$17(XsdParserCore.java:174)
	at java.base/java.util.HashMap$KeySet.forEach(HashMap.java:928)
	at org.xmlet.xsdparser.core.XsdParserCore.resolveInnerRefs(XsdParserCore.java:164)
	at org.xmlet.xsdparser.core.XsdParserCore.resolveRefs(XsdParserCore.java:91)
	at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:62)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:35)
	at Main.main(Main.java:17)

When I remove the import, parsing works without problems. In the test to the namespaces I have seen that the path is given in relation to the project root. However, it cannot be expected that such path specifications are made in a "normal" XSD. An imported XSD file should (in my opinion) always be searched in relation to the importing XSD file.

By the way, thank you very much for this library! It saves me a lot of work.

In my use case I have several XSDs that import each other. However, the namespace location provided in the schemas is not accessible from the code (instead, the schemas are all resources in the class path, sometimes inside jar files, sometimes as files). Usually, this is solved by providing an XML Catalog that override the import statements. Now I don't think that this library needs to also support xml catalogs, but maybe it could be possible to somehow provide a custom lookup implementation that has a signature like public XsdSchema lookupSchema(String namespaceURL, String schemaLocation) and a Method to parse Schemas based on an InputStream public XsdSchema parse(InputStream inputStream)? This way, it should be possible to provide a lookup for imports in a fairly flexible way.

I tried to look into this, but it seems that there are quite a few dependencies on the file name in the parser core and was not able to easily refactor. So before spending some time trying to understand what would need to be changed, would you be willing to check if you think it would be feasible to attempt this and if you agree with the proposed modifications?

Hello. First thanks for this nice library.

I have a case like the following schema:

<xs:complexType name="customer">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Norwegian_customer">
  <xs:complexContent>
    <xs:restriction base="customer">
      <xs:sequence>
        <xs:element name="firstname" type="xs:string"/>
        <xs:element name="lastname" type="xs:string"/>
        <xs:element name="country" type="xs:string" fixed="Norway"/>
      </xs:sequence>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

Given the XSDRestriction object obtained as result of parsing the previous schema. Is there anyway to access the sequence contained inside such restriction?.

I try to create own xsd processor based on xsdparsercore.

public class InputStreamXsdProcessor extends XsdParserCore {
	public InputStreamXsdProcessor(List<InputStream> inputStreams) {
		this.parse(inputStreams);
	}

	public InputStreamXsdProcessor(List<InputStream> inputStreams, ParserConfig config) {
		super.updateConfig(config);
		this.parse(inputStreams);
	}

	private void parse(List <InputStream> inputStreams) {
		inputStreams.forEach(stream -> parseInputStream(stream));
		this.resolveRefs();
	}

	private void parseInputStream(InputStream inputStream) {
		try {
			Node schemaNode = getSchemaNode(inputStream);

			if (isXsdSchema(schemaNode)) {
				ConfigEntryData xsdSchemaConfig = parseMappers.getOrDefault(XsdSchema.XSD_TAG, parseMappers.getOrDefault(XsdSchema.XS_TAG, null));

				if (xsdSchemaConfig == null) {
					throw new ParserConfigurationException("XsdSchema not correctly configured.");
				}

				xsdSchemaConfig.parserFunction.apply(new ParseData(this, schemaNode, xsdSchemaConfig.visitorFunction));
			} else {
				throw new ParsingException("The top level element of a XSD file should be the xsd:schema node.");
			}
		} catch (SAXException | IOException | ParserConfigurationException e) {
			Logger.getAnonymousLogger().log(Level.SEVERE, "Exception while parsing.", e);
			throw new RuntimeException(e);
		}
	}

	private Node getSchemaNode(InputStream inputStream) throws ParserConfigurationException, IOException, SAXException {
		Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(inputStream);
		doc.getDocumentElement().normalize();
		return doc.getFirstChild();
	}
}```

I have multiple problems with this.
1. The XsdParserCore design is bad. I can't extend simple the XsdParserCore, I must put it to same package...
2. I can't access the elements and it's based on files, not namespaces and xsd content.
3. In the `XsdParserCore` we can't resolve the namespace in the dependent xsd because in the `resolveOtherNamespaceRefs` not based on the xsd targetNamespace, it's based on files

Hello,

first of all, thank you for creating this library, it is very appreciated!

Unfortunately though, v1.0.27 seems to have a problem with the validation of xs:maxInclusive if the value is set to one of the built-in calendar types such as xs:date, xs:dateTime or xs:gYearMonth.

I stumbled about this while trying to process one of our schemas (http://www.archivesportaleurope.net/Portal/profiles/eag_2012.xsd). Said schema features a few of xs:maxInclusive declarations, e.g. in lines 176, 181, 186, and 191. When trying to load a local copy of the file via the standard constructor (XsdParser(filepath)), the result was an error with the following stack:

org.xmlet.xsdparser.xsdelements.exceptions.ParsingException: The xsd:maxInclusive value  attribute should be a numeric value.
	at org.xmlet.xsdparser.xsdelements.AttributeValidations.validateDouble(AttributeValidations.java:149)
	at org.xmlet.xsdparser.xsdelements.AttributeValidations.validateRequiredDouble(AttributeValidations.java:163)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdDoubleRestrictions.<init>(XsdDoubleRestrictions.java:36)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.<init>(XsdMaxInclusive.java:24)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.parse(XsdMaxInclusive.java:34)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdRestriction.parse(XsdRestriction.java:118)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSimpleType.parse(XsdSimpleType.java:123)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdUnion.parse(XsdUnion.java:57)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSimpleType.parse(XsdSimpleType.java:123)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:158)
	at org.xmlet.xsdparser.xsdelements.XsdSchema.parse(XsdSchema.java:108)
	at org.xmlet.xsdparser.core.XsdParser.parseFile(XsdParser.java:100)
	at org.xmlet.xsdparser.core.XsdParser.parse(XsdParser.java:61)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:37)

It was a bit weird to see the attribute validation classes for Double values being called. Is this because counterparts for calendar values do not yet exist, or is something else to blame?

<xsd:element name="AgeRecommendation">
xsd:complexType
xsd:sequence
<xsd:element name="MinimumManufacturerAgeRecommended" type="MinimumAgeRecommendedDimension" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="MinimumAgeRecommendedDimension">
xsd:simpleContent
<xsd:extension base="xsd:nonNegativeInteger">
<xsd:attribute name="unitOfMeasure" type="AgeRecommendedUnitOfMeasure" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>

<xsd:simpleType name="AgeRecommendedUnitOfMeasure">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="months"/>
<xsd:enumeration value="years"/>
</xsd:restriction>
</xsd:simpleType>

i can not find the attribute name "unitOfMeasure" in this case

Hi,
I use xsdParser-1.0.24. Found an issue with namespaces -- XSD parsing fails, when namespace does not start with "http://".
Use case for such namespaces is ISO20022 where xmlns is kind of xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.08". You can look at ISO20022 site, camt.053 schema for instance).
So this sample XSD parses OK.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="Document" type="xs:string"/>
    <xs:simpleType name="AMLIndicator">
        <xs:restriction base="xs:boolean"/>
    </xs:simpleType>
</xs:schema>

But when I add xmlns="abc"

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="abc">
    <xs:element name="Document" type="xs:string"/>
    <xs:simpleType name="AMLIndicator">
        <xs:restriction base="xs:boolean"/>
    </xs:simpleType>
</xs:schema>

Parsing fails with the following error:

org.xmlet.xsdparser.xsdelements.exceptions.ParsingException: XsdSchema refers a namespace which was not imported.

Then I add "http://" and it parses well (with 0 unresolved elements):

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://abc">
    <xs:element name="Document" type="xs:string"/>
    <xs:simpleType name="AMLIndicator">
        <xs:restriction base="xs:boolean"/>
    </xs:simpleType>
</xs:schema>

Hi, I am not sure if this is a bug or if this is supposed to be cleaned out when parsing the XSD.

When calling element.getAnnotation().getDocumentations(), and the documentations are defined as follows:

	<xs:element name="someElement">
		<xs:annotation>
			<xs:documentation><![CDATA[
			CDATA line 1
			CDATA line 2
			]]></xs:documentation>
		</xs:annotation>
		<xs:simpleType>
			<xs:restriction base="xs:string">
				<xs:pattern value="[0-9]{9}"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>

Then each documentation.getContent() call returns an empty string. Is this a bug in the code or should I try to find a workaround for my perhaps too specific usecase?

I decided to open a new issue but it is related to this comment #25 (comment)

The problem is that we have a XSD (A) that includes another one (B) which in turn imports a third one (C).
Currently when A references something from C it is treated as a UnsolvedReference.

According to this post on StackOverflow it's not entirely clear whether this should be supported or not: https://stackoverflow.com/questions/13735887/use-type-from-xsd-imported-from-import

So this is a feature request: It'd be great if XsdParser could (maybe optionally) process transitive includes.

An union element can have the attribute memberTypes, which indicates the members of the union. They aren't resolved right now. Only the simple types as child of an union are considered.

Hello,

Is there a way to ignore an element? I have an XSD that contains a tag I'm not interested in, <osd:, and it would be nice to just ignore it. At the moment it is throwing parsing exceptions.

I'm thinking about creating a visitor for each element to ignore, but maybe you have a better solution.

Thanks

Greetings.

I have a project where I need to consume a lot of WSDL files and invoke some operations dynamically (without generating classes for it)

After I found this project, I don't need to resolve types myself anymore, so I thank you from the bottom of my heart.

The only things that I need to workaround are:

1. Frequently, the <schema> inside the WSDL comes as "simple tags", that is, instead of xsd:complexType I have only complexType. I solved this by pre-processing the xml and putting the correct tags.
2. I need to create a separate temporary file for each schema inside the WSDL, because XSDParser only accepts a filePath string.
3. Often I need to address some custom types by hand.

I wanted to know: is there are any plans to address something similar to my problem?

I took a look at the source code, and I came with some conclusions that could help me:

In XSDParserCore, move both parseMappers and xsdTypesToJava to a Defaults (or a better name) class, and allow users to pass their custom parseMappers and xsdTypesToJava to XSD Parser, if none is passed (or nulls), the default ones are used.

That would solve problem 1 and 3, but I don't know the full implications of this decision.

Describe the bug
The Unsolved References are not correct and there are multiple problems i encountered.
1.: the transitive includes are not correct, but there is a fix -> #58
2.: the includes are not considered on imported files, so they aren't resolved
example: a.xsd A import b.xsd B
b.xsd include c.xsd C
so if a.xsd use type B:TypeFrom C they are not include
3.: the unsolved elements are not always using the correct filename, they use the last filename in the parser. So the Problem is, there are
unsolved elements shown under filenames, that doesn't exist

Expected behavior
There are no Unsolved References.

Library Version
1.2.7

Additional context
Attach the XSD file or a similar example that you are trying to parse.
if i try to parse the BBK_RIAD_V2.4-SDMX.xsd, i encountered the Problem.

Describe the bug
Suppose I have file A.xsd which includes B.xsd which includes C.xsd which includes D.xsd. If I have a reference to D.xsd in A.xsd, it will not be resolved by the parser.

This is because transitive dependencies are implemented incorrectly: they are not implemented in a recursive way and will only include "one level" of transitivity, e.g., C.xsd in my example will be included, but D.xsd will not.

See the XsdParserCore class:

Set<String> transitiveIncludes = new HashSet<>();

for(String includedFile : includedFiles){
    parseElements.keySet()
             .stream()
             .filter(fileNameAux -> fileNameAux.endsWith(includedFile))
             .findFirst()
             .ifPresent(fullIncludedFileName -> transitiveIncludes.addAll(parseElements.get(fullIncludedFileName)
                  .stream()
                  .filter(referenceBase -> referenceBase instanceof ConcreteElement && referenceBase.getElement() instanceof XsdInclude)
                  .map(referenceBase -> (((XsdInclude) referenceBase.getElement()).getSchemaLocation()))
                  .collect(Collectors.toList())));
}

Expected behavior
I expect transitive dependencies to work correctly, i.e., transitively.

Library Version
1.2.6

Hello,

is it possible to register my own Xsd visitors for the Xsd parser?

Greetings
Ivo

Just unable to get access to version 1.2.2 with maven.

pom.xml file has
<dependency>
<groupId>com.github.xmlet</groupId>
<artifactId>xsdParser</artifactId>
<version>1.2.2</version>
</dependency>
in it and the maven project returns an error. However it is able to the find version 1.2.1

Hi,

first of all, thanks for this library. :)
I haven't found any other doing the same thing you do with your library.
I'm considering to use it in an application.

But one thing that prevents me from using it is the fact how exceptions are handled.

Every exception during parsing is caught inside the try/catch.
So a client using the library doen't know that something went wrong. :-(

In my opinion it'll be helpfull to propagate any exception as a runtime exception to clients in order that the client is able to react on that exception.

What I propose is...

to change this:

} catch (SAXException | IOException | ParserConfigurationException e) {
     Logger.getAnonymousLogger().log(Level.SEVERE, "Exception while parsing.", e);
}

into this:

} catch (SAXException | IOException | ParserConfigurationException e) {
     Logger.getAnonymousLogger().log(Level.SEVERE, "Exception while parsing.", e);
      throw new RuntimeException(e);
}

What do you think?
Shall I submit a pull request to change this?

<xsd:element name = 'hoursPerWeek' minOccurs='0' maxOccurs='1' type='xsd:double'> <xsd:annotation> <xsd:documentation xml:lang="en"> <ccts:DictionaryEntryName>F8C43CF9-9218-E611-80EA-000C292ED0D7</ccts:DictionaryEntryName> </xsd:documentation> </xsd:annotation> </xsd:element>

Above xsd:double inside a sequence inside a global named complexType is identified as an complexType.

First of all, thank you for contributing this library!

Now the issue:

In the README.md there's a simple usage example:

public class ParserApp {
    public static void main(String [] args) {
        String filePath = "Your file path here.";
        XsdParser parserInstance1 = new XsdParser(filePath);
        
        //or
        
        String jarPath = "Your jar path here.";
        String jarXsdPath = "XSD file path, relative to the jar root.";
        XsdParserJar parserInstance2 = new XsdParserJar(jarPath, jarXsdPath);

        Stream<XsdElement> elementsStream = parserInstance1.getResultXsdElements(filePath);
        Stream<XsdSchema> schemasStream = parserInstance1.getResultXsdSchemas(filePath);
    }
}

Calling the Lines:

        Stream<XsdElement> elementsStream = parserInstance1.getResultXsdElements(filePath);
        Stream<XsdSchema> schemasStream = parserInstance1.getResultXsdSchemas(filePath);

Is not possible, since there's no overload of those functions.
Correct is:

        Stream<XsdElement> elementsStream = parserInstance1.getResultXsdElements();
        Stream<XsdSchema> schemasStream = parserInstance1.getResultXsdSchemas();

Without the filePath. I've wondered about this redudancy, since the Parser gets the Paths.

getSimpleType on xsdRestriction suddenly fails after upgrade to latest version

  def simpleToType(xsdSimpleType: XsdSimpleType): String = {
    val base = xsdSimpleType.getRestriction.getBase
    if (base.startsWith("xs:")) base
    else {
      log.info("simpleType : " + xsdSimpleType.getName + " based on : " + xsdSimpleType.getRestriction.getSimpleType.getName)
      simpleToType(xsdSimpleType.getRestriction.getSimpleType)
    }
  }

I'm facing an issue parsing an xsd with xs:long in restriction, here my xsd file:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" id="PSS">
  <xs:simpleType name="IDContatto">
          <xs:restriction base="xs:long">
                <xs:minInclusive value="1"/>
                <xs:maxInclusive value="99999999999999"/>
          </xs:restriction>
     </xs:simpleType>
</xs:schema>

Here the code:

package org.xmlet.xsdparser;

import java.util.List;
import java.util.stream.Collectors;

import org.junit.Test;
import org.xmlet.xsdparser.core.XsdParser;
import org.xmlet.xsdparser.xsdelements.XsdElement;

public class MyXsdTest {
	private static final String WPFE_FILE_NAME = HtmlParseTest.class.getClassLoader().getResource("longTest.xsd")
			.getPath();
	private static final List<XsdElement> elements;
	private static final XsdParser parser;

	static {
		parser = new XsdParser(WPFE_FILE_NAME);

		elements = parser.getParseResult().collect(Collectors.toList());
	}

	@Test
	public void testElementCount() {
		// Assert.assertEquals(89, elements.size());
	}
}

and the exception here:

java.lang.ExceptionInInitializerError
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:217)
	at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:263)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
Caused by: java.lang.NumberFormatException: For input string: "99999999999999"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:583)
	at java.lang.Integer.parseInt(Integer.java:615)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdIntegerRestrictions.setFields(XsdIntegerRestrictions.java:34)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.<init>(XsdAbstractElement.java:71)
	at org.xmlet.xsdparser.xsdelements.XsdIdentifierElements.<init>(XsdIdentifierElements.java:19)
	at org.xmlet.xsdparser.xsdelements.XsdAnnotatedElements.<init>(XsdAnnotatedElements.java:21)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdIntegerRestrictions.<init>(XsdIntegerRestrictions.java:21)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.<init>(XsdMaxInclusive.java:23)
	at org.xmlet.xsdparser.xsdelements.xsdrestrictions.XsdMaxInclusive.parse(XsdMaxInclusive.java:33)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:138)
	at org.xmlet.xsdparser.xsdelements.XsdRestriction.parse(XsdRestriction.java:133)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:138)
	at org.xmlet.xsdparser.xsdelements.XsdSimpleType.parse(XsdSimpleType.java:106)
	at org.xmlet.xsdparser.xsdelements.XsdAbstractElement.xsdParseSkeleton(XsdAbstractElement.java:138)
	at org.xmlet.xsdparser.xsdelements.XsdSchema.parse(XsdSchema.java:114)
	at org.xmlet.xsdparser.core.XsdParser.parseFile(XsdParser.java:278)
	at org.xmlet.xsdparser.core.XsdParser.<init>(XsdParser.java:254)
	at org.xmlet.xsdparser.MyXsdTest.<clinit>(MyXsdTest.java:17)
	... 22 more

I saw that you consider all restrictions only as integer in the class XsdIntegerRestrictions , it's possible to consider also another numeric types, like long ?

I ma having problems parsing the XSD in windows. There are a lot of missing attributes:

In MacOs:

In Windows with the same code, same input XSD, and same JDK version, at same code line:

I don't know how to investigate the problem.

Thanks a lot.

  <xs:simpleType name="Max35Text">
    <xs:restriction base="xs:string">
      <xs:minLength value="1"/>
      <xs:maxLength value="35"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="Max35Text_CH_camt052">
    <xs:restriction base="Max35Text">
      <xs:minLength value="1"/>
      <xs:maxLength value="35"/>
      <xs:pattern value="[A-Za-z0-9+?/:()\.,&apos;\-]*"/>
    </xs:restriction>
  </xs:simpleType>

what I try :

def simpleToType(xsdSimpleType: XsdSimpleType): String = {
    val base = xsdSimpleType.getRestriction.getBase
    if ( base.startsWith("xs:")) base
    else {
      println(xsdSimpleType.getName+" from base "+xsdSimpleType.getRestriction.getBase)
      println(xsdSimpleType.getRestriction.getSimpleType)
      xsdSimpleType.getRestriction.getSimpleType.getRestriction.getBase
    }

Output :

Max35Text_CH_pacs028 from base Max35Text
null

I get an exception "XsdSchema refers a namespace which was not imported." while parsing the following valid XSD file:

<?xml version="1.0" ?>
<xsd:schema elementFormDefault="qualified" targetNamespace="urn:com/example/mynamespace" xmlns:mynamespace="urn:com/example/mynamespace" version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:simpleType name="type">
		<xsd:restriction base="xsd:string" />
	</xsd:simpleType>
	<xsd:simpleType name="anothertype">
		<xsd:list itemType="mynamespace:type" />
	</xsd:simpleType>
</xsd:schema>

It seams, that XsdParser doesn't like targetNamesparce and its namespace declaration.