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

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

On Thu, May 26, 2016 at 1:37 PM, John Cowan <[e-mail]> wrote:

> 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.
>

I don't really consider different types of integer to be different types.
They are different representations of whole numbers, they are all
intrinsically the same type.

There is a similar error in Pascal which in the ANSI standard has the
ludicrous insistence that int [2] is a different type to int [3]. And there
is no cast operator. Small wonder people used to refer to it as being
'Wirthless'

Yes, real numbers and integers are probably things you want to be able to
treat differently in code because it is very very rare to need or want a
real64 number in a protocol.

I have no problem with limiting the intrinsic types to the set given in
JSON. What I mean by strong typing is that when I convert a JSON data
stream I convert it to a data model that has classes and structures that
are in the application data model. So I write code of the form:

Profile.Applications.Add (MailApplication);

Rather than something like

Tree.Append (Profile, "Profile.Applications", MailApplication.Tree());


Yes, if you use a fully dynamic binding language, you can write code that
looks like the first example. But what you don't get in that situation is
static type checking on your code. My code sill throw a compiler error if I
try to add a DeviceProfile in a slot typed as a list of ApplicationProfile.



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

Mostly agree as a starting point. But I think that you absolutely want to
be able to put binary blobs of data in a stream and distinguish them from
strings.

I have spec, running code and apps written in it.


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

That is an interesting one because it comes down to how do you want
extensibility to work. In particular, when do you want adding things to be
backwards compatible and when do you want to cause things to halt rather
than have an application try to act on data it did not fully understand?



> 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.
>

This is actually a little problematic as in JSON any slot can hold null
while many languages don't allow integers or booleans to be null.

C# has nullable types for integers and booleans. But lots of languages
don't. I am very wary of writing protocol logic that would depend on such a
distinction.