As part of T306533: Improve error handling and messages for maps and specifically T316213 we learned a lot about how the Maps (Kartographer) extension validates the GeoJSON content of an e.g. <mapframe>…</mapframe> tag. There are multiple different steps with very different semantics. Still all output is displayed via the same error reporting mechanism. The two validation steps relevant for this ticket are:

• Is the JSON in the <mapframe> tag valid according to the GeoJSON specification?
• Are the properties that are used in the GeoJSON valid simplestyle properties?

This is done via a single JSON Schema that combines GeoJSON+simplestyle and a generic validator, namely https://github.com/justinrainbow/json-schema. Because of the nature of GeoJSON+simplestyle, the nature of JSON Schemas in general, and the way our particular GeoJSON+simplestyle schema is written there are many possible ways how user-provided GeoJSON can be valid. When it's not, it's impossible (with this technology) to say which of the many possible interpretations is the closest one that requires the fewest fixes. The only thing the validator can do is to report the tree of possible interpretations and the points in this tree where it found a mismatch. This looks like this:

The only thing we can do (with this technology) is to show the output of the validator to the user, ideally explain what it means, and let them figure out which of the suggested fixes is closest to what they intended.

Suggested improvements:

• Make sure the validator output is not shown as a list of "errors" because that's not what it is.
• Collapse it by default.
• Make sure the one error message on top explains what the long list below means.
• See if other validators create more useful output. This is already (partially) done. The output from https://github.com/swaggest/php-json-schema is very similar, even a bit more expressive, but fundamentally the same. Especially the same length.
• See if it's possible to rewrite the schema so it creates more specific output. We tried but learned this is fundamentally how JSON Schemas work. Utilizing more recent JSON Schema features doesn't make a difference.
• Make sure everything in the schema does have the best possible human-readable labels and descriptions.
• See if the validator can show these instead of generic messages like "x does not match the regex pattern y". Partial result: Unfortunately neither the justinrainbow nor the swaggest lib make use of labels and descriptions.
• …?