JMESPath – A query language for JSON

Post by avmich » Sat, Feb 17, 2018, 7:55 PM UTC

crdoconnor wrote: post #98

avmich wrote: post #94

Earlier quoted context omitted.

> * Keep that schema file updated by hand every time something like Sudan breaking in two happens (no). There is a lot of use for libraries dealing with time and dates. When you want to cover all cases, at some point you get to the situation when you have to allow variable number of seconds in a minute - not always 60, but sometimes 59 or 61, or may be even different numbers. And you don't know in advance - for arbit…

Ideally, use a library that intelligently parses dates as part of a turing complete validator.

Post by cryptonector » Sat, Feb 17, 2018, 7:59 PM UTC

zephharben wrote: post #86

johnhenry wrote: post #61

Besides's this projects cli, jp ( https://github.com/jmespath/jp ), I see jl ( https://github.com/chrisdone/jl ) and jq ( https://github.com/stedolan/jq/ ) in the comments. I wonder if anyone has had experience with all three (or even just one) and can comment on their experiences?

I've used jq and jp/JMESPATH quite a bit. I love jq, and use it more often than JMESPATH. However, recently I've noticed that I arrive at "the solution" I need more quickly with JMESPATH. In retrospect, JMESPATH's documentation and examples have been more useful for me than jq's (docs/examples).

Post by hoppelhase » Sat, Feb 17, 2018, 8:27 PM UTC

Post by blattimwind » Sat, Feb 17, 2018, 9:04 PM UTC

a-saleh wrote: post #43

xchaotic wrote: post #11

The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc

Hm. One reason why I prefer Json to XML (and I actually like XML) is, that JSON is simpler. The fact that XML has schema definitions out of the box, and that these schema definitions can reference other definitions would lead to more complex parsers that can contain more bugs and vulnerabilities.

Post by llimllib » Sat, Feb 17, 2018, 9:12 PM UTC

cryptonector wrote: post #105

ak217 wrote: post #81

Earlier quoted context omitted.

jq is by far the best developed and has the most intuitive syntax, but it doesn't have a formal spec for its language. I have been maintaining https://github.com/kislyuk/yq , which wraps jq with a transcoder for YAML and XML.

Is there demand for a formal spec for jq? Would that lead to additional implementations? Serious question.