jsonschema: Add a helper for extending a validator to reject unknown formats

Can you expand on exactly what was done to make the hyper-schema work? I tried to add properties: $ref: # and similar but did not get it to work.

Copy the hyper-schema meta-schema. Change $id. Remove links and base, and add your specialized format.

Regardless, I think specs should come from use cases, as their point is to standardize systems for solving problems.

As someone who has been maintaining a spec for a couple of years, I can tell you that pretty much everyone who has ever had their request declined uses this argument to mean “my use case is the use case you should solve”, regardless of its impact on everyone else, or whether it fits the overall philosophy of the system.

I personally would favor making "failure on unknown format" the default, but I'm guessing that would break existing use cases.

 Not to mention completely violate the specification.

Yes, the spec does say an implementation should (though not shall) succeed if it sees an unknown format (http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.2). However, it says nothing about providing an option to behave differently. Regardless, I think specs should come from use cases, as their point is to standardize systems for solving problems. I think my use case here is legitimate, although I can also understand those who want to silently pass through an unknown format. My point is that providing the option to do both is useful. If the spec forbids making my way the default, no problem, but having a way to enforce the constraint is important. I would love to be able to set a property like format-required or similar.

@handrews, if I use a meta-schema, can I also validate against the main jsonschema spec? AFAIK, you can’t validate against multiple meta-schemas. That said, uses a meta-schema doesn’t seem like a very “obvious” / convenient way of handling it, so it’s not something most people would think of. Having an easier way would be helpful.

I say this quite a bit, but schemas are not a replacement for unit tests 😃 – so “silent” here is “silent” in the same sense as if you wrote buggy code and didn’t notice until your test failed.

Sure, schemas are not a replacement for unit tests, just as writing good, defensive code is not a replacement for unit tests. But, schemas are used for enforcing constraints, and in this case, I have a constraint to enforce, so ideally there should be a way to express that in the schema language.

It won’t be the default, for the reason @handrews mentioned, this library is an implementation of the specification, but I’m still happy to accept a helper function for adding an enum restriction to a metaschema. Though increasingly I’m thinking there’ll shortly be a jsonschema-ext package to contain stuff like that.

What method do you propose? If you sketch out the gist of the design, I’d be happy to code it up if I have the time.