Grouping queries by features about json-path-comparison

[cburgmer]

I've restructured the query names to be more descriptive following a more regular pattern, as laid out in https://github.com/cburgmer/json-path-comparison/blob/master/QUERY_NAMING_PATTERN.md.
The latest change now uses that to re-order queries not strictly alphabetically but respecting the underlying structure of the query name, following the Regex described in the document linked above.
Do you think that's a good first solution to your problem? Or were you looking for something else?

[remorhaz]

As a first step maybe yes, but I thought rather about building an alternate target table that pictures features instead of queries (but keeping the current one, too, of course).

[cburgmer]

I thought so, but wanted to ask you more about the goal of it.
I could envision a table similar to MDN which calls out which browser supports a certain feature. Considering that we are still way before 100% with consensus this might be tricky though: once a query reaches a consensus it might change an implementation from "supporting" to "not-supporting" because of a now surfaced disagreement?

Who would be the user of that, who would it benefit?

[remorhaz]

I think that implementers could benefit from this, getting big picture. I'll give you a simple example. Let the query be $.."key", there's no consensus, and I decide if I should support it in my implementation. But I don't know why some implementations fail! There can be the following reasons of a failure (or a combination of them):

• implementation doesn't support deep scan (..);
• implementation doesn't support double quotes;
• implementation doesn't support quoted keys in dot-notation;
• etc. or it's just a bug.

If I could see, for example, that there is consensus in "using double quotes" but no consensus in "quoted keys in dot notation", I can decide to support double quotes ASAP to improve my users' experience but take a pause before implementing non-consensus feature.

Another benefit is having the list of features and their popularity before my eyes when I'm just planning to build an effective parser for new implementation.