Understanding http://json-schema.org/schema

[Andi]

I am currently trying to understand the self-describing schema for
writing a tolerant validator. The validator will try to make values
fit to the schema - e.g. '1' to 1, or 'false' to false. The current
parsers won't forgive a wrong type, so a valid string representation
of a number will not be adapted and so adds an error. I think this is
wrong, because you need a way to bring data from a client (which is
just arrays, objects and strings) to a useful format.

I think there are some errors in http://json-schema.org/schema

Comments:

1) #.properties.type.options - I think this should be .."enum":
["string","object","array","boolean","number","integer","null","any"],
I don't find "options" documented as a property of a schema.

2) #.properties.type.unconstrained - I don't find "unconstrained"
documented as a property of a schema.

3) #.properties.items - The draft says that it can be a schema or an
array of schemas, so the definition should be:

"items":{
"type":["object","array"],
"properties":{"$ref":"#.properties"},
"items":{"$ref":"#.properties"},
"description":"When the value is an array, this indicates the
schema to use to validate each item in an array",
"optional":true,
"default":{}}

BUT on the other hand, in the schema schema I find that a schema can
be an array itself. It would be better if a schema MUST be an object
and if your instance is an array, you better use a schema with type
"array", and then you can optionally use an array for items, which
implies tuple typing. It seems that there is a misunderstanding here
(or an intermingling of an old draft with a new one).

4) Why should "type" point to another schema? I see no use in this and
it complicates things a lot to validate a given instance to several
schemas. It must be clear which schema an instance should fit to.

5) #.properties.minimumCanEqual/maximumCanEqual.default should be true

6) Probably remove #.properties.pattern.default so that the default
won't be set implicitly when the schema is defined.

7) #.properties.maxDecimal can be negative, and it makes sense, so you
can force numbers to be rounded to 10 (-1), 100 (-2) ...

7) #.properties.uniqueItems is missing

8) #.properties.contentEncoding is missing

9) #.properties.divisibleBy is missing (and should this be part of the
standard?)

10) It is not clear how "extends" is applied. Are properties in
extends overwritten (which makes the most sense) instead of doing
different validations, that are contradictionary? How do extends
behavior look like for arrays, and basic types? How deep is extends
applied? It's not documented.

11) Can I make references to global variables as JSON Schema
definitions? Example: I wrote a framework with a schema as a class
constraint definition. Now I wrote software that depends on the
framework and the software's JSONSchemas will link to the frameworks
schema definitions. In JSON, there are no variables. So how do I
reference it, probably like {"$ref":"$.framework.MyClass.schema"}
$ references the global namespace.
I don't want to use HTTP to link to a schema or read an additional
file.

[Dean Landolt]

On Thu, Jun 24, 2010 at 3:49 PM, Andi <andrea...@gmx.de> wrote:

I am currently trying to understand the self-describing schema for
writing a tolerant validator. The validator will try to make values
fit to the schema - e.g. '1' to 1, or 'false' to false. The current
parsers won't forgive a wrong type, so a valid string representation
of a number will not be adapted and so adds an error. I think this is
wrong, because you need a way to bring data from a client (which is
just arrays, objects and strings) to a useful format.

Why is data from a client just arrays, objects and strings? If you have a distinction between arrays and objects then presumably you're talking JSON as the serialization format so you have numbers too, right? What exactly are you missing?

Kris Zyp introduced the notion of a coerce property on schema in persevere to do this very thing. Defining coercion algorithms doesn't seem like the kind of thing that belongs in the ID per se but it's one of any number of things that would be very nice to specify as extensions. One of the nicest things about json-schema is how extensible it is -- it would be great to try and spec some of the more useful extensions for interoperability's sake (formatting hints is another huge win json-schema could serve as the perfect host for).

[Andi]

HTTP request example: request?a=5&b[]=1&b[]=2

This is: {
a: '5',
b: ['1', '2']
}

At first this is a string and so the validator should try to make it
to ints or numbers. To have additional properties that define the
behavior of adapting the value is a good idea for extending JSON
Schema. Examples: I have added a property "adapt" to my
implementation. It is a function (and so a JSON extension), which
defines how to adapt a value that does not fit.


On 25 Jun., 05:39, Dean Landolt <d...@deanlandolt.com> wrote:

> On Thu, Jun 24, 2010 at 3:49 PM, Andi <andreaskal...@gmx.de> wrote:
> > I am currently trying to understand the self-describing schema for
> > writing a tolerant validator. The validator will try to make values
> > fit to the schema - e.g. '1' to 1, or 'false' to false. The current
> > parsers won't forgive a wrong type, so a valid string representation
> > of a number will not be adapted and so adds an error. I think this is
> > wrong, because you need a way to bring data from a client (which is
> > just arrays, objects and strings) to a useful format.
>
> Why is data from a client just arrays, objects and strings? If you have a
> distinction between arrays and objects then presumably you're talking JSON
> as the serialization format so you have numbers too, right? What exactly are
> you missing?
>

> Kris Zyp introduced the notion of a *coerce* property on schema in persevere

> to do this very thing. Defining coercion algorithms doesn't seem like the
> kind of thing that belongs in the ID per se but it's one of any number of
> things that would be very nice to specify as extensions. One of the nicest
> things about json-schema is how extensible it is -- it would be great to try
> and spec some of the more useful extensions for interoperability's sake

> (formatting hints is another *huge win* json-schema could serve as the
> perfect host for).