Stefan Goessner

Follow up of https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/449: Take the following arithmetic example: `(a + b + c)*d/e Of course, this would break any attempt to have an extensible function interface, ... I don't...

@ohler55 ... I do understand this very well from a user's point of view. But on the way there will be a lot of spec work to be done. So...

Hmm ... as an outcome of this discussion the realisation matures, that inline arithmetic develops as a de-facto standard in current implementations, which is also the natural thing, users expect....

It is a well known insufficiency of JSONPath, not being able to address root level member names / element indices by filters. A way out of this would be ......

`[###]` works on children and `..[###]` on descendants. Why should the node itself be in the result list (I know, XPath meanwhile has both: `descendant` and `descendant_or_self`). By above query...

If an extension point mechanism can be used to register analysis/mutator functions (average, deduplicate), that would be a good thing. Those Jayway functions can (only) be used at the end...

After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward: > Two structured types are...

I totally support a decision to: * not dealing with subsets * restrict the rhs to arrays only with contain-expr's.

@grzegorz-herman : You are correctly pointing to a certain insufficiency of JSONPath here. I would like to elaborate here a little more. Both arguments ... ```json { "a": 1, "b":...

... interesting ... `@key` would be another syntax approach equivalent to function `key(@)` then.