an alternative to existing means of union specification

[Lloyd Hilaiel]

today a union is specified thus:

{
"type": [ "string", "integer" ],
"minLength": 3,
"maxLength": 10,
"minimum": 0,
"maximum": 42
}

Here's an alternative that perhaps is clearer and more flexible:

{
"type": "union",
"schemas": [
{ "type": "string", "minLength": 3, "maxLength": 10 },
{ "type": "integer", "minimum": 0, "maximum": 42 }
]
}

more flexible because it allows multiple schemas of the same type with
different constraints to be specified:

{
"type": "union",
"schemas": [
{ "type": "string", "format": "date" },
{ "type": "string", "format": "datetime" }
]
}

an interesting feature of this change is that you would never have
constraints relating to different types combined in the same schema.
This allow for the possibility of collapsing minLength, minItems, and
minimum all into a single property.

lloyd

[Seth Wessitsh]

Hi Lloyd,

The JSON Schema spec says the items in the type array may be simple types or schemas, so the union type you specify can already be given as:
{
  type: [

    { type: "string", minLength: 3, maxLength: 10 },
    { type: "integer", minimum: 0, maximum: 42 }
  ]
}

I think the reasoning behind having the minLength, minItems, and minimum separate properties is, for one, because the type restriction isn't required so the previous schema could also be specified as:
{
  type: [
    { minLength: 3, maxLength: 10 },
    { minimum: 0, maximum: 42 }
  ]
}

Another reason might be that one might want to use an existing schema within their union and further constrain it without modifying the original.  For example:
{ id: "toy1", type: "string", minLength: 3, maxLength: 10 }
{ id: "toy2", type: "integer", minimum: 0, maximum: 42 }

Assume for simplicity's sake that the schemas can be retrieved by their id's:
{
  type: [ "toy1", "toy2" ],
  minLength: 5,
  minimum: 2,
}

The new union type can make use of some of the restrictions from the toy1 and toy2 schemas while further constraining those that it wishes.
   

Seth C. Wessitsh
se...@wessitsh.com

--

You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To post to this group, send email to json-...@googlegroups.com.
To unsubscribe from this group, send email to json-schema...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-schema?hl=en.

[Lloyd Hilaiel]

Yo Seth,

Thanks for the clarification. I didn't realize full schemas were
allowed as values to type! So this addresses my concern about
flexibility, but not simplicity.

A question that arises is then for your example:

{ id: "toy1", type: "string", minLength: 3, maxLength: 10 }
{ id: "toy2", type: "integer", minimum: 0, maximum: 42 }

{

type: [ "toy1", "toy2" ],
minLength: 5,
minimum: 2
}

isn't this the same as:

{
type: [ { extends: "toy1", minLength: 5},
{ extends: "toy2", minimum: 2] ]
}

More directly I guess I'm wondering, The ability to have both distinct
constraints and common constraints in the case of a union schema
definition seems to have no utility, and makes the grammar more
complex. There must be an example I'm missing where that feature adds
expressivity. otherwise things could get simplified down to this:

[ { extends: "toy1", minLength: 5},
{ extends: "toy2", minimum: 2] ]

(if a schema is an array, then it is a union type)

am I now missing something else? :)

lloyd

[Seth Wessitsh]

Nope, actually it's me who missed something this time. You're correct that my example could be expressed as you point out.
I can't really think of a good reason for having this ability either.  I think the only reason that this is the case is that it allows all schemas to be constrained by the same rules.  I would think this would make it easier to validate a schema.  Unfortunately, it also allows one to define a schema in perhaps a less than succinct manner and in some cases do non-sensical things.

Seth C. Wessitsh
se...@wessitsh.com

lloyd