quick-xml v0.27+ changed behaviour when writing empty values

[decathorpe]

I'm using quick-xml for my XML-RPC crate (dxr) and I've been a happy user so far, thank you for maintaining the crate!

I'm trying to update my quick-xml dependency to a newer version (dxr is currently stuck at v0.25), but I'm hitting a roadblock. It looks like the new serde serializer that was implemented for v0.27 changed some behaviour when writing empty values.

For example, it now writes self-closing XML tags - previously, I got <value><string></string></value> for an empty string value, but with quick-xml v0.27+, I get <value><string/></value>. While this is technically valid XML, my library cannot write self-closing tags like this in order to maintain compatibility with other XML-RPC implementations (some older ones don't accept self-closing XML tags).

Is there a way to get back the old behaviour (i.e. deserialize an empty $value to <foo></foo> instead of <foo/>?

[dralley]

It doesn't look configurable, currently. I'm sure it could be, though, if that is useful / necessary functionality.

https://github.com/tafia/quick-xml/blob/master/src/se/element.rs#L68-L75

[Mingun]

Yes, I'm happy to accept a PR which makes this configurable. I suggest Serializer::expand_empty_elements(enable: bool), like the same-named option for a parser, false by default

[decathorpe]

I can try to work on this. But how would that integrate? I'm currently just doing quick_xml::se::to_string(&value), and I don't want to have to write a custom serializer implementation.

[Mingun]

You will need to instantiate Serializer manually unstead of using helper function. To find the right place for tests you can first add necessary changes without the setting and see what tests are failed in serde-se, then implement setting and add new tests nearby to failed ones.

[bahlo]

@Mingun Do you think a feature flag would work for this as well instead of a serializer option?

@decathorpe Did you start with this already? I can take a stab unless you want to ✌🏻

[decathorpe]

I haven't had the time to look into it yet, so if you want to take a stab at it, that would be great 👍🏻

[Mingun]

@bahlo, because cargo features is additive, having this as a feature option could break somebody who will (transitively) depend on two crates with different requirements. I think, that usual setting will be enough. I believe that disabling producing of self-closed tags is a niche feature, so shortcut function is not necessary (but you could write one in your own crate).