Design for Data Model Extensibility

[mitsuhiko]

There are many situations where libraries want to add support for data types not native to a serialization library. The following use cases are known but do not have equivalents in the data model today:

• i128 / u128
• DateTime and DateTime<Tz>
• UUID
• Decimal
• BigNum

Additionally there are cases I ran into in the past where for a compound type additional information would have been useful too for instance to distinguish sets from vectors.

Today serde relies on in-band signalling to pass such data. Preferable there is a better way to accomplish this.

[vmx]

Additionally there are cases I ran into in the past where for a compound type additional information would have been useful too for instance to distinguish sets from vectors.

Related to this one are "tagged values". Some formats (e.g. CBOR) have the ability to arbitrarily tag their values with additional information. This can be things like distinguish sets from vectors, "this string represents a date", or "these bytes represent a hash". For more information, there was also a discussion about it on the Serde repo: serde-rs/serde#1643 (having worked more with Serde, I now have a better understand why they don't want to add it to Serde, but I think having a serialization library supporting this without hacks would be great).

Those tags could then also be ignored, in case your (de)serializer doesn't support it. E.g. if you deserialize from CBOR with tags into the internal data model, but then serialize into JSON.

So I see two use cases, but I guess they could use the same mechanism. The one I describe above is additional information, which is used to signal something between a serializer and deserializer of a single format. And the other one, outlined in the original issue, is signaling some type that different (de)serializers could agree one.