JMESPath – A query language for JSON • Hacker News Board

Re: JMESPath – A query language for JSON

#61

Post by johnhenry » Sat, Feb 17, 2018, 3:24 PM UTC

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?

Re: JMESPath – A query language for JSON

#62

Post by jnordwick » Sat, Feb 17, 2018, 3:26 PM UTC

I remember when xml started down this road too. "We aren't going to be sgml, but just a lightweight markup. Xpath, xslt, etc. And now we have xml today, the modern day sgml.

But this time it's different?

Re: JMESPath – A query language for JSON

#63

Post by coding123 » Sat, Feb 17, 2018, 3:30 PM UTC

bufferoverflow wrote: post #15

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

We still need XSLT for JSON to complete the circle. Though it seems like XSLT should support JSON: https://www.w3.org/TR/xslt-30/#json

I thought JavaScript was the xslt of json.

Re: JMESPath – A query language for JSON

#64

Post by rozzie » Sat, Feb 17, 2018, 3:43 PM UTC

For those interested in arbitrarily transforming JSON objects (for example, in a communications pipeline) I’d recommend JSONata. It’s quite useful and we’re well along in a Golang port with $function extensibility. http://jsonata.org

Re: JMESPath – A query language for JSON

#65

Post by zero_intp » Sat, Feb 17, 2018, 3:44 PM UTC

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 use jq on simple projects and to prototype. It is lightweight, fast, and usually consistent in operation.

Re: JMESPath – A query language for JSON

#66

Post by wruza » Sat, Feb 17, 2018, 3:50 PM UTC

mpweiher wrote: post #58

wruza wrote: post #45

Earlier quoted context omitted.

Last time I checked, XML was uncertain which validation should I use. DTD, Schema, other solutions. Each has syntax/structure and 1st page explanation so cryptic, that I don’t even understand where do I begin. I don’t like js/json at all, but for json (and without much js knowledge) I can roll out simple validation in less time than is needed to understand these schema formats. If my structure is dynamic, omg it will…

> and cannot be serialized like jsonlib.encode(foo) Huh? Could have fooled me. In Cocoa, for example, serializing to JSON and serializing to an XML property list (or binary property list) is effectively the same code. https://developer.apple.com/documentation/foundation/nsjsons... https://developer.apple.com/documentation/foundation/nsprope...

Yes, but property list is a subset of XML and Cocoa’s almost internal format. It doesn’t even connect keys to values, probably losing all the xpath/xslt/etc abilities. No custom schema too?

Re: JMESPath – A query language for JSON

#67

Post by jjuhl » Sat, Feb 17, 2018, 3:51 PM UTC

Re: JMESPath – A query language for JSON

#68

Post by crdoconnor » Sat, Feb 17, 2018, 3:54 PM UTC

Someone wrote: post #60

crdoconnor wrote: post #48

Earlier quoted context omitted.

The point I was making was that you shouldn't use a "special" language for validation at all - you should just use a library in a regular language to do it. Anyway, code: yaml_text: John: Yemen James: South Sudan python code: from strictyaml import load, MapPattern, Str, Enum import pycountry result = load( yaml_text, MapPattern( Str(), Enum([country.name for country in pycountry.countries]), ) ) full disclosure: I w…

The idea behind XML schema, DTD, etc. is to pick a simple language to express schemas in, so that implementations in different languages have a decent chance of being compatible with each other. Python isn’t a good choice there, as it is too flexible. For example, that code could have gotten the list of allowed country names from a file, database, or URL. ⇒ If I have to send such json to you, I almost would have to w…

>that code could have gotten the list of allowed country names from a file, database, or URL.

That is exactly the point. You should be able to do that, because the canonical list of data could easily from any of those and it should the up to programmer's discretion how to fetch it.

The point of validation is to prevent invalid data from slipping through a net at minimum cost and that's how you do that.

Suden, Sudaan and South Sudan were all invalid countries in 2010 and that YAML was invalid. In 2012, Suden and Sudaan were invalid but South Sudan was not so that YAML was valid.

In the above example you have to make no code changes in order to account for that - just update pycountry every so often.

With XML schemas and DTDs either you don't validate country at all (letting Suden and Sudaan) through the net. Or, you rewrite and redistribute the schema by hand every time some dependency like a list of countries changes.

>If I have to send such json to you, I almost would have to write my program in python

Only if I choose to validate that data using a shared schema. Frankly, I've dealt with XML a lot and the number of times I've been handed a shared schema of any kind is very low. People just don't seem to use them. If they define an API in XML for instance they tend to just send examples and give a written explanation (e.g. insert valid country name here).

I don't see much value in making a schema more inherently "shareable" especially not if it means it has to be re-released every month.

Re: JMESPath – A query language for JSON

#69

Post by vthriller » Sat, Feb 17, 2018, 3:54 PM UTC

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 only have used jq, but I noticed that even AWS CLI docs [0] (already mentioned in the comments a couple of times) suggest to use jq for "more advanced features that may not be possible with --query".

[0] https://docs.aws.amazon.com/cli/latest/userguide/controlling...

Re: JMESPath – A query language for JSON

#70

Post by gregmac » Sat, Feb 17, 2018, 3:57 PM UTC

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 been using jq quite a bit with AWS CLI inside various bash scripts. It allows manipulation and filtering the native api doesn't, which makes it pretty straight forward to get certain values - such as specific tags on the current instance (converted to key-value form, or to turn into bash variables), a list of other systems in the current auto scaling group, etc.

I've also started using it just to get colorized/formatted output from curl or a local json file.

    cat file.json | jq