jp VS scout

I have a hard time suggesting such a thing, because I find JMESPath incredibly inferior to jq's expressiveness, but if you're in the AWS ecosystem much, you may enjoy https://github.com/jmespath/jp#readme which uses the same query language as does awscli (https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-f...). That may at least pay more dividends than keeping jq's language in your head where it will only ever be used by jq

Have you tried this utility instead: https://github.com/jmespath/jp

There’s also jp, which interprets JMESPath: https://github.com/jmespath/jp

This one has the advantage of being natively understood by aws-cli, meaning you can pass a JMESPath to an AWS call and only receive the filtered / transformed result back.

I developed a library that is better suited for such cases than plain Decodable. You can specify a path in the data and at the end of the path specify a Decodable type to be instantiated from the data.

Not 100% sure but you might find Scout interesting for your needs

I developed Scout for this exact purpose because I had to find a solution to get a value when the data structure is not known at build time.

If you are ok to use a program, you can use Scout like that: curl [your curl request here] | scout read -f xml "a-valid-date"

For a clear and simple syntax, you can take a look at Scout.

I have been working myself on Scout to work on data when the format is not known at build time (for instance with a generic command line tool). And I have never had the tuple decoding requested. Although this might be useful for some people.