Closed mvahowe closed 4 years ago
One possibility is skew between Python and JS regexes.
You got a "oneOf" error on the root object that disambiguates between the two derived variants. This is precisely the reason why I advocated against this approach. If there is any error in either schema, what you get is a validation error on the topmost invalid condition, which makes debugging impossible.
To see what the error actually is, I'd manually validate it against either the default or the derived metadata schema directly.
If we want to continue on with the approach, I'd change the validation script to manually validate it against either default or derived schemas to get a better error message.
Right but
Which branch are the failing schema and example file on? I'm happy to take a look. The develop branch passes, both on CI and on my own computer.
For the record, I just added
"peach": "melba"
under idServers, and this is the error I get from the JS validator. It's actually better than any error trace I've seen from any free implementation of RelaxNG.
../docs/examples/artifacts/textTranslation.json: [
{
keyword: 'pattern',
dataPath: ".idServers['agmt'].name",
schemaPath: '#/definitions/languageTag/pattern',
params: { pattern: '^[A-Za-z]{2,3}([\\-_][A-Za-z0-9]+){0,4}$' },
message: 'should match pattern "^[A-Za-z]{2,3}([\\-_][A-Za-z0-9]+){0,4}$"',
propertyName: 'peach'
},
{
keyword: 'propertyNames',
dataPath: ".idServers['agmt'].name",
schemaPath: '#/propertyNames',
params: { propertyName: 'peach' },
message: "property name 'peach' is invalid"
},
{
keyword: 'additionalProperties',
dataPath: '',
schemaPath: '#/additionalProperties',
params: { additionalProperty: 'progress' },
message: 'should NOT have additional properties'
},
{
keyword: 'oneOf',
dataPath: '',
schemaPath: '#/oneOf',
params: { passingSchemas: null },
message: 'should match exactly one schema in oneOf'
}
]
@rdb This is develop. Using jsonschema directly gets me the same result. I'm using whatever comes with Ubuntu 19.10, which appears to have Python 2 as a dependency. (There's no version of jsonschema to be found anywhere, obviously.)
Are you using the python-jsonschema package from the Ubuntu repositories or from pip?
However, curiously, invoking the validation script as an argument to python2.7 fails with "no module found".
I'm using the Ubuntu repository module which something else seems to have installed for me.
I just sudo pip installed jsonschema, same mileage.
Can you try Python 3? Python 2 is EOL.
I'm using python 3. It doesn't work with python 2. That's why the Python 2 requirement is curious.
I reproduced the error using docker and the Ubuntu python3-jsonschema package. It turns out that Ubuntu ships an outdated version of jsonschema, which does not support draft-7 of the JSON Schema spec.
We require at least jsonschema 3.0.0, which can be installed using pip. We should document this.
@rdb also points out that the outdated package doesn't complain about being given an unsupported schema version, it just tries to wing it and fails.
@jag3773 @FoolRunning the information at https://json-schema.org/implementations.html looks useful and encouraging (ie there are allegedly implementations for draft 7 which is what we need).
Follow ups in #150 and #151
Right now, there are two validation scripts in SB, for JS and Python respectively. The schema passes according to the JS one. The huge and utterly uninformative error from the Python implementation is pasted at the end of this post.
This kind of issue was entirely predictable (and indeed was predicted before we moved to JSON), but this doesn't help to define a way forward.
One thing we should do is find out just how variable JSON Schema behaviour is across languages we care about. That would include
I strongly suspect that I've hit an edge case in JSON Schema (I have an unerring ability to do this with languages in general). If we can find the edge case we can probably steer away from it and restore similar behaviour across languages.
Also, if we can define the edge case(s) well we can submit a bug report or even a fix to the Python JSON Schema project.
Another option is to say (preferably with a straight face) that we recommend using the JS implementation everywhere, if necessary via a shell script invocation.
If someone with a big heart and no foresight about hosting costs was to offer SB validation as an API, that would help too.