View this page "JSON Schema Examples"

[Claudio D'Angelo]

I've added a page where insert json schema examples

Click on http://groups.google.com/group/json-schema/web/json-schema-examples?hl=en
- or copy & paste it into your browser's address bar if that doesn't
work.

[Kris Zyp]

This looks great Claudio, good job. One comment, nesting unions
directly in unions is valid, but not necessary. For example ["null",
["string", "object"]] (which means it can be a null or a string or
object) is equivalent to ["null","string","object"]. Nesting unions
inside of arrays inside of unions is necessary to describe some types.
For example:
["null", [["string", "object"]]]
Indicates a null or an array of strings or objects.
However, there is nothing wrong with your examples, I assume you did
that to demonstrate the different ways you can combine syntax, and
this does indeed demonstrate the capabiliities.

[Kris Zyp]

My message was truncated...
Just wanted to mention the simplification you can do on union types,
but your examples are all correct, and do a good job of demonstrating
the typing capabilities of JSON Schema.

[Claudio D'angelo]

Do you intend
{ "type" : ["null", ["string", ["boolean"], [["string", "integer"]] ]] }
is equivalent to
{ "type" : ["null", "string", ["boolean"], [["string", "integer"]] ] }
?
P.S.: you can adds other example. This is useful for me to test my
application.

Kris Zyp ha scritto:

[Claudio D'angelo]

Please, help me to analyse these case:
{
"type" : ["null", [["null","string"]]],
"maxItems" : 3,
"pattern" : "patt"
}

is equals to array nullable of string and null with maxItems = 3
...
and

{
"type" : ["null", {

"type" : [["null","string"]]
}],

"maxItems" : 3,
"pattern" : "patt"
}
is equals to array nullable of string and null with maxItems not setted

What do you think? If you use an object the system reset the options in
the root. You must do:
{
"type" : ["null", {

"type" : [["null","string"]],

"maxItems" : 3,
"pattern" : "patt"
}],
}

[Kris Zyp]

>
> Please, help me to analyse these case:
> {
> "type" : ["null", [["null","string"]]],
> "maxItems" : 3,
> "pattern" : "patt"
> }
>
> is equals to array nullable of string and null with maxItems = 3

Yes, that is correct.

> ...
> and
>
> {
> "type" : ["null", {
> "type" : [["null","string"]]
> }],
> "maxItems" : 3,
> "pattern" : "patt"
> }
> is equals to array nullable of string and null with maxItems not setted

No, this is not a valid schema, the value for the type property or in the
union values must be a type definition, not a property definition. This
would be defining an array of objects that have a property of "type", but
the property definition for "type" is not valid (and clearly not what you
were intending).
You can do this:
{
"type" : ["null", {
"myProp":{"type" : [["null","string"]]}

}],
"maxItems" : 3,
"pattern" : "patt"
}

But I am not sure what you are trying to do...
Kris

[Claudio D'angelo]

See this case:
I want a schema to validate an attribute that can contain: or an array
of string with maxItems= 9 or an array of number with maxItems=10:

{
"type" : ["null", {"type" : [["null","string"]],

maxItems : 9
},
{"type" : [["null","integer"]],
maxItems : 10
}

],
"pattern" : "patt"
}

Kris Zyp ha scritto:

[Claudio D'angelo]

Is correct to have a schema how:
{ "type" : "string",
"pattern" : "..."
}

This is a schema for an attribute.
Or the schema must start with a object/array element declaration?

[Kris Zyp]

You simply can't do that with JSON Schema. You can't union property
definitions, and I don't think the use case is compelling enough to warrant
a different syntax.
Kris

[Kris Zyp]

Yes, with the change made a few days ago, that is correct, you can have a
schema that indicates that the instance is a string, like you did below.

Kris
----- Original Message -----
From: "Claudio D'angelo" <claudio...@lombardia-servizi.it>
To: <json-...@googlegroups.com>
Sent: Friday, January 11, 2008 1:37 AM
Subject: Re: Discussion on json-schema-examples

>

[Claudio D'angelo]

I think that this is a strong constraint. In this manner I can't use
different type af array in the union.

The expression :

{ "type" : [["null","string"]]}
isn't a property definition but a type definition.
In another mail you tell me that
{"type" : "string" }
is a valid schema definition... but it isn't a property definition (what property?) but a type definition that a property can use. In this case an union use type definition.

What about?

Kris Zyp ha scritto:

[Kris Zyp]

> I think that this is a strong constraint. In this manner I can't use
> different type af array in the union.

Is there another language typing or schema out there that has this type of
expressibility? I just don't think there is enough use cases for this to
warrant the added complexity of dealing with unions at the property
definition level and the type definition level.

> { "type" : [["null","string"]]}
> isn't a property definition but a type definition.

This is a property definition object.
{ "type" : [["null","string"]]} -> property definition object
[["null","string"]] -> type definition

> In another mail you tell me that
> {"type" : "string" }
> is a valid schema definition...

Yes the semantics of property definition object equal the semantics of
schema. A schema is basically just a root level property definition object
.
Sorry, for the confusion, I really need to make a graph/illustration of this
to clear things up.
Kris

[Claudio D'Angelo]

On 11 Gen, 16:45, "Kris Zyp" <kris...@gmail.com> wrote:
> > I think that this is a strong constraint. In this manner I can't use
> > different type af array in the union.
>
> Is there another language typing or schema out there that has this type of
> expressibility? I just don't think there is enough use cases for this to
> warrant the added complexity of dealing with unions at the property
> definition level and the type definition level.
>

XMLSchema and all language that use the collection.
This cover all cases (I hope) because adds the apportunity of use any
type. (I can use float with [maxDecimal=6, minimum=6, maximum=9] and
float [maxDecimal=3, minimum=10, maximum=12] in the same array. This
mode is more flexible.

> > { "type" : [["null","string"]]}
> > isn't a property definition but a type definition.
>

Why you talk of property?
If my schema starts with:
{ "type" : { "attr1" : {...}, ...}
I talk of object definition and not property definition.
The same json object ({ "type" : [["null","string"]]} ) describes a
type and not a property.

> This is a property definition object.
> { "type" : [["null","string"]]} -> property definition object
> [["null","string"]] -> type definition
>
> > In another mail you tell me that
> > {"type" : "string" }
> > is a valid schema definition...
>
> Yes the semantics of property definition object equal the semantics of
> schema. A schema is basically just a root level property definition object

Sorry but this statement is confused. If I use a json object how root
is a type definition while if I use
the same json object in an union or array is a property definition?

Sorry but I don't see problem to use type (or property) object
definition in an union or array. Moreover in this case
you can clean the schema, inserting in array declaration only the
property of the array:

{ "type" : [
[
{"type" : "string", "pattern":"xxx"},
{"type" : "number", "format" : "integer",
"maximum" : 10}
]
],
"maxItems" : 100
}
instead of
{ "type" : [["string", "number"]],
"pattern" : "xxx",
"format" : "integer",
"maximum" : 10,
"maxItems" : 100
}

moreover there could be conflicts:
{ "type" : [["string", ["string"]]],
"pattern" : "xxx", <= this pattern is for the string or array of
strings?
"maxItems" : 100 <= this constraints is for the principal array or
the nested array?

[Kris Zyp]

> XMLSchema and all language that use the collection.
> This cover all cases (I hope) because adds the apportunity of use any
> type. (I can use float with [maxDecimal=6, minimum=6, maximum=9] and
> float [maxDecimal=3, minimum=10, maximum=12] in the same array. This
> mode is more flexible.

I really that this increases the expressibility of JSON Schema in being able
to define things like this, but doesn't it also add complexity. This one
just seems like a very low usage capability for the complexity, but I am
open to it.

> I talk of object definition and not property definition.
> The same json object ({ "type" : [["null","string"]]} ) describes a
> type and not a property.

> Sorry but this statement is confused. If I use a json object how root

> is a type definition while if I use
> the same json object in an union or array is a property definition?

Perhaps we should use different names?

> Sorry but I don't see problem to use type (or property) object
> definition in an union or array. Moreover in this case
> you can clean the schema, inserting in array declaration only the
> property of the array:
> { "type" : [
> [
> {"type" : "string", "pattern":"xxx"},
> {"type" : "number", "format" : "integer",
> "maximum" : 10}
> ]
> ],
> "maxItems" : 100
> }
> instead of
> { "type" : [["string", "number"]],
> "pattern" : "xxx",
> "format" : "integer",
> "maximum" : 10,
> "maxItems" : 100
> }

Good point.

>
> moreover there could be conflicts:
> { "type" : [["string", ["string"]]],
> "pattern" : "xxx", <= this pattern is for the string or array of
> strings?
> "maxItems" : 100 <= this constraints is for the principal array or
> the nested array?
> }

Another good point. Still hestitant because of the increase in verbosity and
structural complexity, but I will keep thinking about it, and we can keep it
open idea for discussion.
Kris

[Kris Zyp]

> XMLSchema and all language that use the collection.
> This cover all cases (I hope) because adds the apportunity of use any
> type. (I can use float with [maxDecimal=6, minimum=6, maximum=9] and
> float [maxDecimal=3, minimum=10, maximum=12] in the same array. This
> mode is more flexible.

I really that this increases the expressibility of JSON Schema in being able

to define things like this, but doesn't it also add complexity. This one
just seems like a very low usage capability for the complexity, but I am
open to it.

> I talk of object definition and not property definition.

> The same json object ({ "type" : [["null","string"]]} ) describes a
> type and not a property.

> Sorry but this statement is confused. If I use a json object how root

> is a type definition while if I use
> the same json object in an union or array is a property definition?

Perhaps we should use different names?

> Sorry but I don't see problem to use type (or property) object
> definition in an union or array. Moreover in this case
> you can clean the schema, inserting in array declaration only the
> property of the array:
> { "type" : [
> [
> {"type" : "string", "pattern":"xxx"},
> {"type" : "number", "format" : "integer",
> "maximum" : 10}
> ]
> ],
> "maxItems" : 100
> }
> instead of
> { "type" : [["string", "number"]],
> "pattern" : "xxx",
> "format" : "integer",
> "maximum" : 10,
> "maxItems" : 100
> }

Good point.

>
> moreover there could be conflicts:
> { "type" : [["string", ["string"]]],
> "pattern" : "xxx", <= this pattern is for the string or array of
> strings?
> "maxItems" : 100 <= this constraints is for the principal array or
> the nested array?
> }

Another good point. Still hestitant because of the increase in verbosity and

[Claudio D'Angelo]

On 12 Gen, 06:41, "Kris Zyp" <kris...@gmail.com> wrote:
> > XMLSchema and all language that use the collection.
> > This cover all cases (I hope) because adds the apportunity of use any
> > type. (I can use float with [maxDecimal=6, minimum=6, maximum=9] and
> > float [maxDecimal=3, minimum=10, maximum=12] in the same array. This
> > mode is more flexible.
>
> I really that this increases the expressibility of JSON Schema in being able
> to define things like this, but doesn't it also add complexity. This one
> just seems like a very low usage capability for the complexity, but I am
> open to it.
>

Yes but "you don't must.... you can" , this is, the complexity is
added only if you have needed it.

type definition :
"[type]" | [] | {} // simple definition with default values
or
{ "type" : "[type]", ...} // complex definition

whe can use also:

{ //object description
type : {
"name" : "string",
"surname" : "string",
"age" : { "type" : "number", "format" : "integer" }
}

What do you think?
And all others? What about?

[Kris Zyp]

First, I updated the JSON Schema proposal with a BNF grammar, to provide a
solid definition to the nomenclature of schema, property definition (changed
the meaning of this a little), and type definition. Hopefully our discussion
can be a little less confusing with well defined terms.
Second, I wanted to put couple questions regarding JSON Schema up for vote:
1. Currently in JSON Schema, there is a type attribute where you can define
primitive types (roughly corresponding to the different JSON types) with a
small constrained set of values. There is also a format attribute that
allows a wider range of subtypes or formats. The formats are almost
exclusively transported with JSON strings. The question which types/formats
should be included in list of possible types and which should be in included
in the list of formats. The currrent state of the proposal is checkmarked.
You can vote by changing the checkmarks (or leaving them alone). You can
also change the names if you would like. I ommitted the ones that seem
obvious (I think boolean should clearly be a type), these are mostly items
that are less obvious or defined differently in other schemas. If you
disagree feel free to add them to your vote:
type format name
[x] [ ] integer (Claudio suggested removing this from both
type and format, and defining integers by the maxDecimal attribute)
[ ] [x] dateTime
[ ] [x] date
[ ] [x]
[ ] [x] regex
[ ] [ ] function (there is no function type because there is
no function in JSON due to lack portability)
[ ] [x] uri
Or alternatively vote with:
[ ] Just keep the set of possible types equivalent to the JSON primitive
types (string,boolean,number,object,array,null), everything should be a
format
[ ] Same as above except also allow "any".

2. Should union capabilities be applicable to schemas in property
definitions in addition to union capabilities in type definition?
Currently, you can define a property to allow a string or number like:
"myProp": {"type":["number":"string"], "maximum":100, "maxLength":3}
It has been suggested that the union capability could be applied to the
schema for the property as well, so this could alternately be defined:
"myProp": [{"type":["number"], "maximum":100}, {"type":["string"],
"maxLength":3}]
[ ] only allow union on type definitions (only allow the first example)
[ ] allow union on type definitions and schemas (allow both examples)

Kris

----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Sent: Saturday, January 12, 2008 12:50 AM
Subject: Re: Discussion on json-schema-examples

>

[Kris Zyp]

I get to vote, right? :)
> type format name
[] [] integer

I agree with Claudio, I think there should just be number.

[ ] Just keep the set of possible types equivalent to the JSON primitive

[x] Same as above except also allow "any".

I like the idea of keeping a strict connection between JSON value types and
types defined in JSON Schema.

[x] only allow union on type definitions (only allow the first example)

[Matt (MPCM)]

[] Just keep the set of possible types equivalent to the JSON
primitive...
[X] Same as above except also allow "any".

Another thought, let the absence of any specific type(s) signify no
restrictions ("any"). Unless any empty type array has another
meaning...

[] only allow union on type definitions (only allow the first example)
[X] allow union on type definitions and schemas (allow both examples)

The second example makes clear sense to me, as format concepts are
somewhat linked to the type. Some overlap, but trying to apply a
length of 3 to a number does not make any sense to me, nor applying a
maximum of 100 to a string. The first example feels very unclear to
me.

I'm also guessing that should have been "number","string and not
"number":"string.

--
Matt

[Kris Zyp]

> Another thought, let the absence of any specific type(s) signify no
> restrictions ("any"). Unless any empty type array has another
> meaning...

That is indeed how it is currently works.
"If the property is not defined or is not in this list, than any type of
value is acceptable."
We could certainly remove the "any" type since it can be expressed by not
including the type property.

> I'm also guessing that should have been "number","string and not
> "number":"string.

Oops, thanks, you are right, the first example should have been:
"myProp": {"type":["number","string"], "maximum":100, "maxLength":3}

[Matt (MPCM)]

> We could certainly remove the "any" type since it can be expressed by not
> including the type property.

The type as an array of restrictions (i.e. restricted to these types),
empty meaning no restrictions. It does cleanly remove the need for
"any", which does not match a json type. So I guess my vote is
switched to be just json types, with an empty array meaning any.

Sorry for the confusion.

[Kris Zyp]

These are some more semantic questions up for vote. These main questions are
about the name of the attribute properties:

1. Should we have separate definitions for minimum/maximum for a number, for
the minimum and maximum length of a string, and minimum and maximum number
of items in an array, or should they be combined in a single attribute.
[ ] separate minimum, minItems, minLength, max...
[ ] combine in one bi-property minimum/maximum.
[ ] combine two, keep one separate.

2. The number (or overloaded property, depending on vote from above) minimum
and maximum should be:
[ ] min/max
[ ] minimum/maximum - currently in the proposal.

3. Specifying possible values for a property:
[ ] options - currently in the proposal
[ ] enum
[ ] enumValues
[ ] enumeration

4. title
[ ] add title as a short description of a schema or property
[ ] leave title out (it is not currently in the spec)

5. final
[ ] remove the final attribute. One can indicate no additional properties
are allowed by setting the additionalProperties attribute to false (also
indicating the schema should not be extended)
[ ] keep final attribute as a way to indicate that the schema should not be
extended

[Scott Clarke]

[ ] Same as above except also allow "any".

Keep it simple and the same as JSON but  i think the the inclusion of "any" or just "" (blank) is important to provide additional flexibility.
 

 

[X ] allow union on type definitions and schemas (allow both examples)

Allow for both for flexibility.

 

[Scott Clarke]

1. Should we have separate definitions for minimum/maximum for a number, for
the minimum and maximum length of a string, and minimum and maximum number
of items in an array, or should they be combined in a single attribute.
[ ] separate minimum, minItems, minLength, max...

[X ] combine in one bi-property minimum/maximum.

[ ] combine two, keep one separate.

This one is tough to answer without examaples but i think would be the easiest to write and understand without additional complexity

 

2. The number (or overloaded property, depending on vote from above) minimum
and maximum should be:
[ ] min/max

[X ] minimum/maximum - currently in the proposal.

spell it out for clarity and for people who english isn't their first language.

3. Specifying possible values for a property:

[X ] options - currently in the proposal
[ ] enum
[ ] enumValues
[ ] enumeration

think 'option' on this one would be clearest to most people. I don't think enumeration is something all javascript programmers know and understand, but everyone understands options.

 

4. title
[X ] add title as a short description of a schema or property (

[ ] leave title out (it is not currently in the spec)

I think title may be helpful in some siutations, but it should be optional so we don't add unnecessary bloat to rpc requests/responses.

 

5. final
[ ] remove the final attribute. One can indicate no additional properties
are allowed by setting the additionalProperties attribute to false (also
indicating the schema should not be extended)
[ ] keep final attribute as a way to indicate that the schema should not be
extended

i dont have an opinion on this one either way. Maybe allow for both options and leave it up to the developer to decide whats best for their given situation.



there is my .02 cents.

[SMM]

I agree with (and vote for) limiting to just the JSON types
("boolean", "number", "string", "object", "array", "null") as there
technically isn't any support for any other types. Everything more
specific (e.g. "float", "integer", "dateTime", "date", "time", etc.)
becomes a format or restriction placed upon one of the primative
types. "Any" is specified by a lack of restriction of "type".

As for unions, I think the option which keeps the restrictions paired
with the type makes the most sense. This doesn't really need an array
for the value of "type", since the array is around the schema for
"myProp":

[X] "myProp": [{"type":"number", "maxValue":100}, {"type":"string",
"maxLength":3}]

Thanks,
Stephen

[SMM]

1. Should we have separate definitions for minimum/maximum for a
number, for
the minimum and maximum length of a string, and minimum and maximum
number
of items in an array, or should they be combined in a single
attribute.

[X] separate minimum, minItems, minLength, max...

[ ] combine in one bi-property minimum/maximum.
[ ] combine two, keep one separate.

It makes sense often to only specify one (e.g. non-negative numbers).
And makes easier to read/parse.

2. The number (or overloaded property, depending on vote from above)
minimum
and maximum should be:
[ ] min/max
[ ] minimum/maximum - currently in the proposal.

[X] minValue/maxValue

This third choice seems consistent with minLength, maxLength. My
second choice would be min/max as it is shorter and widely accepted
abbreviation.

3. Specifying possible values for a property:
[ ] options - currently in the proposal

[X] enum
[ ] enumValues
[ ] enumeration

I think many languages provide "enum" ability or ability to create
enumerations. "Options" feels more vague as it is overloaded in other
contexts.

4. title
[ ] add title as a short description of a schema or property
[ ] leave title out (it is not currently in the spec)

[X] add "annotation" as a short description of a schema or property,
alt. name is "comment"

Again adding an additional choice: I know in XML Schema there is a
pretty widely used capability to annotate a schema with copyright or
informational messaging. Title is very specific as to its usage which
means that it may be overloaded for other usages.

5. final
[X] remove the final attribute. One can indicate no additional

properties
are allowed by setting the additionalProperties attribute to false
(also
indicating the schema should not be extended)
[ ] keep final attribute as a way to indicate that the schema should
not be
extended

I also don't have strong feelings on this. If I recall, XML Schema
are effectively "final" by default, because if it doesn't conform to
what is specified then it is invalid. Having an area which allows
"any" opens it up for extension. You can always "inherit" from a
definition and further restrict it but you can't add to it.

Thanks,
Stephen

[Kris Zyp]

> I also don't have strong feelings on this. If I recall, XML Schema
> are effectively "final" by default, because if it doesn't conform to
> what is specified then it is invalid. Having an area which allows
> "any" opens it up for extension. You can always "inherit" from a
> definition and further restrict it but you can't add to it.

I need spell this out in the spec, but extending a schema must follow rules
for sane type narrowing. That is if B extends A, then any instance that is
valid by B, must be valid by A. If A allows additional properties, an
extended schema B can define additional properties without violating A.
Properties can also be redefined as long as it narrows the type. For example
one could define property foo to be type:["string","null"], and B could
define foo to be type:"string"

[Stephen McKamey]

That sounds logical. That way A would still validate, yet B could
enforce tighter restriction for a particular application of A.

So as an example (which might not really be practical), JSON-RPC could
define the message envelope and a particular service could define
specific usages of that envelope for a particular method.

[Matt (MPCM)]

Extends might not be the best wording, as you are always implying
creating a tighter subset of certain fields. How do you feel about
`refines`?

This definitely needs to be spelled out. I would find it confusing
initially that I could not broaden the type on a schema which I was
extending.

[Stephen McKamey]

I agree "extends" implies adding to, "restrict" implies removing
flexibility from. Not to keep bringing up XML Schema but I think that
it serves as a good analogy for at least reflecting upon.

XML Schema supports both Deriving Types By Extension:

http://www.w3.org/TR/xmlschema-0/#DerivExt

as well as Deriving Types By Restriction (what is being proposed
here):

http://www.w3.org/TR/xmlschema-0/#DerivByRestrict

I see validity to both. Back to my earlier vote about "final" being
unnecessary, I take that back if there is also the concept of deriving
by extending.

[Kris Zyp]

My vote:

> 1. Should we have separate definitions for minimum/maximum for a number,
> for the minimum and maximum length of a string, and minimum and maximum
> number of items in an array, or should they be combined in a single
> attribute.

> [x] separate minimum, minItems, minLength, max...

> [ ] combine in one bi-property minimum/maximum.
> [ ] combine two, keep one separate.

> 3. Specifying possible values for a property:

> [ ] options - currently in the proposal

> [x] enum
> [ ] enumValues
> [ ] enumeration

> 4. title
> [x] add title as a short description of a schema or property

> [ ] leave title out (it is not currently in the spec)

> [] add "annotation" as a short description of a schema or property,
> alt. name is "comment"
Regarding "annotation": I am not sure I understand the overloading argument.
Stephen, are you worried that people will want to have their own custom
property (which is allowed) called "title", that would interfere and have a
different meaning than the title of the schema?

> 5. final
> [x] remove the final attribute. One can indicate no additional properties

[Stephen McKamey]

Sorry I should have been more clear. I mean that "title" implies a
specific usage for a free text field. If it were to be used for
copyright/licensing info then that isn't really a "title" or
"description". If the specification only has one type of free text
field (which I think is all it really needs), then I vote for it to be
named something more generalized (e.g. "annotation", "comment") so
that people aren't shoehorning other text into the only available
field.

XML Schema has annotations: http://www.w3.org/TR/xmlschema-1/#cAnnotations

[Kris Zyp]

> Sorry I should have been more clear. I mean that "title" implies a
> specific usage for a free text field. If it were to be used for
> copyright/licensing info then that isn't really a "title" or
> "description". If the specification only has one type of free text
> field (which I think is all it really needs), then I vote for it to be
> named something more generalized (e.g. "annotation", "comment") so
>that people aren't shoehorning other text into the only available
> field.

Should we have both (title and annotation)? These informational fields do
not impose any (significant) burden on implementators, just more information
to play with.
Kris

[Kris Zyp]

> I agree "extends" implies adding to, "restrict" implies removing
> flexibility from.

Yes, although adding properties and removing/limiting flexibility of
properties are not mutual exclusive, nor even opposites. The idea of
extending a schema is analogous to extending a class. One can add additional
properties in a sub-class and one can further narrow or constrain existing
properties in a sub-class. The key principle is that if B extends A, then
any instance that is valid by B, must be valid by A. As long as A does not
explicitly prevent additional properties and extension, B's schema
definition can further constrain A's properties, and it can define
additional properties. That is, if B extends A, the valid instances of B are
a subset of the valid instances of A.

> Not to keep bringing up XML Schema but I think that
> it serves as a good analogy for at least reflecting upon.

I certainly appreciate the comparisons with XML Schema, as much as possible
we should learn from it to develop JSON Schema. Thanks for the insights and
analogies.

> XML Schema supports both Deriving Types By Extension:
> http://www.w3.org/TR/xmlschema-0/#DerivExt
> as well as Deriving Types By Restriction (what is being proposed
> here):
>
> http://www.w3.org/TR/xmlschema-0/#DerivByRestrict

Both of these concepts still follow the rule of a subtype defining a subset
of instances.

Perhaps an example would help:
Address =
{type:
{street:{type:"string"},
city:{type:"string"},
zip:{type:["number","string"]},
country:{type:"string"}}}

USAddress =
{extends: Address, // inherit all the properties from Address (would use
referencing here to reference Address)
type:
{state:{type:"string"}, // define the additional property "state"
zip:{type:"number"}, // constrain the zip property to be a number
country:{type:"string",enum:["US"]}} // constrain the value to only
being "US".
}

In this example all valid instances of USAddress are also valid instances of
Address (but not necessarily vice-versa).
An example of a valid USAddress (and by implication, Address):
{street:"299 Chestnut Dr", city: "Sandy", state:"UT",
zip:84070,country:"US"}
Kris

[Jakob Kruse]

On the question of keeping or dropping the "integer" type I am clearly
in favor of keeping it!

Reason: simplicity.

Integer is a type that exists as a separate type in almost all
programming languages, databases etc. Javascript/JSON being notable
exceptions. But since we often, with a JSON Schema, need to describe
data coming from a non-Javascript source, we would need to describe
integers very often. And { type: "number", maxDecimals: 0 } is just an
ugly way of saying "integer".

Let's not restrict ourselves to types that exist as native types in
JSON. XML Schema (which is possibly one of the ugliest creations of
this world to date, but serves as a nice example in this case)
doesn't. If it did every single type in XML Schema would be a "format
restriction" on string, which is the only native XML type. What we
need is a clear and easy way to describe all the major types that we
need to communicate. Integers are a very major type, so let's not make
it too difficult, please.

/Jakob

[Stephen McKamey]

I'd ordinarily align more with the strict definitions of types in
JSON, but I have to say Jakob has a good point about the pragmatics of
including "integer". I change my vote to include "integer".

By this reasoning, it seems reasonable that "dateTime" would also be
included...

My only fear is that we might open the door to a flood of lesser used
types which have to real meaning in ES4. Is there any sort of good
heuristic which can be used to determine in or out of the spec?

[Jakob Kruse]

Stephen,

Yes, avoiding the temptation of going completely "XML Schema" and
defining a horde of only slightly meaningful types is important.

The only "heuristic" I can suggest is to model from common programming
language types and use common sense. So something like "url" wouldn't
be a type, because it is always "just" a restriction on a string, but
"datetime" would, because it usually isn't.

/Jakob

[Kris Zyp]

Maybe some more informal voting to get an idea of what we want:
1. The type attribute can contain:
[ ] only a string primitive (string,boolean,number,etc...) or a union array
(of string primitives) with sub object property definitions and array item
definitions in a "properties" and "items" attributes. This is Jakob's
suggestion, I believe.
[ ] a string primitive or a union array of strings _or schemas_ with the
same delegation to "properties" and "items" like:
type: ["number",{type:"string",pattern:"[0-9]+"}]
This is kind of Jakob's and Claudio's suggestions combined.
[ ] a string primitive or a properties definition object/object type
definition or a single element array indicating an array instance, or a
union of string primitives and schemas (I think this was the favored choice
from the last vote) like:
type:
["number",{type:"string",pattern:"[0-9]+"},{type:{foo:{type:"string"},bar:{type:"string"}}}]
[ ] The current proposal behavior of a type being an string primitive,
single element array, object type definition, or union.
If you need me to clarify these options more I can.

2. The set of types (bringing this one up again):
[ ] number, boolean, string, null, object, array
[ ] number, boolean, string, null, object, array, datetime, integer
[ ] also include any
[ ] move all formats to the type attribute. Anything besides string, number,
boolean, null, object, array, and integer would be considered a format of a
string.
[ ] move all formats to the type attribute and do subtyping of primitives in
MIME style format: boolean, text, text/url, text/phone, text/email, number,
number/integer, and so on...

----- Original Message -----
From: "Jakob Kruse" <kr...@kruse-net.dk>
To: "JSON Schema" <json-...@googlegroups.com>

[David Waite]

On Jan 24, 11:27 pm, "Kris Zyp" <kris...@gmail.com> wrote:
> Maybe some more informal voting to get an idea of what we want:
> 1. The type attribute can contain:
> [ ] only a string primitive (string,boolean,number,etc...) or a union array
> (of string primitives) with sub object property definitions and array item
> definitions in a "properties" and "items" attributes. This is Jakob's
> suggestion, I believe.

> [*] a string primitive or a union array of strings _or schemas_ with the

> same delegation to "properties" and "items" like:
> type: ["number",{type:"string",pattern:"[0-9]+"}]
> This is kind of Jakob's and Claudio's suggestions combined.
> [ ] a string primitive or a properties definition object/object type
> definition or a single element array indicating an array instance, or a
> union of string primitives and schemas (I think this was the favored choice
> from the last vote) like:
> type:
> ["number",{type:"string",pattern:"[0-9]+"},{type:{foo:{type:"string"},bar:{ type:"string"}}}]
> [ ] The current proposal behavior of a type being an string primitive,
> single element array, object type definition, or union.
> If you need me to clarify these options more I can.
>
> 2. The set of types (bringing this one up again):

> [*] number, boolean, string, null, object, array

> [ ] number, boolean, string, null, object, array, datetime, integer

> [*] also include any
> [*] move all formats to the type attribute. Anything besides string, number,

[Jakob Kruse]

My votes below (and yes, i like the KISS principle). In vote 2 I would
prefer to ditch "null" because it's a fixed value, not a type, but
let's discuss that later.

/Jakob

On Jan 25, 7:27 am, "Kris Zyp" <kris...@gmail.com> wrote:
> Maybe some more informal voting to get an idea of what we want:
> 1. The type attribute can contain:

> [X] only a string primitive (string,boolean,number,etc...) or a union array

> (of string primitives) with sub object property definitions and array item
> definitions in a "properties" and "items" attributes. This is Jakob's
> suggestion, I believe.
> [ ] a string primitive or a union array of strings _or schemas_ with the
> same delegation to "properties" and "items" like:
> type: ["number",{type:"string",pattern:"[0-9]+"}]
> This is kind of Jakob's and Claudio's suggestions combined.
> [ ] a string primitive or a properties definition object/object type
> definition or a single element array indicating an array instance, or a
> union of string primitives and schemas (I think this was the favored choice
> from the last vote) like:
> type:
> ["number",{type:"string",pattern:"[0-9]+"},{type:{foo:{type:"string"},bar:{type:"string"}}}]
> [ ] The current proposal behavior of a type being an string primitive,
> single element array, object type definition, or union.
> If you need me to clarify these options more I can.
>
> 2. The set of types (bringing this one up again):
> [ ] number, boolean, string, null, object, array

> [X] number, boolean, string, null, object, array, datetime, integer
> [X] also include any

[David Wilhelm]

On Jan 25, 2008 1:27 AM, Kris Zyp <kri...@gmail.com> wrote:

Maybe some more informal voting to get an idea of what we want:
1. The type attribute can contain:
[ ] only a string primitive (string,boolean,number,etc...) or a union array
(of string primitives) with sub object property definitions and array item
definitions in a "properties" and "items" attributes. This is Jakob's
suggestion, I believe.
[ ] a string primitive or a union array of strings _or schemas_ with the
same delegation to "properties" and "items" like:
type: ["number",{type:"string",pattern:"[0-9]+"}]
This is kind of Jakob's and Claudio's suggestions combined.
[ ] a string primitive or a properties definition object/object type
definition or a single element array indicating an array instance, or a
union of string primitives and schemas (I think this was the favored choice
from the last vote) like:
type:
["number",{type:"string",pattern:"[0-9]+"},{type:{foo:{type:"string"},bar:{type:"string"}}}]

[x] The current proposal behavior of a type being an string primitive,

single element array, object type definition, or union.
If you need me to clarify these options more I can.

2. The set of types (bringing this one up again):
[] number, boolean, string, null, object, array

[x] number, boolean, string, null, object, array, datetime, integer
[x] also include any

[Matt (MPCM)]

1. The type attribute can contain:

[X] a string primitive or a union array of strings _or schemas_ with

the
same delegation to "properties" and "items" like:
type: ["number",{type:"string",pattern:"[0-9]+"}]

2. The set of types (bringing this one up again):

[X] number, boolean, string, null, object, array

Though I do not really object to the others all that much.

I think it would helpful to have examples of different schema's for a
handful of constant examples as we discuss this, including some
popular formats. We know what is going in and also what we want to
pull out of the data. We are really talking around defining the syntax
of the data structure and how the definition makes things clearer/
possible. I'm a visual learner, so perhaps I'm biased in thinking this
would help clarify views...