Finding impacted paths for query results with respect to actions

[kevinswiber]

There's a lot to be considered if selecting a single query language for overlays, which is a given.

Looking at existing, supporting libraries for a selected query language is certainly one of those items to be considered.

In doing so, from an implementor's perspective, actions are potentially problematic if the existing libraries:

• Return immutable query results
• Are unable to provide the paths associated with query results

Some options:

1. Use a query language with explicit path-finding syntax. The query, itself, in this case, would return paths for the action. Example:

   jq 'path(.paths."/v1/account".get.responses[] | select(.description == "Error response."))'
   

2. Use a query language with supporting libraries that either return mutable query results or associated paths.

The first option listed above has benefits in being an explicit intention by the author. I do have concerns about the second approach. There may be some edge cases where returning paths from query results may not be possible.

Something to consider.

[darrelmiller]

You raise a good point. I'm not sure libraries that return mutable results are necessarily enough. I could image a scenario where an OpenAPI DOM doesn't allow mutating certain properties on certain objects and it becomes necessary to delete and recreate the DOM element. In that case you might need the path to be able to locate the parent object.

The outcome of this is that many existing implementations may not be sufficient for the needs of an overlay.

I think what you are calling out highlights to me the unsuitability of JMESPath as a solution as one of its core functions is the ability to create a projection of the input. By definition, that projection is not a reference to the input document and there is no way to create a path to that projection in the source document because it doesn't exist. I don't like the idea of saying "we're using JMESPath but just don't do any projections".

The path function in jq is interesting, but I can't tell whether path is any kind of standard syntax or just a jq implementation. Being able to get a bunch of JSONPointers would be idea because that does have a standard.

I don't think this issue precludes us from moving forward with JSONPath as there is nothing to stop an implementation from being able to provide JSONPointer references for the results of the query. It is just more work.

[darrelmiller]

To update this issue, the latest specification for JSONPath specifically addresses the need to return both value and location from paths. https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-20.html#section-2.1.2 Hopefully, this will drive implementers to provide the needed support for this.