Good PHP JSON Schema validator and default value handling

[Max Loeb]

Can you recommend a good JSON schema validator written in PHP? I've found a few projects as I hunt around online, but they all seem to be a little half-baked. I'm currently using https://github.com/hasbridge/php-json-schema, but it has little bugs here and there, omissions (eg. support for "$ref" and "definitions"), and poor error reporting . I'd rather not have to write my own, but it's looking like I may have to.

The second part of my question has to do with default values. Should a validator apply the default values to the incoming request, so that when the request is handed off to the API, the defaults are already there? Or is that something you should keep separate?

Thanks much for your replies.

[Geraint]

The standard does not suggest using default values for validation - they are informative, giving extra information to UIs (or perhaps values for URI Templates).

However, there's a growing need for "coercive validation", where if a document would fail validation, but there are simple modifications that could make it pass, then an altered document is returned that passes validation.

Adding default values for missing required properties could be part of this, and so would converting strings to numbers/booleans/null.  This is particularly needed for server-side environments such as PHP, where submitted data might be encoded as "application/x-www-form-urlencoded" (which converts all values to strings).

When it comes to implementations - the only ones I'm aware of are up on the JSON Schema main site.  Unfortunately, I'm not aware of any PHP implementations that support coercive validation - I had a half-baked one myself quite a while ago, but it was not complete, and not v4-compatible.

Geraint

[Max Loeb]

Understood. It sounds like until coercive validators start to appear, my best bet is going to be to define my default values as constants elsewhere in the code, and use those constants to set the defaults. Not the worst approach in the world, but it would be nice to be able to let the schema drive it, instead of the other way around. Thanks much.

[Geraint]

Hi Max,

Just wanted to let you know that I've made good progress on a coercive validator for PHP.  I expect to have something in a GitHub repository some time this evening.  It's currently lacking "$ref" support, but I expect that to be be fairly straightforward to add.

It would be quite good for me to know exactly what functionality you'd need in terms of of coercion.  Currently it does basic type-juggling (between string/number/boolean) and in certain cases it can add missing object properties (using default values if they exist).  Can you think of more situations that you think it should cover?

Geraint

[ml...@tagged.com]

That sounds wonderful! I'll be happy to be your first guinea pig, and I'm also available to provide bug fixes or other coding help if you'd like it. I don't currently have detailed requirements, but I'm sure I'll have comments once I try it out. I do have a few general requests that I think would be handy for any PHP validator:

1. It would be nice if I didn't have to explicitly resolve $refs (which is the case with https://github.com/justinrainbow/json-schema)

2. I'd like to be able to load schemas from PHP files. Since I'm doing all of this validation and instance interpreting in PHP anyway, it's only natural for me to be working with native PHP associative arrays, rather than writing them in JSON and having to convert on the fly. Not sure how you would get that to play nice with $refs and 'extends', but no doubt it could be done.

On an unrelated note, I don't know if you have anything to do with it, but it would be great if someone could document the full syntax and capabilities of $ref more fully somewhere. I get the impression it can be used by a schema to refer to properties within itself, but I couldn't find definitive information about it anywhere, and my attempts to wire it up in my own schema caused exceptions to be thrown by the validator I'm using (the one I linked to above).

[Geraint Luff]

A "$ref" just specifies a URI - combine that with JSON Pointer fragments, and you can link to other parts within the same document by supplying a relative URI that is just a JSON Pointer fragment path, like: "#/some/pointer/path".  It's exactly the same as writing <a href="#something"> in HTML, except you get to use JSON Pointer to specify the position (relative to the root of the document), instead of explicitly labelling the target like you do for HTML.

Thanks for the suggestions - I'll have a bash at $ref support, and let you know how it goes.

Geraint

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/NC1LLLibcjQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Julian Berman]

Geraint:

By the way, I've seen you kick this idea around a bit. I've also thought about it a bit, and I did a tiny tiny tiny bit of work on a (Python) library written on top of my jsonschema implementation before noticing one of your posts on a similar idea. That lives at https://github.com/Julian/Seep/wiki/Keywords

I'd be interested in kicking around ideas with you at some point, it's on my back burner, but some day.

Julian

[Geraint]

Hi Max,

Following your feedback, I wrote a rough SchemaStore class.  A brief outline is here.  Although it's in the jsv4-php repository, it should be independent, so hopefully people can use it with other JSON Schema tools if they like.

The idea is that it should perform all sorts of normalisation for you - resolving $refs, and converts PHP arrays to objects (otherwise you'd have to write all the schema-handling code twice, once for each type).

I expect it to be action-packed with bugs, but it's a start at least.  Feedback is of course very welcome.

Geraint

[Geraint]

Julian,

Good to hear I'm not alone!  I think the more implementations there are, the more we will challenge each other with new features and the like. :)

Geraint

[Max Loeb]

Very nice, I look forward to experimenting with it. I gave your coercive validator a try this evening, and so far it works flawlessly. My only early feedback at this point is that your error messages could be more helpful. You output something like "Invalid type: string", but even better would be something like "Type error for 'foobar': expected string, found number". On a positive note, I love that it's just one file and is fairly compact (the last validator I tried requires at least 16 files). I'm off to bed, but I'll get back to it tomorrow. Keep up the awesome work.

--

[Max Loeb]

Very nice, I look forward to experimenting with it. I gave your coercive validator a try this evening, and so far it works flawlessly. My only early feedback at this point is that your error messages could be more helpful. You output something like "Invalid type: string", but I'd rather see something like "Type error for 'foobar': expected string, found number". On a positive note, I love that it's just one file and is fairly compact. The last validator I tried requires at least 16 files. I'm off to bed, but I'll get back to it tomorrow. Keep up the awesome work.

On Thu, Jul 11, 2013 at 1:31 AM, Geraint <gerai...@gmail.com> wrote:

--

[Lionel Villad]

Joining late on the conversation...

Regarding default value handling, Datapower 6.0 supports adding default values for missing properties, even when not required. This is unfortunate that the two (three?) implementations don't behave in the same way.

The question is whether there is a plan to address this issue in the V5?

Lionel

[Geraint]

It seems to me like it would be incredibly complicated to specify, and would disproportionately weigh down the standard.

Simple cases are easy enough (although even then, not every tool will want the same behaviour).  But the moment we specify any kind of value-creation/coercion rules, I believe they should be complete.  However, with the complexities surrounding "oneOf" or "dependencies" (and of course the horrors than can be expressed using "not") make that a mountain of a task.

There could be something like a wiki page, or a repo with some simple examples/tests, so that developers can see roughly how other people are handling it, but I'm not sure about actually going into the spec.