serialize/deserialize schema causes validator to fail when Function type is used about js-schema HOT 6 OPEN

The thing is, that checking for 'function' type is something that is not supported in JSON Schema format (see this list of primitive types). :(

One possible solution would be creating JSON Schema extensions for these kind of things, but I don't want to go that way. It would possibly make the serialization output unreadable for other JSON Schema implementations.

A better solution would be to properly inform the user of the API of the information loss, and to handle these cases gracefully. For example, a serialization/deserialization cycle should always result in a valid js-schema function (although maybe not identical to the original).

Do you really need to serialize this schema? You could maybe get away with a less strict schema that is serializable, or rebuilding the schema every time instead of serialization/deserialization.

from js-schema.

I was serializing the schema so that I could include it in the same JSON document that it validates. I was also thinking of having a form that a user fills out that then creates my JSON document and includes its serialized schema in that document so that the back-end can see how to validate the document when it uses it to create a visualization. So user enters the data, back-end visualizes it. This is for some kind of user-configurable dashboard of widgets. Alternatively I guess I could save only the schema version number and the back-end could retrieve the a corresponding JS class with the schema validator in it, unserialized. I do think we need to at least document that the serialization methods don't work for the Duck example provided in the readme

from js-schema.

How would you tackle some simple validation as well? It would be nice to know at least which part of my document failed to validate if not why as well. I might be into adding this functionality if you can point me in the right direction – maybe something that could be switched on with debug = true or something if you're concerned about performance.

from js-schema.

Reading the JSON Schema standard again, I discovered that extensions are supported quite well:

Implementations MAY choose to define additional keywords to JSON Schema. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords to be supported by peer implementations. Implementations SHOULD ignore keywords they do not support.

A simple extension to the serialization would be a warning message that this schema could not be serialized perfectly. So that when you look at the serialized version, you can see explicitly that there was information loss. Later, maybe js-schema specific extensions could be defined, but that's more work.

As for your usecase: if you validate JSON documents, you would in theory never need the 'function type' validation, because JSON can not contain functions.

from js-schema.

Validating and then knowing which fields failed is something I planned for a long time, but did not get to implementing it in the end due to lack of time. It would be awesome if you could work on this!

I think it should be an extension to the current API, something like this:

var Duck = schema({              // A duck
  swim : Function,               //  - can swim
  quack : Function,              //  - can quack
  age : Number.min(0).max(5),    //  - is 0 to 5 years old
  color : ['yellow', 'brown']    //  - has either yellow or brown color
});

var myDuck = { swim : function() {}, quack : function() {}, age : 2, color : 'yellow' };
console.log(Duck(myDuck)); // true
console.log(Duck.errors(myDuck)); // false

var myCat =  { walk : function() {}, purr  : function() {}, age : 3, color : 'black'  };
console.log(Duck(myDuck)); // false
console.log(Duck.errors(myDuck)); // { swim: 'should be a function', quack: 'should be a function' }

So the errors(object) method would return a tree of errors with the same structure as the original object.

It would be implemented with an additional errors() function on each type of validation. It would return these detailed error reports: simple string for simple validations, or object with nested error reports for compound types (like object or array).

from js-schema.

Attempt to implement errors API was done with pull request: #15

from js-schema.