Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMESPath – A query language for JSON

jmespath.org

Post reply on HN
Print view View original

51–60 of 131 posts

Re: JMESPath – A query language for JSON

#51

Post by Avshalom »

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

People become just furious at the existence (especially when they never write xml by hand) of closing tags. Because the XML people wanted to be able to spot unclosed elements before they reached EOF and because they thought it would be nice to be able to report what was actually unclosed we're going to have to just accept a world in which programmers will use absolutely anything before using xml.

see also: hating pascal's 'end' instead of '}' or claims that python is readable because it doesn't even have '}'

Re: JMESPath – A query language for JSON

#52

Post by maxxxxx »

paulddraper wrote: post #33
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 can create first-class arrays in JSON.

That's the only advantage I see in JSON but it's a good one.

Re: JMESPath – A query language for JSON

#53

Post by randallsquared »

benjaminjackman wrote: post #37
crdoconnor wrote: post #28

Earlier quoted context omitted.

The "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. Neither JSON schema or XML schema are particularly popular - and for good reason.…

That ability to use outside canonical sources is really interesting. Are there some existing examples of schema languages with that feature?

JSON Schema, at least, can refer to a URI for the definition of something, and that URI can refer to only a specific section of the JSON document to which it points.

Re: JMESPath – A query language for JSON

#54

Post by krapp »

mjburgess wrote: post #49
danbruc wrote: post #39

Does this have any mathematical foundation like the relational algebra for SQL? Or more generally, does a mathematical framework exist to treat this or similar constructs and that goes beyond what relational algebra provides and that, for example, also handles aggregate functions? The reason I am asking is that I am currently trying to build a tool to analyze a kind of time series data, think log file entries, in ord…

load the data into a database (sqlite is very good). use the database. delete the database.

Might as well just keep everything in a relational database to begin with, in that case, and generate JSON from the query results.

Re: JMESPath – A query language for JSON

#55

Post by spraak »

danbruc wrote: post #39

Does this have any mathematical foundation like the relational algebra for SQL? Or more generally, does a mathematical framework exist to treat this or similar constructs and that goes beyond what relational algebra provides and that, for example, also handles aggregate functions? The reason I am asking is that I am currently trying to build a tool to analyze a kind of time series data, think log file entries, in ord…

What reasons did you not go with SQL itself? I may not fully understand what you're trying to do, but in any case it sounds really interesting.

Re: JMESPath – A query language for JSON

#56

Post by titanix2 »

Finnucane wrote: post #40
hliyan wrote: post #23

Earlier quoted context omitted.

Isn't that what we want? I would think that solving the same problems for a less verbose format is a good thing. And looking at the examples and the library support ( http://jmespath.org/libraries.html ) I would say this solves a real problem. I can already think of several use cases for my own system. The fact that a solution is treading familiar ground does not invalidate its utility.

It's not very much less verbose, really. You still need a key and a value. The only thing you lose, really, is the end tag. For a complex text document in say TEI or Docbook, I don't see how this is much of an advantage.

No, you also loose the attribute system and thus the ability extend existing elements without changing their structure.

In addition, arrays must be indicated clearly in JSON while you can consider children of an xml nodes to always form a list (be it empty or containing one element).

So while the two format are very similar, there is still some differences that doesn’t make them interchangeable for every usecase.

Re: JMESPath – A query language for JSON

#57

Post by acdha »

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

The problem with XML is that almost every tool has bad usability — both things like basic tasks frequently dumping you into a thicket of cryptic standards docs or that the libraries in most common languages have unnatural API choices (i.e. they follow the libxml2 C interfaces) and leave a lot of basic usability on the floor.

As a simple example, there's no technical reason why XPath couldn't allow you to either use namespaces as written in the document[1] or ignore them when appropriate[2]. Nobody cared about usability and it's the number one reason I've heard why developers with jobs to do fled to JSON / YAML as quickly as possible. A similar story arises with XPath 2 — libxml2 never got support so that standard effectively doesn't exist for most projects, but there's no way to shift the resources away from developing further revisions which will also not be widely used towards much cheaper basic investment in shared infrastructure.

1. e.g. if the doc is , it should never require you to write {http://path/to/foo}bar to match that element.

2. Ever try to target docs in multiple versions of a standard?

Re: JMESPath – A query language for JSON

#58

Post by mpweiher »

wruza wrote: post #45
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

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...

Re: JMESPath – A query language for JSON

#59

Post by [deleted] »

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

[deleted]

Re: JMESPath – A query language for JSON

#60

Post by Someone »

crdoconnor wrote: post #48
benjaminjackman wrote: post #37

Earlier quoted context omitted.

That ability to use outside canonical sources is really interesting. Are there some existing examples of schema languages with that feature?

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 write my program in python, and even then, it could be hard for me to replicate your setup.

Post reply on HN