Consider offering XML serialization as separate product

[JKSnd]

The project I'm using mathnet spatial for uses json for serialization instead of xml. It isn't ideal that my project takes on an xml dependency that is never used.

Can serialization be broken out into a separate nuget package?

[JohanLarsson]

How do you suggest doing this given how XmlSerializer works? I agree that the dependency on Sytem.Xml is not ideal.

[JKSnd]

I would move the responsibility of XML serialization into a set of data transfer objects (DTOs) and use a mapping layer to convert between the core types and the DTOs. This pattern could then be used to add JSON serialization similarly.

Then a developer could add serialization support to their project through Nuget by installing MathNet.Spatial.Serialization.Xml, for example. Units.Net does something similar.

[Jones-Adam]

I can move support for serialization from the system.runtime.serialization (DataContracts etc) into a separate (.netstandard2.0 - possibly 1.6) assembly (and at the same time improve serialization support). This is fairly straight forward and works well and as you say should extend to being able to support json too.

However, with regards to the native XmlSerializer even with DTOs the use experience is not great as you cannot (at least as far as I can find) intercept the type lookup for nested types. This would mean converting a type tree into a surrogate type tree before serializing and back again after deserialization. This would only work if you were serializing the objects as standalone objects but would fail in the case you embedded a geometry type into your own serializable class. Not really an ideal experience. An option would be to drop support for XmlSerializer and either just support data contracts or also support a 3rd party xml serializing solution like ExtendedXmlSerializer in order to be able to keep existing format compatibility for people who have saved representations of the current types.

Another thing to keep in mind is that the current xml serialization support is incomplete with not all types in the library supporting serialization, so either way there is something to be addressed here.

[JohanLarsson]

How big problem is the dependency on System.Xml? I agree it is not nice but can be convenient. Next question is how big is the upside?, I don't know if XmlSerializeris used much.

@AQuentin2033 Agreed we should have all types implement IXmlSerializable if we have the dependency.

[JohanLarsson]

Not that it matters much for anything but nodatime does things the same way we do.