Updated page "JSON Schema proposal - first draft"
Kris Zyp
questionable areas:
1. Should nullable be removed, since I added the type "null"? I think
so, but the only issue is whether that would make it excessively
difficult to define that a property value as being anything but null,
as you would have to use a union type:
["string","number","object","array","boolean"]. Or alternatively, the
"any" type could refer to any non-null value, and a smaller union type
could be used to indicate any value including null:
["any","null"]
2. The new property additionalProperties seems clunky. The goal is to
provide some means to define the schema type for any additional
properties. Two ways to do it, the first is with additonalProperties:
{type:{
foo:{
type:"string"}},
additionalProperties:{
type:"string"}}
Second is the original way with the "*" property:
{type:{
foo:{
type:"string"},
"*":{
type:"string"}}
}
This would able to validate something like:
{foo:"bar",otherProp:"some string"}
I think the "*" is more readable, but it does have name clash
possibility (if one wanted to validate an instance property "*").
Matt (MPCM)
expect any type and do our own handling after the schema matching.
Perhaps it is the type of systems I deal with, but rarely would I use
"anything, but not null". I think removing nullable and requiring a
union type is clearer. For that reason I would not muddy the waters by
assigning special meaning to "any".
"any" should include all types. I would rather see "!<type>" excluding
prefixes, before making "any" not mean any.
Have those who need such a broad but selectively exclusive need use
["string","number","object","array","boolean"]. It is simple and
follows logical rules without exception.
Kris Zyp
Kris
Claudio D'Angelo
The scope of nillable is that an attribute with a specific type CAN be
null.
The type null is used to indicate that the attribute MUST be null.
Matt (MPCM)
Kris Zyp
optional nulls. For example ["string","null"] is a nullable string. Claudio,
is the problem that you don't currently support union types?
Kris
----- Original Message -----
From: "Matt (MPCM)" <Wicke...@gmail.com>
To: "JSON Schema" <json-...@googlegroups.com>
Claudio D'Angelo
manage an attribute that can be a string or integer or date.
This methodology can go well for javascript but not for java or C++.
Claudio D'Angelo
manage an attribute that can be a string or integer or date.
This methodology can go well for javascript but not for java or C++.
On 6 Gen, 17:43, "Kris Zyp" <kris...@gmail.com> wrote:
Kris Zyp
can use the validator to validate instances. You just can't have exact
correspondence of type constraints in the generated classes. Java classes
can certainly approximate JSON Schemas much more accurately than JavaScript
because JS1/ES3 doesn't have types. There is certainly no requirement that
you have to an exact correspondence though, generated classes that may be
populated with JSON instance simply must have a type that is at least as
wide the JSON Schema type. With allowance for primitive wrappers Java always
has a type that is at least as wide as a JSON Schema type. In Java, an
Object type is wide enough to handle a String, Integer, or Date.
Claudio D'angelo
validator.
I can't encourage the use of Object because It's can cause
ClassCastException or useless prolongation of code.
The schema serve to my system to speak the same language with other
systems. In an example:
|"born" : {"type":["integer","string"], /allow for a numeric year, or a
full date/
"format":"date", /format when a string value is used/
"minimum":1900, /min/max for when a numberic value is used
/|| "maximum":2010,
"optional":true
},
this step indicate that I can receive a date object (with all
informations) or an integer (with year).
Introduce the union only to manage a nullable attribute involve to
manage other information (if then else statements) during the validation.
For my system json schema is became too much expensive.
I think that I must search another method to validate.
|
Kris Zyp ha scritto:
Kris Zyp
> validator.
I really don't think you should necessarily be doing format validation,
especially if you are concerned about the complexity/expense of the system.
Of course, JSON Schema is a form of documentation to establish correctness,
and documentation exists at various levels of complexity. There is minimal
level correctness that can it is dictated by types, and there is higher
level of correctness (reasonable data) that can only be discerned from
descriptions. "format" falls in between, and in addition is probably the
most likely area of JSON Schema to change/evolve. It is naive to assume that
you can have just one level of bound of correctness, and that will solve all
correctness problems. Documentation like JSON Schema can and should be
progressive in it's ability to describe acceptable data.
> I can't encourage the use of Object because It's can cause
> ClassCastException or useless prolongation of code.
How then would you describe a property that can have an integer or string? I
would assume that without union types, you would have to use "any", which
presumably you would translate to the Java type Object, and you would be
back to where you started, except the Schema would be less descriptive, have
a lower level of validation capability and provide less information for
languages that do support union types.
Kris
Claudio D'angelo
yesterday was a bad day. I've slept up and I think that it isn't a problem.
For me is OK (although I think that the property nillable is more readable).
Kris Zyp ha scritto:
Claudio D'Angelo
must be done?
Claudio D'Angelo
"myDate" : {
"type" : [
{ "type" : "string",
"format" : "date"},
{"type" : "string",
"pattern" : "[0-9][0-9][0-9][0-9]" },
"number" ]
...
Claudio D'Angelo
Claudio D'Angelo
location?
Claudio D'Angelo
Example :
{ "type" : {
"js:name" : {"type" : "string"},
"js:age" : {"type" : "number"}
}}
or
{ "type" : {
"${name}" : {"type" : "string"},
"${age}" : {"type" : "number"}
}}
Kris Zyp
can't use a property definition (like {"type":"string"}) in a place that
requires a type definition (like "string"). Therefore you would have to
write:
"myDate" : {
"type" : ["string","number"],
"pattern":"([0-9][0-9][0-9][0-9])|(...your date regex...)"
}
Kris
Kris Zyp
properties are now defined on a property definition, and an instance
properties (your properties) definitions are all defined on the object type
definitions. The exception would be if we reintroduced "*" as property in
object type properties to define all properties not explicitly defined, then
we could have a collision with "*".
My hope was this would make life drastically simpler for you, because you
would not need namespaces anymore.
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Subject: Discussion on json-schema-proposal---first-draft
>
> What about name collision?
> >
>
Kris Zyp
sometimes used a convention of having a special array property that can
point to an array that indicates that the array and parent key values should
be mixed in. I don't really want to pollute JSON Schema with that though.
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Sent: Tuesday, January 08, 2008 3:38 AM
Subject: Discussion on json-schema-proposal---first-draft
>
Kris Zyp
we are really making progress, and that we are getting close to a really
good spec. Thank you so much for your help, obviously your suggestions and
advice from implementation have been critical in moving this forward.
Thanks,
Kris
----- Original Message -----
From: "Claudio D'angelo" <claudio...@lombardia-servizi.it>
To: <json-...@googlegroups.com>
Sent: Tuesday, January 08, 2008 12:28 AM
Subject: Re: Discussione su json-schema-proposal---first-draft
>
Claudio D'angelo
and i can use type object in union?
"type" : [
{
"name" : {"type" : "string"...},
"surname" : {...},
...
},
{
"enterpriceName" : {...},
...
}
],
Kris Zyp ha scritto:
Claudio D'angelo
Kris Zyp ha scritto:
Claudio D'Angelo
that avoid attribute 's confict?
For example $schema or $json:schema.
Kris Zyp
type, minimum, maximum, etc.).
Kris
----- Original Message -----
Kris Zyp
Kris
----- Original Message -----
From: "Claudio D'angelo" <claudio...@lombardia-servizi.it>
To: <json-...@googlegroups.com>
Sent: Tuesday, January 08, 2008 7:39 AM
Subject: Re: Discussion on json-schema-proposal---first-draft
>
Claudio D'angelo
in the object declaration there are only the attribute names, isn't it?
Kris Zyp ha scritto:
Kris Zyp
validated, no JSON Schema defined properties (like type, minimum, etc.)
Claudio D'Angelo
The expression
"type" : ["null", ["string", "integer"]]
is a vaid format to indicate an array that contains both string and
integer and can be null?
Kris Zyp
"type" : ["null", [["string", "integer"]]
just a nested union type. ["null",["string","integer"]] =
an array of that type.
Note that the main reason to use the "null" type instead of the "nullable"
attribute is that it would be impossible to denote an array of values, where
each value could be a string or null. With the null type you can do it with
[["string","null"]].
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Sent: Tuesday, January 08, 2008 8:58 AM
Subject: Discussion on json-schema-proposal---first-draft
>
Kris Zyp
{"type":{"foo":{"type":"string"}},
"additionalProperties":{"type":"number"}
}
This would indicate that the target instance must be an object with a foo
property with a string value, and any other properties must have a number
value. So the following would validate:
{"foo":"bar","otherProp":1,"anotherProp":2,"yetAnotherProp":3}
And this would not validate:
{"foo":"bar","otherProp":"a string value","anotherProp":true}
I still think that using "*" would make a more readable equivalent schema:
{"type":{"foo":{"type":"string"},
"*":{"type":"number"}}
}
But it does introduce a name clash, and it is worth noting that a parallel
situation exists in the SMD (service mapping definition) with parameters,
and I would like to keep them in sync (SMD has an additionalParameters
property). Change both, or neither...
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Sent: Tuesday, January 08, 2008 1:33 AM
Subject: Discussion on json-schema-proposal---first-draft
>
Kris Zyp
>
Kris Zyp
>
Claudio D'angelo
["null",["string","integer"]] = ["null","string","integer"]
I'm not agree ... ["null","string","integer"] indicate that an array can contain a string, an integer or a null.
I want indicate that an attribute is an array of string or integer but this attribute can be null
Kris Zyp ha scritto:
Claudio D'Angelo
This is useful if I have a schema that represents an object and in
another schema I represents an array of the above object:
--schema1.json
{type : {...}}
--schema2.json
{type: [{type:{}, $schema : "uri of schema1.json"}]}
Claudio D'angelo
Don't take my response in consideration
Kris Zyp ha scritto:
Claudio D'Angelo
this schema:
"myattr" : {
type : ["integer", "float"],
minimum : 3,
maximum : 10,
maxDecimal : 2
}
Is valid? or this must be considered only float?
Claudio D'Angelo
"float"?
In this manner you have that type represents only the type of json
(object, array, number, boolean, null, string and union how special
type) and format represents the format of these type
On Jan 9, 10:09 am, "Claudio D'Angelo" <claudio.dang...@lombardia-
Kris Zyp
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Subject: Re: Discussion on json-schema-proposal---first-draft
>
Kris Zyp
redundant (no need to declare integer, since it is subset of "number").
However, if we use your other suggestion (make "integer" a format), that
would change that.
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Subject: Discussion on json-schema-proposal---first-draft
>
Kris Zyp
> This is useful if I have a schema that represents an object and in
> another schema I represents an array of the above object:
Referencing and reusing other schemas is certainly one of my primary hopes
and goals for JSON Schema, I think it is central to the ultimate optimal use
of JSON Schema. However, referencing is also not specific to JSON Schema.
Many other forms of JSON stand to benefit from referencing capabilities, and
I don't believe it would be advantageous for JSON Schema to have it's own
referencing convention in contrast to other forms of JSON. One should be
able to use one referencing mechanism and apply it to JSON Schema as well as
other JSON. Therefore, I believe that JSON Schema should lean on another
standard/specification for referencing.
I believe that a standard for JSON referencing would be immensely valuable,
and I have put forth efforts to that end
(http://www.json.com/category/referencing/), albiet without a great deal of
success.
In the spec, I suggested the use of the JSON referencing proposal that I set
forth here:
http://www.json.com/2007/10/19/json-referencing-proposal-and-library/
which was my attempt to put together the best ideas and techniques of the
various referencing techniques that have been used and suggest a compromise
of conventions. With this proposal, one could achieve reuse of schemas by
referencing, and you could create your second schema that references the
first one like:
--schema2.json
{type: [{myProp:{$ref:"schema1.json"}}]}
Although, in this case, it might be more useful to reference the object type
definition than the schema itself.
There are also a number of examples of referencing type definitions in the
common JSON Schema definitions, in the card and calendar schemas:
http://groups.google.com/group/json-schema/web/common-json-schema-definitions
Kris
Claudio D'angelo
the moment). However JSPON references element in the same stream and not
in another stream.
json schema is a json stream and using JSPON with
{type: [{myProp:{$ref:"schema1.json"}}]}
will be parsed how " link another object that has myProp = "schema1.json".
I think that is useful another methodology.
Kris Zyp ha scritto:
Claudio D'angelo
Kris Zyp ha scritto:
Claudio D'Angelo
I see that you have renamed the float in number. Why don't you remove
the integer type? This type can be resolved or setting maxDecimal=0 or
setting format=int[eger].
At heart integer derive from number.
On 11 Gen, 11:31, Claudio D'angelo <claudio.dang...@lombardia-
>
> - Mostra testo tra virgolette -
Kris Zyp
divide up types, that might be good to get more input.
Kris
----- Original Message -----
From: "Claudio D'Angelo" <claudio...@lombardia-servizi.it>
To: "JSON Schema" <json-...@googlegroups.com>
Sent: Friday, January 11, 2008 3:02 PM
Subject: Re: Discussion on json-schema-proposal---first-draft
David Waite
reference one or more names (string or array of strings) at the same
level?
This would allow you have multiple sets, and also indicate that (for
your example) both state and town have to be specified if either is
used, by having them reference one another.
Jakob Kruse
I find this choice rather questionable. The possible values of the
"type" defintion should be just that - types. "null" is not a type,
it's a value. Including "null" as a possible "type" value is just
starting down a slope where "true" and "false" come next (in JSON
specs they are treated the same), and that's just plain wrong.
Let's reserve "type" for types. "any" being the only reasonable
exception, because it just saves a lot of space and increases
readability.
I vote for reintroducing "nullable" (if that's what it was called - I
don't like "nillable" because the value is not "nil") as the way of
indicating that the property in question could be null. "any" would
then mean "any valid type", but not "null" unless "nullable" is true.
/Jakob
On Jan 6, 5:43 pm, "Kris Zyp" <kris...@gmail.com> wrote:
> Yes, any type definition can be unioned with "null" so as to support
> optional nulls. For example ["string","null"] is a nullable string. Claudio,
> is the problem that you don't currently support union types?
>
> ----- Original Message -----
> From: "Matt (MPCM)" <WickedLo...@gmail.com>
> To: "JSON Schema" <json-...@googlegroups.com>
> Subject: Re: Discussione su json-schema-proposal---first-draft
>
> > Wouldn't a union type cover this?
David Wilhelm
any other type, but it is a valid JSON value.
On this topic, I noticed that when I attempt to validate the object:
{
"foo":null
}
with the schema:
{
"foo":{
"type":"null"
}
}
I'm still getting the error:
foo
is non-nullable, but has a null value
"type":"any" , "type":["any"] , or even "type":["any","null"]
don't seem to work either. Sorry if this is not the place for
implementation discussion. If not, where?
Cheers,
Dave
Matt (MPCM)
primitive types boolean, number, and string and the special values
null and undefined. Everything else is variations on the object type."
- http://javascript.crockford.com/survey.html
"Vars are not typed. A var can contain a reference to an object, or a
string or a number or a boolean or null or undefined." -
http://javascript.crockford.com/survey.html
A var, which is a string, being set to null in Javascript identifies
it as an 'object' type. This is mostly recognized as being incorrect,
but that is the way it is. From my view this does make null somewhat
of a type in Javascript conceptually. I cannot take a var that is now
null and infer that it is was a string. Not sure how this shapes up in
ES4...
--
Matt