Generated serializer unconditionally emits xmlns:xsi on root element

[rcbevans]

When NILLABLE_TYPE_SUPPORT is enabled, every generated root-element serializer emits xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" unconditionally, even when no xsi:nil or xsi:type attributes exist in the document being serialized.

Where

xsd-parser/src/pipeline/renderer/steps/quick_xml/serialize.rs, the NamespaceSerialization::Global branch (lines 731-797).

The codegen decides at code generation time whether to emit xsi based on the generator flag:

let need_xsi_namespace =
    nillable_type_support && !collector.provides_xsi_namespace();

This generates code that unconditionally writes xsi on every root element:

if self.is_root {
    helper.write_xmlns(
        &mut bytes,
        Some(&super::super::PREFIX_XSI),
        &super::super::NS_XSI,
    );
}

There is no runtime check for whether any nillable field actually contains a nil value in the current document instance.

Effect

Serialized output includes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" on the root element even when:

• The schema has no nillable="true" elements at all
• The schema has nillable elements but the current instance has no nil values

This pollutes the namespace context for all descendant elements. In particular, xs:any content deserialized as Element captures all in-scope namespaces via helper.namespaces(). After a serialize/deserialize round-trip, extension elements gain an xsi namespace entry that was not present in the original document, breaking equality.

Expected behavior

The xsi namespace should only be emitted when the serialized output actually contains xsi:nil or xsi:type attributes.

Workaround

For schemas that have no nillable elements, remove the flag:

generator_flags.remove(GeneratorFlags::NILLABLE_TYPE_SUPPORT);

[Bergmann89]

Hey @rcbevans,

the serializer is currently evaluated completely during generation time and does not support any runtime checks, to be able to generate a stream of events. Adding a runtime check if the xsi namespace (or any other namespace) is needed, would need a major change of the current serialization approach . As a first improvement I would just check during generation time, if the current element needs the xsi namespace or not (by checking if one of it's dependencies needs it).

If this is done, we may add another variant to NamespaceSerialization (like Dynamic), that traverses the tree to extract the needed namespaces during runtime instead of hard coding it to the element during generation time.

[Bergmann89]

Hey @rcbevans,

I've implemented namespace evaluation at runtime using NamespaceSerialization::Dynamic. Feel free to have a look 😊

[Qix-]

Is there some example about how to use this? Seeing the same thing; xsi namespace. Further, it doesn't appear that .with_namespace() during the build step does anything; the <prefix>:xmlns="..." attribute is never emitted on the root element.

[Bergmann89]

Hey @Qix-,

yes, you can have a look to the integrations tests here, here and here (the links points to the generate method, you'll find suitable read and write tests below).

The nillable test (see last link) has two test cases, one that is emitting the xmlns:xsi and one that doesn't.

.with_namespace makes a namespace available to the generator, but it will only emit namespace attributes for namespaces that are actually needed for the particular type that is serialized.