additionalProperties would be nice

[davek2]

The project description says:
3. The generated schema should be as strict as possible given the first 2 rules.

In order to meet that goal, schemas of type "object" should include an "additionalProperties" property. If the user generates a schema exclusively from json instances then this would always be false. If the user imports a schema with it true (by default or explicitly), then the true would take precedence over an instance-derived false without generating a conflict. Two schemas with opposite values would generate a conflct.

[wolverdude]

true in this case would always trump false because the generator is intentionally designed to be permissive. Even so, there is a note in the next section about the subset of json-schema this library is intended to deal with. If I have time soon, I'll update the readme to make this a little more clear.

[davek2]

The readme is already quite clear that the package deals with only 4 keywords. The question is whether the number could be 5, 6, or 7 without violating the design tenets "uses a small subset of JSON Schema's capabilities", "does not try to guess user's data model", and "installs without dependencies". jsonschema.net supports user options to control generation without doing any guessing.

I can submit a pull that adds support for additional properties, additional items, and merge properties, all controlled by user options as with the current merge arrays option. It also fixes a bug in merge arrays. But I won't bother if you consider "4 keywords" to be one of the design tenets.

[wolverdude]

If it would be helpful to users, I'm all for it. TBH, I haven't had an occasion to work with JSON Schema in a while, so I feel a little out of touch with the pulse, but I'd love to get an updated version out there. I'll try to get to your PR soon, though it's not as high priority as the bug fixes.

[YehudaCorsia]

Hey, i try to find the way to enter this.
if you can help me to find the best way its will be helpfull :-)