Linguistically this doesn't make much sense. This layer doesn't sit between serialization formats. I'd say "abstraction layer for serialization formats".

supports

I would add a bit more explanation on the very basics of the design. Mention how this can be used by other formats (by implementing a custom formatter using Formatter as base class), how data is modeled (what kind of primitives are supported and how ObjectValue can be used), is the order of items preserved when writing back to disk, how is versioning handled, etc.

If it becomes more than a few lines then it can just become a link to the Wiki.

oeps

Shouldn't this be \see?

Using uint64_t is error-prone for a type named IntValue with eValueType::Int.

https://stackoverflow.com/a/13502497 suggests that JavaScript numbers roughly have a range of ±2**53, so int64_t will be sufficient.

Any reason to use float instead of double for JSON? This should be documented.

Why are std::shared_ptrs used here?

Something as abstractly named as "Value" really needs documentation as to what it is and what it's for.

Code-style says to use a trailing, not a leading _ for private/protected members: https://wiki.blender.org/wiki/Style_Guide/C_Cpp#Class_data_member_names

Either add explicit or document why this constructor should not be explicit.

I feel that these should get some documentation as to what they return, and in which scope they're valid. Is the code expected to check the type, before calling any of these? Who owns the returned pointer?

These need documentation. What they do, but also what happens when the Value is not of the required type. Does that raise an exception? Return nulltpr? Produce invalid results?

Documentation, certainly about the template variables. It also needs to explain what "primitive" means; after all, eValueType is not named ePrimitiveValueType, so there must be some value types that you cannot use here.

Same code style fix needed for these other private variables 😛

Remove "Helper function to"

Remove "Helper class for"

Instead of "internal" I'd call it "wrapped"; "internal" to me sounds too much like it's an implementation detail, but it's also part of the public interface of the type.

be

key-value

Better default-initialize primitive values:

T inner_value_{};

Otherwise on a default construction for example, this would be uninitialized.

This template is quite confusing, could we at least have an alias for std::pair<std::string, std::shared_ptr<Value>?

Think this should be explicit.

Why is this a std::shared_ptr? Who owns the values? Who is expected to be sharing the values?

There must be a virtual destructor here, even if it's an abstract class.

Document

Why does the value need to be mutable in order to serialize it? What modifications will this function do? Either make it const, or use a pointer so that at the call itself it's clear that the function can modify the value.

Document

Unless the full 0-255 range is needed, use int8_t instead. It'll give much more sensible erroneous results when there is some off-by-one error somewhere; invalid negative values can be tested for, but invalid wrapped-around-so-still-valid values cannot.

This function should be named value() (so it's consistent with IntValue::value()) and not string_value(). Otherwise it's unclear when you see an invocation like this:

j = value.as_string_value()->string_value();

as_string_value() already returns a "string value", so it's not immediately clear what different kind of "string value" would be returned by string_value().

Very minor suggestion: I prefer using the single line syntax for such short doxygen comments:

/** Short description, blah blah. */