Variant: Remove JSON conversion table

[rdblue]

Rationale for this change

I've talked with several community members that intend to implement JSON conversion, but do not want the conversion specified in the Variant spec to be required. If the conversion is not required, I don't think that it makes sense to add it to the spec.

The conversion was originally added because we wanted to ensure that engines that do not support Variant could interact with the data. At the time, it seemed like a good idea to standardize how conversion to JSON took place for those engines. But there is necessarily data loss when converting to JSON. It's hard to decide just how lossy this conversion (to JSON and back) should be and what value there is to minimizing the loss. That's why people don't intend to implement a consistent well-defined conversion. Without willingness to follow this section of the spec, it should be removed.

What changes are included in this PR?

Remove the JSON conversion table and section from the Variant spec.

Do these changes have PoC implementations?

No. The conversions in this table were never implemented.

[emkornfield]

I still believe the best course of action is to move this to an appendix and make it clear that is optional. Otherwise there are cases where engines might diverge needlessly (e.g. special values for double, and bytes encoding). But I'm OK removing it.

[rdblue]

I still believe the best course of action is to move this to an appendix and make it clear that is optional. Otherwise there are cases where engines might diverge needlessly (e.g. special values for double, and bytes encoding). But I'm OK removing it.

Does it matter if behavior differs? If it does, then I'm fine keeping this as required so that it doesn't diverge. But if this is optional, it doesn't help prevent divergence.

[emkornfield]

Does it matter if behavior differs? If it does, then I'm fine keeping this as required so that it doesn't diverge. But if this is optional, it doesn't help prevent divergence.

I don't think the statement is a binary here. In practice it probably doesn't matter, but it still doesn't mean that we wouldn't necessarily want consistency here. It becomes an implementation details, but in the absence of a common guide different implementations might choose slightly different representations, not for any good technical reason but simply because it is arbitrary (i.e. "Inf" vs "Infinity"). This is why I think an appendix on implementation notes, that indicate this is one possible way of translating data and is recommended but not required makes sense to me. This is not part of the spec, but that doesn't mean that providing guidance is not beneficial.

[rdblue]

This is not part of the spec, but that doesn't mean that providing guidance is not beneficial.

But what is the value if that guidance is not reliable? If you're going to choose an arbitrary thing like "-Inf", then it needs to be done that way everywhere. You can't also allow "Inf (but _not_ the positive one)" because people can't rely on the recommendation. If it is something for compatibility, it should to be required. Otherwise it doesn't add compatibility.

[rdblue]

I talked with Micah on Slack. We agreed that we can have a larger discussion on the mailing list, but can merge this now. Since this is probably not going to be a hard requirement, I think we should remove it and add it back later rather than leave it in until the discussion concludes.