Are function extensions defined in the spec mandatory?

[glyn]

The spec defines a number of function extensions which will become the initial entries in the IANA sub-registry. Are these extensions optional for JSONPath implementations (like subsequent sub-registry entries) or mandatory because they are in the spec?

[gregsdennis]

As being party of the core document, users will probably expect implementations to support them.

[glyn]

That's true, unless we make it clear that needn't be the case.

I would prefer function extensions all to be on the same footing, regardless of whether they are in the JSONPath spec or added later. It seems rather arbitrary to make those function extensions in the JSONPath spec mandatory given that they are merely the initial entries in the IANA sub-registry.

So I think the spec should say that a JSONPath implementation MAY implement all, some, or none of the function extensions included in the spec. This leaves open the possibility of a basic implementation omitting function extensions altogether.

[cabo]

I would prefer to make these extensions mandatory. This increases interoperability; these mechanisms are phrased as function extensions because that is a convenient way to define them, not because they are optional. Having mandatory function extensions also makes sure the extension point itself needs to be implemented.

[gregsdennis]

I concur with @cabo.

At a minimum, known functions (those in the spec and any that are registered) must be supported. Support of custom functions (as my implementation now supports) should be optional with the understanding that custom functions should not (and cannot) be expected to be interoperable.

[cabo]

2023-01-10 Interim: Document that the functions are non-optional.