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

[John Cowan <[e-mail]>]

Phillip Hallam-Baker scripsit:

> I have some very strong opinions on the advantages of strong typing.

Even if you accept the principle of strong typing, that is not conclusive
as to how many atomic types you have.  Most programming languages have
only one string type, or at most have a family of types varying only by
length or maximum length.  But it would be possible to declare the type
of a string using a regular expression, and Cobol approximates this with
its PICTURE types.

On the other hand, statically typed languages typically have multiple
types of numbers: C has 14, Java has 7, Pascal has 2, and Algol 68 has
a denumerably infinite number (short int, short short int, short short
short int, etc.) all statically distinct, though normally only a finite
number of distinct run-time representations.

If we stick to JSON's mutually exclusive atomic types of null, boolean,
number, string, we can devise a very simple schema language for static
typing only.  Most of the complexity comes from wanting to provide more
complex static types such as integer vs. non-integer, exact vs. inexact,
or highly constrained strings.

===========

Here's a sketch of a simple schema-by-example language:

The type 'any JSON number' is encoded by any JSON number.

The type 'any JSON boolean' is encoded by any JSON boolean.

The type 'any JSON string' is encoded by any JSON string not specially
mentioned here.

The type 'JSON array of fixed size with fixed types' is encoded by
a JSON array whose elements are the encodings of the fixed types.
This corresponds to a tuple in some statically typed languages.

The type 'JSON array of variable size with fixed element type' is encoded
by a JSON array whose first element encodes the element type and whose
second element is the string "...".  This corresponds to a list in some
statically typed languages.  It can be combined with the last rule to
allow arrays whose first few elements have different element types,
and any additional elements have the same type.

The type 'arbitrary JSON array' is encoded by the JSON string "[]".

The type 'JSON object with fixed keys' is encoded by a JSON object
whose keys are the fixed keys and whose values encode the types of their
corresponding keys.

The type 'JSON object with arbitrary keys' is encoded by the JSON string
"{}".

The type 'arbitrary JSON value' is encoded by the JSON string "*".

Open questions:

1) What about a JSON object with fixed keys that also allows arbitrary
additional keys?

2) What about null?  It can be treated as the sole inhabitant of a unique
atomic type encoded by a JSON null, or as something not mentioned in
schemas that is always allowed in place of any JSON value (like SQL null),
or as a replacement for arrays and objects only.

-- 
John Cowan          http://www.ccil.org/~cowan        [e-mail]
                if if = then then then = else else else = if;