cburgmer
Grouping queries by features
The table is growing larger and becomes difficult to evaluate with an eye. One of the solutions may be tagging each query with features, For example, query $["key"] can be tagged with features bracket notation and double-quoted names; query $.a..* can be tagged with features nested names, dot notation, deep scan and wildcard and so on.
If the implementation hits any consensus in a query tagged with any given feature, we can say that it supports that feature, and then we can build a matrix of supported feature combinations. For example, that will show that some implementation supports names without quotes in dot-notation but doesn't support them in bracket notation.
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?
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).
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?
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.