Re: [Json] Schemas & so on

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

On Tue, May 3, 2016 at 3:50 PM, John Cowan <[e-mail]> wrote:

> Phillip Hallam-Baker scripsit:
>
> > 1) Order in which the elements appear.
>
> My understanding is that people do use JSON arrays this way: the first
> element means X, the second means Y.  If arrays are always or almost
> always used in a uniform way, then we don't have to worry about order,
> just specify a single type type for all the individual elements.
>
> > 2) alternatives
>
> No cases of number-or-string, or object-or-null?
>

I don't allow number or string or see the need.

For all fields I allow the following

Minimum Occurrences = 0 or 1
Maximum Occurrences = 1 or unlimited.

Null is only allowed if the Minimum Occurrences is 0. If Max is unlimited
then the field maps to a list rather than a simple variable and the
corresponding serialization is an array.

That is possibly too strict as right now going from max occurs 1 to
unlimited breaks backwards compatibility as the serialization changes from
item to array[item]. I could probably be loser there.


There might be an argument to be made for any 'Any' field type which can
contain anything. I don't support that right now. But I might have to
rejigger my parser if I am supporting ACME and they don't go to the nested
approach.

ACME has the following type system, lets say you are sending a Delete
request, an acceptable message serialization would be:

{ "field1" : "data",
 "field2" : "data",
 "field3" : "data",
 "type" : "Delete",
 "field4" : "data",
 "field5" : "data"}

The only way this can be supported is to parse the entire JSON tree to an
intermediate format and then perform schema processing on the tree. Which
is fine if that is the way you want to do things and you are not writing a
transaction where field1 might be several Gb and so you want to check if
you understand the transaction before accepting the data or otherwise
concerned about being practical.


If I have to support the above, I will probably do so by pre-parsing the
tree and so it would be fairly straight forward to support a variant type.

But there would have to be a good reason because it is going to have to be
mapped to a C / C# / Java type sometime.



>
> > 3) model groups
> > 4) the bizaro dual type system in which elments type data and types type
> > elements.
> > 5) Distinguishing attributes and elements
>
> Agreed on those.
>
> --
> John Cowan          http://www.ccil.org/~cowan        [e-mail]
> "But I am the real Strider, fortunately," he said, looking down at them
> with his face softened by a sudden smile.  "I am Aragorn son of Arathorn,
> and if by life or death I can save you, I will."
>