It would be nice if the validation error messages referenced a schema by its title rather than its UUID

[aviflax]

Currently when I get a validation error message, it ends with something like in schema ecff90d3-5502-54ba-b62f-5969d00a49c8. But my schema does have a title — it would be nice if that was used instead of the UUID. It would make the error messages slightly more friendly and useful.

BTW, great lib. Thank you!

[jaybloke]

This is a great idea. I'm presently using this gem to validate a questionnaire w/answers... it would be nice if there was a better way to show more meaningful errors to the user. As it stands, I will have to do some major hacking in order to provide friendly error messages.

[angelim]

@aviflax, @jaybloke Try giving your schema an id property. (http://spacetelescope.github.io/understanding-json-schema/structuring.html#the-id-property). This gem uses the id as the schema's URI and doesn't generate an uuid.

[RST-J]

@angelim But it creates a uuid as id for schemas that come without an id though (just for completeness, your answer perfectly solves the uuid issue). However, for displaying it to users, the id is also not a really convenient caption. Processing error outputs for end users is not something that json-schema currently supports well (which we already identified, there are also other issues about that topic).

I think it would be worth to discuss how errors should be structured and handeld and based on that design or rather sketch of design someone (or maybe I myself find some time to do it) can prepare a PR. My first idea would be to bring OO to errors and define error classes which for themselves semantically define what is wrong in which place. These classes then could define serveral "to_s"-variants. Any more input? Problem is that this will likely break backwards-compatibility if we won't add another flag (I really don't want to do that) or have some hack - so this would be something vor v3.

@iainbeeston Your thoughts on this?

[angelim]

@RST-J I agree with you completely. My first answer was an attempt to solve that particular problem without changing any code. I think this gem would benefit from re-evaluating the way errors messages are handled. Maybe something along the lines of ActiveModel Validators. That would also give it more flexibility to allow internationalization and customization.

[RST-J]

Yes, there could be some to_i18n-method which then returns something like %w(json_schema draft_04 NAME_ID properties name required). But I see one issue, its about the NAME_ID-part in the array. This should be something that identifies the schema which was violated. Intuitivly, I see two solutions. Either we take the value of the schema's title property. Or we take the schema's id property and underscore the path ('http://example.com/some/schema_path/to_file' would then be inserted as (%some schema_path to_file)). Or we combine both with title being prioritized. But as I actually have never seen the use of the title property before this issue I'd propose we could just use the second approach alone.

And there is another problem - maybe. What about schema violations that stem from the 'definitions' property of some schema? I personally don't use them, I store these references as entity definitions on their own and reference them via '$ref'. Do such definitions have suitable ids? Maybe the NAME_ID expansion should then be %w(some schema_path to_file definitions underscored defintition_id)?

[majkelcc]

In https://github.com/ruby-json-schema/json-schema/blob/master/lib/json-schema/errors/validation_error.rb I see some very useful information coming with each error. To be as flexible as possible validation could return an array of instances of mentioned ValidationError. Additionally to unify the basic presentation of errors, I think ActiveModel::Errors is a good example of how it might work.

Should we move the discussion on better errors to a new issue?