RFC: RMLTC0010a-JSON & RMLTC0010b-JSON & RMLTC0010c-JSON

[pmaria]

RFC for:

• RMLTC0010a-JSON
• RMLTC0010b-JSON
• RMLTC0010c-JSON

In JSONPath the syntax for using a key containing spaces is "['foo bar']". This test implies that a mapping author should use "foo bar" instead, which changes the syntax rules of the JSONPath language. When you consider that references and templates can contain more complex expressions than just simple key references, this will also become problematic. IMO the mapping language should have no influence on the query expression language, especially not one that creates a divergence from the standard form of queries in that query expression language.

Proposed:

• Change the mappings of these test cases to use expressions that are valid in standard JSONPath

[DylanVanAssche]

Hi,

Thanks for your suggestion!
However, JSONPath is still a proposal and not standardized.
Several JSONPath implementations exist, handling some parts of the JSONPath
proposal differently in comparison to other implementations.

For example:

• jsonpath-ng can handle both cases
• com.jayway.jsonpath can handle both cases (used in the RMLMapper
  and RMLStreamer)

This can be illustrated by the Jayway JsonPath Evaluator:

• https://jsonpath.herokuapp.com/?path=$..book[?(@.price%20%3C=%20$[%27expensive%27])]
• https://jsonpath.herokuapp.com/?path=$..book[?(@.price%20%3C=%20$[%22expensive%22])]

So we don't think this is related to the RML test cases, but to the JSONPath
library used by the processor.

[pmaria]

Hi @DylanVanAssche,

Agreed that JSONPath is not standardized, which leads to a bunch of compatibility problems.

However, I'm confused. The examples you give are not indicative of the problem I tried to highlight. The problem has to do with the syntax for path segments containing spaces.

If you fill in the example with input:

{
  "countries": [{
    "Country Code": 1,
    "Name":"Bolivia, Plurinational State of",
    "ISO 3166": "BO"
  }, {
    "Country Code": 2,
    "Name":"Ireland",
    "ISO 3166": "IE"
  }, {
    "Country Code": 3,
    "Name":"Saint Martin (French part)",
    "ISO 3166": "MF"
  }]
}

and path

countries[*].Country Code

You get errors for all but Goessner. I can't find any source pointing to this being valid syntax, so it seems to be an optimization.

I use Jayway as well for CARML, and it gives an error Use bracket notion ['my prop'] if your property contains blank characters.

I don't see any options in Jayway to work around this.

Because you indicated that RMLMapper uses the jayway implementation I got curious how it can work there. I found https://github.com/RMLio/rmlmapper-java/blob/d574f063630fafbaffd5546136500e7558afd0f0/src/main/java/be/ugent/rml/records/JSONRecord.java#L39
which wraps the reference with the bracket notation.

Now, I can see doing this for convenience for users, but this is changing the way the expression language (or the underlying implementation) works IMO.

If this is expected engine behavior, it should be documented somewhere.

But I would be against making this expected behavior, because it requires an engine to change the expression language. That is a bad idea IMHO.

So I propose to reopen this issue.