External Serialization?

[cdrnet]

Currently types like Point2D implement IXmlSerializable and also include helper fields like SerializeAsElements.

I tend to prefer external serialization approaches, i.e. an external serializer that can format specific objects or collections of them into XML, binary or other formats. Fields like SerializeAsElements would no longer be needed. To my understanding there already is a partially external serializer to a custom text format.

• What is the motivation for implementing IXmlSerializable?
• Is there a specific scenario that requires this?

[JohanLarsson]

I don't understand what you mean by 'external serialization'

• The reason for implementing IXmlSerializable is due to the types beeing immutable, AFAIK it is the only way to make immutable types compatible with XmlSerializer
• The reason for SerializeAsElements is that we have legacy xml with points serialized element and attribute style. This is perhaps not nice in a general library.
• Do you mean the Parse() when you say custom text format? The reason for parse is mainly that [TestCase] will read nicely in the testrunner.

[cdrnet]

With internal serialization a type is responsible for its serialization (ISerializable, IXmlSerializable; .Net 1), with external serialization you typically have some static class or object that converts between different representations (e.g. ProtoBuf, Json, System.Runtime.Serialization, .Net 4). External serializers sometimes use data contract attributes to delegate the control back to the type.

The problem with serialization is that this is usually very application specific. You mentioned you have some legacy requirements regarding attributes vs elements, other users may have different requirements. Then we have parse logic that works well with the tests. In short, serialization cannot really be a responsibility of the type but of the application and use case.

In Math.NET Numerics we use external serialization exclusively, e.g. to convert between matrices and CSV, MatrixMarket or MATLAB binary streams/files.

A disadvantage of a pure external approach is that it does not integrate well with internal serializers but requires some manual work, e.g. when including points in a complex object tree that is required to be XML-serializable. I take it this is one of your scenarios?

In your particular application, do I understand it correctly that you require the same type to be serialized in either element or attribute style on case by case basis? Is this consistent within a serialized tree, or are there mixed cases where both happens within the same tree that is to be serialized?

[JohanLarsson]

• We can remove the SerializeAsElements flag and I'll handle it in our stuff, the flag is ugly. Serialize everything as elements then right?
• The parse methods can be removed from the types but I think I like them as is just relaying the call to Parser. I have no strong opinion on this.
• Stuff like exporting to CSV or Mathlab makes sense to have as external. I think implementing IXmlSerializable has elements of nice.

[cdrnet]

Great! Personally I prefer attribute style as it is more compact and closer to SVG but I'll let you decide.

Ok, let's keep the types IXmlSerializable and the static Parse methods.

[JohanLarsson]

I removed the flags, probably forgot some. I kept ReadXml handling both element and attribute style.