Extension support

[fiestajetsam]

Cover how the extension mechanism, including updates to IANA work.

[cabo]

Let me try to summarize the objectives here:

• The extension mechanism specifies the grammar for all jsonpath queries that make use of this mechanism, i.e., the individual extensions do not define additional grammar
• A consumer of queries can there parse any extended query; this allows it to find out which extensions are being used in a query (as a list of names)
• We include one feature in jsonpath-base that makes use of the extension mechanism (so far, a length feature has had the most support)
• Extensions are defined in an IANA registry that would initially be populated with the one extension we include
• The registration policy (RFC 8126) for that registry needs to be decided, probably on the spectrum between Specification Required (with some specific instructions to the designated expert) and IETF review.

[danielaparker]

Why? The draft specification is already somewhat incompatible with all existing implementations, all existing implementations would see major breaking changes were they to move to conformity with the draft. Why then allow for additional incompatibilities between new implementations that follow the draft? It seems to me that the primary value of the draft is interoperability, and extensions break interoperability.

[cabo]

extensions break interoperability.

The damage done by extensions is larger when they are done in an uncontrolled, chaotic fashion. And they will be, if we don't define an extension point.

[goessner]

Thanks for enlightening ... reading RFC 8126 ...

[glyn]

The function extension point is in base 09. I think addresses the general points in this issue in a concrete way.