Friendly error messages for union types about jsonschema

[Julian]

This sounds reasonable, other than the fact that name makes me really confused. It's not officially mentioned in the schema, so it's not clear if it's actually special in any way.

I'd want to clarify that, because if it isn't special then using it for this would be dirty, but if it is, then this would be OK – maybe you want to take a shot at it :)? If not, you can leave this open.

[gazpachoking]

Hmm, you appear to be right. I was just looking at all the examples in the draft having that property, which made me think it was part of the spec. The only discussion on it I found was here. https://groups.google.com/d/msg/json-schema/TAquHyF9lXg/3tyhmC7dI2YJ

I could certainly contribute a solution if you have any ideas on how it could be done cleanly, can't think of anything myself that might not give unexpected results outside of my scope right now.

I am thinking of moving from a custom validator system we have in our project (FlexGet) to using json schema, but do not want to give users cryptic errors. Maybe I'll just override the validate_type method in order to give custom errors for our project.

[Julian]

That would be a thing you could do certainly. Just extend it, call up using super to actually validate, and re-raise a different ValidationError using whatever property your application likes.

[gazpachoking]

Yeah, I might just override it outright, as I'm thinking we also want to display the subschema error message when we can detect which they meant. (we often have 'simple' form, of just a boolean, and 'advanced' form accepting an object) It'll probably be nice for us to display the actual object error message when users create a dict rather than a bool. All rather specific to our project though, I was just thinking maybe some of it could have been upsteam at first. Thanks for the nice project though. :)

[Julian]

No, certainly -- I agree with this in principle, readability is good, no one wants a huge splatted traceback, it's just unfortunate that draft 3 doesn't have this in it.

At some point when it actually exists in a reasonable form jsonschema will support draft 4, and it sounds like that might introduce something that'd help you, so perhaps then we can revisit this.

[gazpachoking]

Oh hmm, just saw 'title' is mentioned in draft 3. Maybe that could be used. https://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.21

[Julian]

Well, see, it's not just a question of what can be used -- name can be used just as well as title, it's a question of what is used. I'm still not sure title, even though it's part of the schema, is used for any significant purpose. The thing I'd rather not do (which of course the application can still choose to) is add significance that is local to the validation library that in fact isn't present in the schema or its use.

So I guess what I'm saying is I still need to look around to see if in fact title is used for this (naming a schema, or naming it well enough to call that its type more specifically).

Of course it doesn't matter that much, since it's only an exception message, which is there for developers, but lemme take a look around.

[gazpachoking]

Yeah, I wasn't sure it was entirely appropriate either. Figured I'd write up the code and see how it works anyway.

[Julian]

I'm still thinking about this, but I think you've said enough here -- I'll either merge or politely thank you and pass on the pull request as soon as I've made a decision :). Thanks again.