A lingering problem with the current specification

[Francis Galiegue]

Hello list,

I'd like to have your opinion about this...

This simple schema:

{
"type": "null"
}

can also be written as:

{
"type": [ { "type": "null" } ]
}

and so on recursively. But also:

{
"extends": { "type": "null" }
}

and so on recursively as well.

To my eyes, this is a problem in design. What's more, it makes
implementations quite difficult. And I don't even mention schemas in
"dependencies". My implementation covers it all, in fact it covers all
of draft v3 except custom types, custom format specifiers and accurate
"style" format specifier. It is easily extensible to cover future
keywords like "minProperties", "maxProperties" and the redefined
"required" as well.

But the code reflects the spec: complicated. Too complicated. I'd go
as far as to say, "convoluted".

Now, consider:

{
"and": [
{ // one schema here },
{ // another schema here }
]
}

{
"or": [
{ // one schema here },
{ // another schema here }
]
}

{
"not": { // schema here }
}

I don't think there is the need to explain what each of these supposed
keyword would do...

... And that's the point: they are _simple_. Simple to understand also
means simple to implement, and it allows to get rid of "extends",
schemas within "type" and the whole "disallow" keyword.

I propose that draft v5 set these as a target.

Comments?
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[Gary Court]

I agree. I have had this exact same thought and proposed solution in
my mind for some time as well.

--Gary

[Xample]

Don't forger the "one" which would allow to make enums of schemas and not only values

Gary: we are waiting on you :-)