Way to configure list serialization type

[Kakadus]

The default of xsd-parser is to use a Vec tuple struct for lists:

#[derive(Debug, PartialEq, Eq, Serialize, Deserialize)]
pub enum MyType {
    #[serde(rename = "A")]
    A,
    #[serde(rename = "B")]
    B,
}

#[derive(Debug, PartialEq, Eq, Serialize, Deserialize, Default)]
pub struct TestListType(pub Vec<MyType>);

which creates an xml such as <test>A</test><test>B</test>.

Schema:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd">
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:simpleType name="myType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="A"/>
            <xs:enumeration value="B"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="testList">
        <xs:list itemType="myType"/>
    </xs:simpleType>
</xs:schema>

with the generated code from RenderStep::TypesSerdeQuickXml.

However, quick-xml also allows to generate xml lists separated by whitespaces, like <test>A B</test>:

#[derive(Debug, PartialEq, Eq, Serialize, Deserialize, Default)]
pub struct TestListType {
    #[serde(rename = "$text")]
    pub content: Vec<MyType>,
}

Is there a way to configure xsd-parser to change the list serialization format for specific types? That would be really cool.

[Bergmann89]

Hey @Kakadus,

unfortunately that's not possible right now, but I think your suggestion could be implemented relatively easy. Maybe we can stick to the unit struct and use this instead:

#[derive(Debug, PartialEq, Eq, Serialize, Deserialize, Default)]
pub struct TestListType(#[serde(rename = "$text")] Vec<MyType>);

I will make a short test later.

[Bergmann89]

Ah Ok. Yeah, then we have to use the extra content field.

This is the place where the list type gets rendered. Internally it is represented as ReferenceData with the occurs field set to Occurs::DynamicList. Simply adding a suitable if-statement to render the truct instead the tuple struct should be enough, but to be compatible to all other parts of the generator you have to patch all type renderer steps and also the code that is generated for the direct quick_xml de/serialization.

A more cleaner, but also more complex solution, would be to introduce a separate List variant for MetaTypeVariant instead of relying on the Reference variant. Actually this is maybe the better solution because currently the lists are really just a reference to another type (with multiple occurrences) but if we change the behaviour of this list type, then it should have a suitable type representation in the code as well.

[Kakadus]

Thanks for the hints! After digging a bit into the code, I found that this is already done when using quick_xml without serde by checking the is_list property. I don't think there is any need for a List variant - checking for self.meta.is_list should suffice

[Bergmann89]

Yes, the build-in direct quick_xml de-/serialization is more flexible and support more features, than the serde quick_xml implementation.

Just wanted to mention that using is_list at runtime may break the code that is generated in other renderers. If you have an explicit list variant, then you get a compiler error if you didn't handle it in the renderer. So having to a solution that uses is_list is fine for now. The type safetyness can be implemented later when I do a refactoring, because there are also some other parts of the code that would profit from some explicit type definitions instead of runtime checks.

[Kakadus]

I wanted to add the extra field only with the serde renderers, but I ran into the problem that the default value is prepared in the generator already and when using the extra field, it needs to be defined differently. That effectively means that the extra field will then become necessary for all list structs in all renderers...

[Bergmann89]

This is what I meant in my post above: The renderers are depending on each other (maybe I could have given a better description). The actual goal of the data types is to define suitable rust related types (wether if it's a struct or a enum, how many fields or variants, ...) and the renderer then only renders the actual code uppon these definitions. So yes, if you want to make the list a struct with one field, this should be defined in the data types to have the same structure accross all renderers.