Clarify relationship between custom scalars and serialization formats

[martijnwalraven]

We've had some discussions about differing interpretations of serializing custom scalars, so I was wondering what other people's thoughts about this are.

Section 7.1 (Serialization Format) of the spec lists a number of required and optional primitives that may be used to serialize values:

[T]he serialization format must support representations of the following four primitives:

• Map
• List
• String
• Null

And:

A serialization format may support the following primitives, however, strings may be used as a substitute for those primitives.

• Boolean
• Int
• Float
• Enum Value

Is this meant as an exhaustive list? Or can serialization formats add support for additional primitives?

Because built-in scalars have a predefined mapping to one of the listed primitives, this only seems relevant for custom scalars.

So I think the question comes down to: are custom scalar values always eventually coerced into one of the primitives listed in the spec? Or can custom scalars be defined on top of arbitrary types, and leave the encoding to a serialization mechanism that comes after execution?

Specifically, this came up in the context of encoding Date and Time in CBOR. The idea would be that resolvers can return language-specific types (such as a JavaScript Date or java.time.Instant), and instead of defining a custom scalar that would coerce these to a string, it would leave them as is and allow the serialization format to choose a more specific encoding, that may be more efficient or more semantically correct. The downside of that seems to be that it forces serialization mechanisms to be aware of these additional types (so you may not be able to just use JSON.stringify in JavaScript for example), which may be a source of incompatibilities.

[leebyron]

The intent was not for this list to be exhaustive, just to be a suggestion for a standard set. (Note JSON doesn't even hit this standard set)

More specific primitives should definitely be used if available for relevant custom scalars. I'll add some copy to clear this up

[pm-dev]

@leebyron
You wrote:
(custom scalars) may be represented in whichever relevant format a given serialization format may support

Has there ever been discussion around schematizing the primitives that are native to a given serialization format?

A concrete example:
When defining a custom scalar, say Timestamp, it would be nice to know from the schema what that will be serialized as. Assuming my serialization format was json, I'd wonder if this would be coerced to a string or number in a response. Unfortunately, we cannot schematize this unless some other information, such as the primitive types native to the serialization format, is also schematized.

Seems like this could be powerful feature, because today a graphQL server could change how a scalar is coerced "under the hood" without changing the schema, and yet clients would break.

Side note, scalars like ID which accept string or ints as input would require this rfc before something like this is possible https://github.com/graphql/graphql-wg/blob/master/rfcs/InputUnion.md