Project governance about json-path-comparison HOT 7 OPEN

I think the goal for now is clear: compare the behaviour of multiple JSONPath implementations.

As we see a JSONPath standard emerging, it is important to include reference implementation(s) in the comparison. One reference implementation has already been added. When the standard and reference implementation are complete, it may then be beneficial to change the goals of this project to compare the other implementations against the Compliance Test Suite rather than, or maybe as well as, against the computed consensus, as this will help implementations move towards the standard should they wish to.

I would have thought that issues and PRs are the best way to get feedback. I don't think it's necessary to formalise the project governance beyond this. Are there specific examples where you think more formal governance would help?

from json-path-comparison.

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

from json-path-comparison.

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

What would be the goal of adding an alternative proposal?

from json-path-comparison.

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

What would be the goal of adding an alternative proposal?

When one does stuff for free, is it necessary to have a point? But perhaps as a point of reference. I have some thoughts on the syntax and semantics that differ somewhat from Proposal A, some thoughts on a full specification of comparative and arithmetic expressions that are not present in proposal A, and some thoughts about some non-breaking extensions to the JSONPath syntax, some with precedents. Such thoughts may be of interest, or not. But in any case, the existence of an "A" almost demands a "B"!

from json-path-comparison.

Thanks @danielaparker. The reason I asked was to determine whether another proposal or another reference implementation of the evolving internet draft was most appropriate. The former turns out to be the case. I'm personally comfortable with that as it would shed more light on the problem space.

@cburgmer wdyt?

from json-path-comparison.

As we see a JSONPath standard emerging ...

Do we, though? Is JSONPath a protocol that the IETF can realistically take ownership of? Is a "full standards" IETF RFC likely to emerge? Is there a compelling reason that JSONPath implementations must interoperate?

I'm starting to think that the answer to these questions is no. I think it's more realistic to concentrate on historical comparisons and experimental proposals.

from json-path-comparison.

Is there a compelling reason that JSONPath implementations must interoperate?

yes there is.

• If I am using JSONPath expressions in configuration files which aim to be used in various Implementations those expressions should be uinversal
• I am using an interactive tool https://extendsclass.com/jsonpath-tester.html to investigate expresions. The such developed expressions should work in other implementations as well.

from json-path-comparison.