Generated code does not accept derived types where the base type is expected

[giacomo618]

The generated code with xsd-parser 1.5.2 fails to accept a derived type where the base type is expected. For example, the following schema uses xs:extension to create a derived type ConcreteDocument from AbstractDocument:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"
	attributeFormDefault="unqualified">

	<xs:complexType name="AbstractDocument" abstract="true" />

	<xs:complexType name="ConcreteDocument">
		<xs:complexContent>
			<xs:extension base="AbstractDocument">
				<xs:sequence maxOccurs="unbounded">
					<xs:element name="info" type="xs:string" />
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

	<xs:element name="document" type="AbstractDocument"/>
</xs:schema>

and the following xml uses xsi:type to specify the type of the instance as ConcreteDocument

<?xml version="1.0" encoding="utf-8"?>
<document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ConcreteDocument">
	<info>some info</info>
</document>

The code generated with

Config::default()
        .with_schema(Schema::File("my-schema.xsd".into()))
        .with_interpreter_flags(InterpreterFlags::all())
        .with_optimizer_flags(OptimizerFlags::all())
        .with_generator_flags(GeneratorFlags::all())
        .with_quick_xml();

defines Document as an alias to AbstractDocument, which is an empty struct. Thus, Document::deserialize fails when encountering the info element:

Error { kind: UnexpectedEvent(Start(BytesStart { buf: Owned("info"), name_len: 4 })), position: Some(139), elements: Some(["document", "info"]) }

I expected the generated code to define AbstractDocument as an enum with variants for each derived type, similarly to how substitution groups are handled for xsd-parser/tests/optimizer/abstract.xsd in xsd-parser/tests/optimizer/expected1/convert_dynamic_to_choice.rs or to use Any like in xsd-parser/tests/optimizer/expected0/convert_dynamic_to_choice.rs.
Is there a way to generate code able to accept derived types in place of the base type or is this at the moment unsupported?

[Bergmann89]

Hey @giacomo618,

thanks for reporting. This should actually work as you expected it. I will check what's wrong here and report back.

[Bergmann89]

It looks like this isn't actually supported at the moment. I also realized that I mixed up substitution groups and abstract types while investigating this.

I'll add dedicated test cases covering both features and then implement proper support for each of them. This will likely take a few days, though.

[Bergmann89]

Hey @giacomo618,

Just a quick update: I had a few hours to work on this today and managed to implement a solution that looks promising.

It's not quite finished yet. The quick_xml serialization/deserialization tests are still failing, and I'd also like to add an new optimization step that allows substitution group elements and dynamic types to be stored in the same Box. That should make the generated API much easier to work with for schemas that use both mechanisms together.

I expect to have everything wrapped up sometime next week. In the meantime, I wanted to share the current state in case you'd like to take a look already: #276

[Bergmann89]

Hey @giacomo618,

I've finally wrapped up the work on this improvement. It should now behave as proposed. I also added a few extra tests that demonstrate how to use it. Feel free to give it a try and let me know how it works for you.

[giacomo618]

Thanks a lot for taking the time to look into the issue. I have tested the changes and I was able to parse XML files containing dynamic types. However, I had to use with_dynamic_types for each and every base type used, which for real-world schemas can be a lot of types. Is there a workaround? My use case would be to generate code from the FIXM schema and its extension.

[Bergmann89]

Hey @giacomo618,

thanks for the feedback. Yes, this is still an issue. I'm not 100% sure how to address this, because the schema does not provide the information if a type needs to be handled as dynamic type or normal type (expect it is explicitly marked as abstract). In a real object oriented language (like C++, C#, Java) this wouldn't be an issue, because you can simply derive your types, but in rust we need to have this information, to decide if we need to implement a normal type or a boxed dyn type.