json schema reference and default/required attributes validation

[Armishev, Sergey]

1.XML schema standard has definition for schemaLocation tag  that allows to reference xml schema from xml instance. How can I do the same in json file and reference the json schema?

2.I think that if schema has default and required attribute together then it should be no need for json file to define such attribute. Validator should check that default is defined so that implementation suppose to take this value from schema

 

Here is simple example

 

JSON schema:

{

    "title": "default integers",

    "type": "object",

     "required":true,  

    "properties": {

      "myinteger":{

              "description": "integer with default value",

              "type": "integer",

             "required":true,

              "default":5

      }      

    },       

      "additionalProperties" : false

}

 

Json that I would like to use but JSON schema not allowed me to do it

{

}

 

JSON schema that I don’t like to use but JSON schema consider it as valid

{

      "myinteger":5

}

 

Imagine that I have hundreds of json files and all of them based on the same json schema file and according to current spec I need to copy/paste the same default values to all of them? And if I want to change my default value to 4 I need to edit all of my files again?

 

-Sergey

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

[Francis Galiegue]

On Mon, Mar 12, 2012 at 16:39, Armishev, Sergey <sarm...@idirect.net> wrote:
> 1.XML schema standard has definition for schemaLocation tag  that allows to
> reference xml schema from xml instance. How can I do the same in json file
> and reference the json schema?
>

This is currently not defined.

> 2.I think that if schema has default and required attribute together then it
> should be no need for json file to define such attribute. Validator should
> check that default is defined so that implementation suppose to take this
> value from schema
>

[...]

While I understand the need, I disagree: this is not the role of validation.

And consider this:

{
"properties": {
"p": {

"type": "integer",
"required": true,

"default": null
}
}
}

This is a _valid_ JSON schema (see the metaschema: "default" is
defined as {}, ie an empty schema, ie every value is valid). But the
"default" value doesn't obey the schema! So, if we follow your
reasoning, you will end with JSON documents which are valid against
the schema -- yet they aren't.

And this is exactly why to my eyes, the "default" keyword belongs to
JSON Patch, not JSON Schema. Draft v3 says nothing about this, but
this is my opinion ;)

--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

[David R]

As far as I understand it:

1)  There is no universal way for referencing schema, as that would be an extension/change to the JSON format, which we don't want to do.  If we're looking at some JSON and we don't know what the schema is, then there isn't a standard method for inferring schema.  However, schemas can define links based on instance data, so for instance the schema http://json-schema.org/json-ref has the following link defined:

{

"href" : "{$schema}",

"rel" : "describedby"

},

where "describedby" is a value that means the link is to a describing schema.  So if you believe that a JSON document is following the json-ref schema, then you can check for a "$schema" property and use that to find a more specific schema being implemented.

If you've just fetched the JSON data over HTTP, then you might find there's a schema specified in the Content-Type, using the "profile" parameter.

2) In your example, what's the difference between "required and has a default" and simply "has a default"?

In your situation with hundreds of JSON files, why not make the property optional, but still supply a default in the schema?  That way, you can get exactly the behaviour it sounds like you're looking for, where if the property is present its value is used, but if it's missing then an intelligent client should use the value from "default".  I don't see why you need the field to be "required".

[David R]

On Monday, 12 March 2012 16:01:10 UTC, fge wrote:

While I understand the need, I disagree: this is not the role of validation.

A side-question - is the role of JSON Schema purely validation?  Because (apart from links with the "describedby" relevance) most of the definitions in the hyper-schema aren't to do with validation, they are to do with display, parsing, and user-interaction.  Things like the "schema" property of the Link Description Object hold very little relevance to validation, and are much more useful for defining an API.

So I think "supplying a default value in a way that can be changed later" isn't out of character for a JSON Schema, as it feels to me like part of describing an API.  However, as stated above, I believe the functionality being searched for is already accounted-for by supplying a default and leaving the property optional.

[Francis Galiegue]

On Mon, Mar 12, 2012 at 17:09, David R <gerai...@gmail.com> wrote:
> As far as I understand it:
>
> 1)  There is no universal way for referencing schema, as that would be an
> extension/change to the JSON format, which we don't want to do.  If we're
> looking at some JSON and we don't know what the schema is, then there isn't
> a standard method for inferring schema.  However, schemas can define links
> based on instance data, so for instance the schema
> http://json-schema.org/json-ref has the following link defined:
>
> {
> "href" : "{$schema}",
> "rel" : "describedby"
> },
>
> where "describedby" is a value that means the link is to a describing
> schema.  So if you believe that a JSON document is following the json-ref
> schema, then you can check for a "$schema" property and use that to find a
> more specific schema being implemented.
>

The problem with that (and a post on this list long ago highlighted
this) is that $schema is a perfectly valid value in a JSON instance. I
have been hit by this recently on the list by misinterpreting the JSON
document of a post...

I have not read the spec for some time, but remind that there was a
way to refer to a schema for a JSON instance in an HTTP header...
Which of course won't resolve the problem if you happen to use any
other protocol. HTTP is not TCP!

[Armishev, Sergey]

I agree with Francis that reference should not depend on protocol. And that is json schema claim! From usability perspective if the claim is valid that json schema can be used instead of xml schema then reference must be defined. In the case of xml schema usage when 2 different companies (ecommerce) exchange their documents they need to be sure that their documents are correct according to the same schema. I think it is very important. I am putting currently my own private tag into my json files but don't think it is correct approach.
-Sergey

--
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.

[Armishev, Sergey]

default value itself must pass the validation. That is not happening now. If I put null into my example and define integer in my json file JSV passes validation.
Wrong JSON schema that passes JSV validation

{
"title": "default integers",
"type": "object",
"required":true,
"properties": {
"myinteger":{
"description": "integer with default value",

"type": "integer",
"required":true,
"default":null
}

},
"additionalProperties" : false
}

JSON
{
"myinteger":5
}

-Sergey

-----Original Message-----
From: json-...@googlegroups.com [mailto:json-...@googlegroups.com] On Behalf Of Francis Galiegue
Sent: Monday, March 12, 2012 12:01 PM
To: json-...@googlegroups.com

And consider this:

--

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.

[Francis Galiegue]

On Mon, Mar 12, 2012 at 18:09, Armishev, Sergey <sarm...@idirect.net> wrote:
> default value itself must pass the validation. That is not happening now. If I put null into my example and define integer in my json file JSV passes validation.
> Wrong JSON schema that passes JSV validation
> {
>    "title": "default integers",
>    "type": "object",
>     "required":true,
>    "properties": {
>        "myinteger":{
>                  "description": "integer with default value",
>                  "type": "integer",
>             "required":true,
>                  "default":null
>        }
>    },
>        "additionalProperties" : false
> }
>

See what I said: JSV is _right_ about that. The spec _does not_ say in
any way that "default" must obey the schema it is attached to at all.

Now, maybe you see why I want "default" out of JSON Schema and into JSON Patch.

[Armishev, Sergey]

Francis,
Unfortunately I can't agree with you. Again , current JSON schema definition has this entry made by some wise guy (my opinion)
5.20. default

This attribute defines the default value of the instance when the
instance is undefined.

According to the meaning of that sentence (English is not my mother language but I hope I got this phrase correctly): the default value should be defined in such a way that it could be used as such (means must pass validation) in the instance
From this perspectives, JSV IS NOT RIGHT.
Again, my arguments here not for the "purity" of definition but usefulness of JSON schema in applications. And currently I see 2 major types of applications that can benefit from JSON schema: validation of json files produced by different applications (i.e. ecommerce) and automatic code generations(protocols, GUI, wizards). I think in both cases default values should play big role as well as json structure. This is why I consider default as a primary tag not patch. JSV implementation currently has empty hook for the default tag. I just used it for validation and automatic merging of json file and json schema. Thanks to Gary for the perfect code! This way I can create my real json file on the fly (but only if I have reference to the JSON schema to such json file. This is why I consider so important to define in standard way how we are going to reference JSON schema in the json file). Now consider that I have styling options for my markup as a default values in the JSON schema? It is much more powerful then CSS itself! And that is only one example

-Sergey

-----Original Message-----
From: json-...@googlegroups.com [mailto:json-...@googlegroups.com] On Behalf Of Francis Galiegue
Sent: Monday, March 12, 2012 4:15 PM
To: json-...@googlegroups.com
Subject: Re: [json-schema] json schema reference and default/required attributes validation

--

[Francis Galiegue]

On Mon, Mar 12, 2012 at 22:38, Armishev, Sergey <sarm...@idirect.net> wrote:
> Francis,
> Unfortunately I can't agree with you. Again , current JSON schema definition has this entry made by some wise guy (my opinion)
> 5.20.  default
>
>   This attribute defines the default value of the instance when the
>   instance is undefined.
>

... And it does not say anything about whether the default value of
the instance should conform to the schema, does it? Nor does it
specify that it should substitute for the value for a missing property
which is tagged as "required".

Word for word, JSV is right about what it does.

Consider the parallel with XML: XSD only concerns itself with
validation (and so do RelaxNG and DTD). Altering XML input is the role
of XSLT. There are parallels here:

* validation: XSD/JSON Schema;
* alteration: XSLT/JSON Patch;
* addressing: XPath/JSON Pointer.

Which is why I maintain that "default" does not have its place in JSON
Schema as such: it serves no purpose for validation. It does serve a
purpose for alteration.

[Armishev, Sergey]

Word for word!
" This attribute defines the default value ... ". My understanding of English word "define" is that I can take it and put it in place of missing property. Means it should be subject of the same validation, otherwise you can't claim that you can use it to define instance value. I think it is pretty clear
And regarding XSD and JSON schema. I assume we go forward in our software. And JSON schema suppose to provide more powerful capabilities then XSD and not just repeat it
And again, I am more concern what applications I can make and how easy. From this perspective, separation of default value into separate standard seems pretty heavy option. And I probably choose to use JSON schema standard in my application in the way as I understand it then wait for some future standard that seems not so useful.

And remember Occam's razor! :)

-Sergey

-----Original Message-----
From: json-...@googlegroups.com [mailto:json-...@googlegroups.com] On Behalf Of Francis Galiegue
Sent: Monday, March 12, 2012 6:13 PM
To: json-...@googlegroups.com
Subject: Re: [json-schema] json schema reference and default/required attributes validation

--

[Francis Galiegue]

On Tue, Mar 13, 2012 at 02:43, Armishev, Sergey <sarm...@idirect.net> wrote:
> Word for word!
> " This attribute defines the default value ... ". My understanding of English word "define" is that I can take it and put it in place of missing property.

Yes, the spec specifies this...

> Means it should be subject of the same validation, otherwise you can't claim that you can use it to define instance value.

But not that. Reading the spec and the metaschema, it is clear that
"default" can take any value and that no relationship is defined
between it and other schema fields.

Which means this is left to interpretation. You choose to interpret it
one way, I choose to follow the spec by the letter. And as it is
unspecified, in the end, we are both right...

> And regarding XSD and JSON schema. I assume we go forward in our software.

So do I, and I also choose to clearly separate the roles.

> And JSON schema suppose to provide more powerful capabilities then XSD and not just repeat it

JSON and XML are different, I was just highlighting what is to me a
distinction which should be done wrt processing. Mixing validation and
alteration is not a good thing to my eyes.

I have just reread the JSON path spec and it is very outdated... Mr
Bryan, any chance a new one is in the works? In particular, it should
use JSON Pointer.

> And again, I am more concern what applications I can make and how easy.

So do I, and I find it easier to separate processes :)

> From this perspective, separation of default value into separate standard seems pretty heavy option. And I probably choose to use JSON schema standard in my application in the way as I understand it then wait for some future standard that seems not so useful.

JSON Patch isn't very useful as such, granted. I have a lot of ideas
for it though.

>
> And remember Occam's razor! :)
>

Hey, who is interpreting here? ;)