Re: [Json] Another problematic JSON Schema use-case

[Phillip Hallam-Baker <[e-mail]>]

The core problem with 'JSON Schema' is that either you like strongly typed
languages or you don't.

I have some very strong opinions on the advantages of strong typing. My
college tutor was Tony Hoare. But a lot of people don't see the point just
as a lot of folk in the nuclear physics lab used to turn off compiler
warnings to 'get rid of' their errors.

If you don't like strong typing then you probably won't see the value of a
schema language because you will be using languages that allow you to write
something like this

var DOM = JSON.Parse (Textfile);

Where JSON.Parse is a completely generic function that dumps out a tree
that you can then access through dynamic binding.

Dynamic binding certainly has advantages but it has what people from my
camp consider to be the serious disadvantage that you can't do static type
checking at compile time.

It also has the disadvantage that you end up with code that looks like this:

struct Furniture {
    string: Name;
    string: Type;
    }

Which serializes as

"Furniture" : { "Name" : "Aeron", "Type" : "Chair" }

Which is fine, if you don't want to use an object oriented language where
you would write something like:

class Furniture {
    string: Name;
    }

class Chair : Furniture {
    }

Which would typically serialize as :

"Chair" : {Name: "Aeron"}


If you design a protocol with strong typing in mind it is highly unlikely
that you are going to have problems using dynamic binding as a result. But
the reverse is not the case.

Since I do security, I insist on static type checking. Perl is fine for
writing a Web site mashup. It isn't something I would want to see used on a
CA.