itemscript also provides a reference client implementation called Item Lens and a reference server called Item Store.

class Foo
{
int? bar; // Obviously nullable.
int[] baz; // I’m not convinced it’s good if this can be null in the strictest sense. Should have a minimum two elements, maximum 8
string qux; // This probably ought to be a proper name with no funny characters
}

class Foo
{
int? bar; // Obviously nullable.
int[] baz; // I’m not convinced it’s good if this can be null in the strictest sense. Should have a minimum two elements, maximum 8
string qux; // This probably ought to be a proper name with no funny characters
}

It is equally obvious that having a standard means of specifying the structure and type of JSON objects has the potential to add great value. Given that, you might be on the wrong track when you say “document validation is overrated”. That sort of generalization really doesn’t provide any insight without some sort of context.

Now, as far as the stipulation that “schema languages should be designed to communicate the structure of documents to humans, and only incidentally to validator programs”, I’m putting that in the “wrong track” column. Maybe I’m missing something, but it doesn’t make a lick of sense. You can use C#, Java, Ruby or whatever to define your JSON structures, and check them with the compiler.

A JSON schema should primarily exist to allow applications to validate JSON instances. Tools could generate schemas from objects or vice versa. Of course it should be human readable, that’s a given.

As the link describes, it is an attempt for a json relax ng schema, and a quite goo one in fact. It seems to be in early development stages, and by that I mean they may not be validators written to parse this schema yet.

I will be pursing this language as it seems promising; However, Kwalify, may be my only other choice., but a JSON schema in JSON does not seem so wise. Already this new schema allows for more than Kwalify.

I am not especially happy with the results but it does work.

Your JSON schema is interesting. However it feels a lot like Kwalify. Any reason you did not just implement support for Kwalify schemas?

Regarding the percieved baggage of XML schemas, i just have to say that I have no problems with XML schemas, they work just fine for the most part and XSD is better then XDR which is better than DTDs so we are at least moving forward. Regarding XML schema validation, I have typically had to shut it off due to the performance costs.

What I typically use XML schemas for is to help generate valid XML inputs to non-REST web services. Also, they can be used to auto-generate UIs. They are also useful for generating “Beans” (if the schema is good) when using Java/C# or similar.

I would love to see JSON schemas for the same reasons. I could auto-generate things like registration forms, we could finally have a standard JSON format for things like RSS, Atom, OPML, etc.

JSON is the best transport for client apps written in javascript, bringing some order to the party would not hurt if it is done right.

this blog entry seams to be off to a good start, but it would really need to be enhanced to be of any real use: http://www.epiphantastic.com/?p=22

standards and structure are good, so long as it is not for their own sake.