Parser : RFC version or python-jsonpath version?

[rob-ross]

You have mentioned that your RFC version is more modern and you thought a better implementation than your original python-jsonpath version. I have finished initial work on the Lexer in my port and am about to start on the parser. I ended up with 3 Lexer implementations, a PJP version that uses the regex patterns and algorithms from your python-jsonpath , a JJP (java-jsonpath) version that attempts to support everything your PJP Lexer does, but in a more optimized Java way, and an RFC Lexer that will be strictly conformant with the RFC spec. I think I have a good foundation for others to customize the Lexer as they see fit.

But the Lexer is the easy part.

As I start on the parser I will first try to use the same methods and algorithms you have in your PJP version so I can pass all your parser unit tests. Then I will create a Java optimized version of that, then one for the RFC version.

Can you elaborate on the differences between your two JSON Path implementations, and call out what you think is "better" in the RFC version? And I mean besides the additional functionality that the PJP version has to support for your extended feature set. I mean more the way the parser is organized and any patterns you used in the RFC version that you like better. Or just pointers on what you would have done differently in the parser with your experience and hindsight.

Thanks!

• Rob

[jg-rp]

With the changes I'm working on in #98, the gap - in terms of cleanliness and one implementation being better than the other - between python-jsonpath and python-jsonpath-rfc9535 is small. It's just that python-jsonpath is more cluttered because it is more flexible and has more features.

Prior to #98, it is mostly the internal representation of JSONPath segments and selectors that is better in python-jsonpath-rfc9535. Otherwise both implementations approach the parser in the same way. Although method names in python-jsonpath's Parser class will be confusing to anyone familiar with RFC 9535.

As to what I would do differently, that's what #98 is. The JSONPath internal representation has changed and the parser is rewritten.

I do regret adding "filter expression caching" to python-jsonpath. Messing around with "cache trees" and "cacheable nodes" adds complications for a feature that is rarely useful.

[rob-ross]

That's good to know about filter-caching. I will skip that feature..

Also, do you have documentation for the grammar rules you're using in python-jsonpath? That's really the core compatibility concern. As long as I follow the same grammar rules and provide a similar API as your project I can be "compliant" with it.

Thanks!

[jg-rp]

Documenting the non-standard grammar used in python-jsonpath is on my todo list.

Extra JSONPath Syntax covers:

• the key selector
• the keys selector
• the keys filter selector
• the current key identifier

The "singular path selector" is briefly described here.

And the following syntax is yet to be described in any detail.

• The pseudo root identifier
• The filter context identifier
• contains and in membership operators along with list literals
• undefined and missing reserved words
• the =~ operator and regex literals
• query union (|) and intersection (&) operators

[jg-rp]

I've started to separate test cases for non-standard syntax in to JSON files, matching the CTS schema.

See 6e1f3b7.

The "filter context identifier" will be an exception, as we can't represent arbitrary extra data using the CTS JSON schema.