-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Element ref not resolved correctly #72
Comments
Digging further. This is probably related to working on Windows. I've noticed the |
This method is the culprit. public void addUnsolvedReference(UnsolvedReference unsolvedReference) {
XsdSchema schema;
try {
schema = XsdAbstractElement.getXsdSchema(unsolvedReference.getElement(), new ArrayList<>());
} catch (ParentAvailableException e) {
schema = null;
}
String localCurrentFile = currentFile;
if (schema != null) {
String schemaFilePath = schema.getFilePath();
if (!localCurrentFile.equals(schemaFilePath)) {
localCurrentFile = schemaFilePath;
}
}
List<UnsolvedReference> unsolved = unsolvedElements.computeIfAbsent(localCurrentFile, k -> new ArrayList<>());
unsolved.add(unsolvedReference);
} Since |
This is not the first time I see issues in this library related to a poor handling of file paths. (slash versus backslash, relative versus absolute, ...) I wonder if it's doable to properly clean that up, for example (but not limited to) by using normalized Java |
Hello Simon, Thanks for the issue and for using the library. Also thanks for the investigation, while I agree that the file paths are a mess in the library I'm not entirely sure that's the source of your issue. The issue is that the cloned XsdElement myElem doesn't yet the type resolved, which means that while eventually the instance I used to generate the clone will have the type resolved in the next iteration, the cloned instance never will. This might be solved by solving the type references first and only then other references. I've added the following line in XSDParserCore#resolveInnerRefs at 464:
Here: Please check on your side if that fixes your issue. |
I can do you better: I can verify that normalizing the My current workaround: public void addUnsolvedReference(UnsolvedReference unsolvedReference) {
XsdSchema schema;
try {
schema = XsdAbstractElement.getXsdSchema(unsolvedReference.getElement(), new ArrayList<>());
} catch (ParentAvailableException e) {
schema = null;
}
String localCurrentFile = currentFile;
if (schema != null) {
String schemaFilePath = schema.getFilePath().replace("\\", "/"); // SEE FIX HERE
if (!localCurrentFile.equals(schemaFilePath)) {
localCurrentFile = schemaFilePath;
}
}
List<UnsolvedReference> unsolved = unsolvedElements.computeIfAbsent(localCurrentFile, k -> new ArrayList<>());
unsolved.add(unsolvedReference);
} |
I might be missing something but that replace alone doesn't seem to solve the problem with your sample xsd. I'm on windows if that makes any difference. I've created a file issue_72.xsd with your example and created the following test: Test code: @Test
public void testIssue72() {
XsdParser xsdParser = new XsdParser( getFilePath("issue_72.xsd"));
XsdComplexType documentComplexType = xsdParser.getResultXsdSchemas().findFirst().get().getChildrenComplexTypes().filter(e -> e.getName().equals("Document")).collect(Collectors.toList()).stream().findFirst().get();
XsdElement sequenceElement = documentComplexType.getChildAsSequence().getChildrenElements().collect(Collectors.toList()).stream().findFirst().get();
} With my solution this doesn't happen. Resolving the cloned references wasn't really right, because if I first resolve references that clone elements that themselves have unsolved references in the end it won't be correctly resolved because I don't solve the unsolvedReferences of the clones. And like you said, the solution is already pretty hardcoded with backslashes and slashes, I'd rather not have more if I can avoid them. |
Hmm, perhaps I minimized the example too much. The actual schema I was working with is this one. Note the <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- XML root element -->
<xs:element name="document" type="Document" />
<xs:complexType name="Document">
<xs:sequence>
<xs:element ref="animal"/> <!-- Note that the name of this element is determined by the actual type of animal -->
</xs:sequence>
</xs:complexType>
<!-- Element names: `Cow`s should be serialised as an element named `cow`, `Goat`s should be serialised as an element named `goat`. -->
<xs:element name="animal" type="Animal" abstract="true" />
<xs:element name="cow" type="Cow" substitutionGroup="animal" />
<xs:element name="goat" type="Goat" substitutionGroup="animal" />
<!-- Types: `Cow` and `Goat` extend from `Animal` -->
<xs:complexType name="Animal">
<xs:attribute name="name" type="xs:string" />
</xs:complexType>
<xs:complexType name="Cow">
<xs:complexContent>
<xs:extension base="Animal" />
</xs:complexContent>
</xs:complexType>
<xs:complexType name="Goat">
<xs:complexContent>
<xs:extension base="Animal" />
</xs:complexContent>
</xs:complexType>
</xs:schema> Perhaps there are two issues then. My own issue was resolved with
This is not true though - I have stepped through the code. Upon cloning an |
You are right, but due to the stop condition of having the same number of UnsolvedReferences after iterating the list the resolveInnerRefs will stop resolving, at least with the first example you've provided. Anyway adding the sort will always be an improvement, by ordering I'll avoid generating unnecessary UnsolvedReferences in clones which will make it faster to parse. I can't really replicate your issue, but then again I'm on Windows. Since your suggested solution doesn't seem to break any of the existing tests I'll add it, together with the improvement I mentioned above. Would that work for you? |
I'm on Windows too, actually, so I'm surprised it's not possible to replicate. But yes, I agree it might make things more efficient, and yes, if you can add that replacement in that would be great! Cheers. |
Great! The new version is available, 1.2.16. If you find any other issues let me know. |
Describe the bug
A forward reference to an element results in an unresolved reference for the type of that element.
Consider the following schema:
This correctly results in a complex type
Document
with a single elementmyElem
, but the type of the element -Foo
- is not resolved.There are two references which should be resolved here:
ref="myElem"
andtype="Foo"
.I did some debugging and I think the reason why this is currently not working is as follows:
UnsolvedReference
.ref="myElem"
, a copy of the target element is made. SeeXSDParserCore#replaceUnsolvedReference
line 560:type="Foo"
.Expected behavior
I would expect no unresolved references.
Library Version
1.2.15
The text was updated successfully, but these errors were encountered: