@json-schema-org/owners

Plan proposals

Apologies for not having gotten to writing this proposal out sooner. I think we can all agree, time on this project is stretched thin!

First before discussing the new website, I think some pre-work is needed regarding the structure of the json-schema working group, and formalising yourselves as chairs of the project (if you are willing). I am happy to take on some responsibility for public communications and organisational elements for the project.

My suggested plan is as follows

1. Review the list of libraries which implement json-schema and the json-schema test suite, and ask each of them if they would like to become involved in json-schema, including an explanation of the current state of affiars (of course after your approval on the wording). I would also like to ask them what teams they could see within the project, and any high level elements they would like to be involved in.
2. Further, scan through the curren open issues, looking for any potentially interested individuals who also might like to be involved in the project, asking similar questions.
3. Once this is completed, there should be a list of individuals who are keen to contribute to the re-establishing of the projects workforce. We could then create a private google group to enable internal communications. I would also encouridge everyone to join the irc channel on freenode.
4. With an established working group, who can then evaluate and re-establish the requirements for draft 5. If I understand / have read correctly, the plan was for draft 5 to be a tidy up release, before the first version of the specification is put out as an RFC. (Speaking of which, did the project get any responses from the RFC? If so, how do we get hold of them?)

This will allow the project to evaluate the state of draft 5, and how to move forward to make it ready for publishing as an RFC. (I'd like to be part of the review process for this!)

I noticed that getting draft 5 sorted has been raised as issues here json-schema/json-schema#167 and here json-schema/json-schema#130 . cc'ed so people can follow discussions.

Regarding the website

Part of contacting a number of people, I would seek comments on the current website, looking to evaluate if it meets the current users expectation and needs. I'd do this in the form of a google questionaire.

If a re-structure of the site is needed, consider a few alternatives.

Start re-build using bootstrap. Bootstrap would allow for a faster build, while also making it easier for others to contribute. After some basic layouts are constructed, create a number of github issues and associated milestones for the website rebuild.

I'd like to also spend some time on / directing people involved, to the Understanding JSON Schema web book from the Space Telescope Institute. Maybe something on how to get involved in the specification.

This regards examples.html and perhaps other examples.

I am just starting to learn about JSON Schema and read the first example:

{
	"title": "Example Schema",
	"type": "object",
	"properties": {
		"firstName": {
			"type": "string"
		},
		"lastName": {
			"type": "string"
		},
		"age": {
			"description": "Age in years",
			"type": "integer",
			"minimum": 0
		}
	},
	"required": ["firstName", "lastName"]
}

The title attribute is defined in http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.1 as:

[This keyword] can be used to decorate a user interface with information about the data produced by this user interface.

In light of this, the example's title seems incorrect because it is describing the schema itself rather than the JSON instance that is being validated.

Recommended change:

"title": "Person",

As per json-schema-org/json-schema-spec#10 :

The json-schema.org homepage (and http://json-schema-org.github.io/ ) points to json-schema/json-schema, where it should point to json-schema-org/json-schema-spec.

This material originally written by @fge and further updated by @sam-at-github at https://github.com/json-schema/json-schema/wiki/$ref-traps

Foreword

If you implement JSON Reference support in your JSON Schema implementation, all points below should be considered carefully.

Some of these points are already mentioned by the JSON Reference draft, so if you have read the draft already, this may not be news to you.

Unable to dereference a URI

This can of course happen. For the most obvious protocol out there, http, you may encounter a 404, for instance. Or the URI scheme may not be supported.

It should be noted that the draft does not dictate a specific implementation behavior in this kind of situation. Some implementations may choose to fail, others may not.

JSON References can be chained

It can happen that you have this reference to resolve:

{
    "$ref": "http://one.site/oneschema.json#"
}

and when you resolve that reference, you have yet another JSON reference:

{
    "$ref": "otherschema.json#"
}

In this case, you MUST also resolve that reference, and so on, until you fetch content which is not a JSON Reference.

JSON References can loop

Consider this example:

{
    "a": { "$ref": "#/b" },
    "b": { "$ref": "#/a" }
}

Clearly, an infinite loop may arise. Implementations must detect loops in a chain of references being resolved and raise an exception.

References through other references

Consider this example:

{
    "a": { "milk": "cow", "eggs": "bird" },
    "b": { "$ref": "#/a" },
    "c": { "$ref": "#/b/milk" }
}

(todo: is this situation resolvable in all cases?? Someone provide an algorithm.)

A JSON Reference can resolve to anything

A JSON reference is only a URI, and if you happen to be able to dereference that URI, the content type is undefined.

Which means, you may get a valid JSON document which is not a schema. For instance:

3

Or you may get something which is not even JSON:

Hello!

Indicated in numerous issues is the fact that the controlling owner of the json-schema.org domain is unreachable though other people involved with the project have continued payment for the domain. As suggested in #48 (comment) this is an issue to track contacting the registrar with respect to trying to gain control of the registration.

Since contact with the original owner is not expected at this point, the options would be to let the domain expire and hope to be able to buy it when it becomes available (risky) or to work with easyDNS support to try to reach a solution.

Regarding contacting easyDNS, see: https://fusion.easydns.com/Knowledgebase/Article/View/264/0/accountdomain-access-issues

Someone else created the account for us!
[...]
If you are the owner of a domain (as displayed in the WHOIS information for the domain) but the domain is in an easyDNS account which is not in your name or under your control, we have a procedure in place for this as well.
[...]
If you are unable to contact the person or company in question, set up an account as mentioned above, and contact our support team by phone or email. We'll check proof of ownership through a series of procedures, then move the domain into your account. The process isn't immediate, as you might understand, and we appreciate your understanding in the matter.

@kriszyp Appears to be indicated on the WHOIS record, so they would likely have the easiest time with this.

@stefk noted in json-schema/json-schema#198 that the web site still shows the Draft 04 specifications and meta-schemas. @awwright I imagine you're already on this but filing as @stefk wanted to still track this after closing the issue at the old repo.

Originally filed by @JulienPalard as json-schema/json-schema#197

shared.html has several 404 links

With draft4 schemas we validate dates using ruby's DateTime.rfc3339 method. Defining the type as ["string", "null"] and the format as "date-time" fails when response contains null.

JSON::Schema::ValidationError: The property '#/data/items/0/dateValue' Invalid date
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attribute.rb:18:in validation_error' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/formats/custom.rb:16:in rescue in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/formats/custom.rb:12:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/format.rb:10:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:32:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/ref.rb:12:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/items.rb:14:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/items.rb:13:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/items.rb:13:in each_with_index' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/items.rb:13:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:32:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/ref.rb:12:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:32:in block in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in each'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/attributes/properties.rb:14:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:25:in block in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in each' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema/validator.rb:23:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/schema.rb:33:in validate' C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/validator.rb:113:in validate'
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/json-schema-2.8.0/lib/json-schema/validator.rb:254:in `validate!'

This is a copy of json-schema/json-schema#250 (because the repo si marked as archived)

Today (21 November 2016) I discovered that I cannot open website "json-schema.org" due to missing DNS records. I remember on Friday 18th it was still there, I am not sure about the weekend, though.

Is this a deliberate, planned transition, or just someone forgot to pay for the domain registration?

The problem is that some validation tools (e.g. jayschema) that can chain schemas during validation, rely on referred schemas being reachable on the URL specified in id attribute. Obviously, http://json-schema.org/schema, being the ultimate root of all other schemas, will break such validation if not present.

Is there anything I can do to fix this?
— @radio-miskovice

Thanks for your site - very helpful!

It would be easier to manage tabs, bookmarks, etc if the HTML titles of pages were unique. But now, e.g., these two pages just have the title "JSON Schema".

• http://json-schema.org/
• http://json-schema.org/example2.html

Related PR #57

Closed #51 because the issue was about clarification, not about having a draft-5 meta-schema.

Also related: #59

Hi! There is no editors section anymore on the page implementations.html. Is this by intention or just by an oversight?

The following commit removed the editors section: "Remove old website generation mechanism", Sept 19, 2016, 4a5a039

The section included tools like Visual Studio, ReSharper and JSONBuddy.
(Yes, I'm the author of JSONBuddy)

I know, I've raised it a couple of times, but it still didn't happen for some reason.

I think it would increase the confidence of new users (yes, there are plenty of people who are only discovering JSON-Schema) if they could see more than 2 owners of the organisation.

@Relequestual @kriszyp Who else? The old one has 6 people, there probably should be more now.

http://json-schema.org/examples.html

404 on

• Geographic Coordinate - http://json-schema.org/geo.json
• Card - http://json-schema.org/card.json
• Calendar - http://json-schema.org/cal.json
• Address - http://json-schema.org/addr.json

Example most of the links at the top level are broken

[sam@localhost json-schema-org.github.io]$find -maxdepth 1 -type l  -exec "ls" "-al" "{}" ";"
lrwxrwxrwx 1 sam sam 33 Dec  4 21:32 ./draft-zyp-json-schema-00.xml -> _includes/draft-00/jsonschema.xml
lrwxrwxrwx 1 sam sam 33 Dec  4 21:32 ./draft-zyp-json-schema-03.xml -> _includes/draft-03/jsonschema.xml
lrwxrwxrwx 1 sam sam 20 Dec  4 21:32 ./address -> example/address.json
lrwxrwxrwx 1 sam sam 16 Dec  4 21:32 ./geo -> example/geo.json
lrwxrwxrwx 1 sam sam 33 Dec  4 21:32 ./draft-zyp-json-schema-01.xml -> _includes/draft-01/jsonschema.xml
lrwxrwxrwx 1 sam sam 14 Dec  4 21:32 ./links -> draft-07/links
lrwxrwxrwx 1 sam sam 38 Dec  4 21:32 ./draft-zyp-json-schema-04.xml -> _includes/draft-04/jsonschema-core.xml
lrwxrwxrwx 1 sam sam 15 Dec  4 21:32 ./schema -> draft-07/schema
lrwxrwxrwx 1 sam sam 33 Dec  4 21:32 ./draft-zyp-json-schema-02.xml -> _includes/draft-02/jsonschema.xml
lrwxrwxrwx 1 sam sam 21 Dec  4 21:32 ./hyper-schema -> draft-07/hyper-schema
lrwxrwxrwx 1 sam sam 17 Dec  4 21:32 ./card -> example/card.json
lrwxrwxrwx 1 sam sam 21 Dec  4 21:32 ./calendar -> example/calendar.json

Currently it's implied the links are to Draft 4, but they're not.

Why do the docs suggest to use http://json-schema.org/draft-04/schema# instead of http://json-schema.org/draft-04/schema? Is this so that it's obvious how to use references to parts of that schema?

This issue is inspired by @davidjamesstone's questions in json-schema-org/json-schema-spec#201 about using JSON Schema to validate HTTP API headers.

We should add some content to the web site on best practices for APIs, and what JSON Hyper-Schema does and doesn't do. Summarizing comments in that issue from @awwright and myself, some ideas include:

• The different roles of JSON Hyper-Schema (a media type) vs Service Definition formats such as OpenAPI.
• Why many things in service definitions are not necessarily required for REST when JSON Hyper-Schema is used correctly
  • Why you don't need to specify GET/PUT/PATCH/DELETE or POST-to-create explicitly
  • How to use link relations to convey usage (the "collection" and "item" relations come to mind as an easy example)
  • Assuming json-schema-org/json-schema-spec#179 goes into draft 6, how to use schema to indicate a non-standard POST
  • How to use encType to indicate PATCH by specifying a patch media type
• What is intentionally left out of hyper-schema? (assuming these continue to be outside of it), and how to think about these things in relation to hyper-schema?
  • auth
  • headers

I can take a first pass at this. I need to sort it all out in my head as I'm writing my generic hyperclient anyway.

The specification is, properly, a specification for implementation authors to refer to. This makes it rather verbose and technical, and hard to learn from.

So for a better general reference, the website should include a reference written for schema authors (instead of implementors), detailing various recipes, examples, gotchas, and links to the appropriate section from the normative specification.

This perhaps could be done in plain HTML or Markdown files in a "dev" branch. These changes are then pulled into the "master" branch and compiled as part of the merge commit. The process might go something like:

# Update branch
git checkout dev
git pull json-schema-org dev
# Merge in new material
git fetch remote
git merge remote/dev
git push json-schema-org dev
# Build and update 'master'
git checkout master
git merge --no-ff --no-commit --strategy=theirs dev
make
git commit
git push json-schema-org master

This way build products are kept isolated from the "dev" branch.

I noticed the json in the example pages was not highlight but the snippet on the homepage was so I was about to make a PR to add highlighting to the exemple too but the highlighting is done manually!

what do you think about using someing like prismjs to highlight code example ?

The tables used in
http://json-schema.org/draft-06/json-schema-migration-faq.html
http://json-schema.org/draft-06/json-hyper-schema-migration-faq.html

are intended to look good with light borders (as they were rendered on the wiki)

Since the rest of the site ignores decades of best practices and uses tables for layout, borders are turned off.

I can't figure out how to get the CSS fixed because of all of the different technologies now involved, but those tables are nearly unreadable now and that needs fixing, preferably before we add more for draft-07.

http://json-schema.org/interfaces does not appear to be linked from the specs or the website. Is there any additional information on this resource? If it is abandoned, can it be deleted?

In the OpenAPI/Swagger 2.0 spec, we had pointed to specific sections of the draft 4 documentation for further information. Our mistake was that we pointed directly to the latest documentation, but I do not think that there was an option to point it to draft-4 at the time.

With the push of the latest draft (congrats!) and the replacement of the doc, our current links are all broken. We cannot simply point to the latest version because the spec does not support it.

I'm hoping you'd be willing to consider re-hosting the previous version (draft 4) at least by allowing us to link to the right sections. I do not expect that you provide direct navigation links to it, however you may want to consider a 'previous versions' section.

As a follow-up suggestion, would also suggest providing an alias link with the current draft name and not just the 'latest' to avoid future breakage as well.

Add it to the editor list in http://json-schema.org/implementations.html?

We've got #json-schema on Freenode now. We should link to this on the website.

I noticed while preparing #123 that there are numerous similarly named libraries listed on the Software page. For example Java has two implementations called "json-schema-validator"

I propose that when repositories have the same name, the user/org should be included to qualify which implementation is being referenced. For example Java would become:

• Java
  • java-json-tools/json-schema-validator
  • everit-org/json-schema
  • networknt/json-schema-validator

Why are we hosting the geo, address, calendar, and card schemas? In the previous iteration of the site they were not linked, as far as I can tell. I kind of remember that they weren't linked on this one until recently. They have several oddities, like a lack of $id (except one which has id despite declaring a draft-06 $schema).

I don't think that we should really be a registry of "standard" schemas, particularly a we barely have bandwidth to maintain the web site and have not been able to update the examples as it is. We certainly don't have time to maintain an extensible registry, and this small selection is pretty random.

How do people feel about removing these? Apologies if this came up before, I wasn't paying as much attention and there was a lot of noise in some of those issues so I'm not going through and reading them all again.

@Relequestual @awwright @adamvoss @Semigradsky @epoberezkin @Julian

Discussed in #31 but really a separate issue, the schemas of the drafts not having an extension means they always download when a user clicks the link, sites like Schema Store which is linked to from Microsoft's VS Code link directly to the available schema which creates a less than ideal user experience. It is very frustrating when you want to view the schema to have to save it first and open it when it could have been viewed in the browser.

Given the files are in json format, I feel they should be duplicated with the json extension if they can't be renamed for whatever reason.

It still points to draft-06 here: http://json-schema.org/documentation.html

Also I thought we've agreed not to use version-less URLs: http://json-schema.org/schema ?

Looks like some links ruined
http://json-schema.org/examples.html

Would be awesome if someone could include some of the new draft-7 features into the examples. E.g. I'm highly interested in the actual use of if / then / else but can't find any examples.

It still points to the old repo: https://github.com/json-schema-org/json-schema-org.github.io/blob/master/implementations.html#L14

Whenever we get to topic guides, here, @jdesrosiers wrote an excellent answer to the question of inheritance, ending with the great quote

Schemas are not describing objects, they are a collection of constraints. So, thinking in terms of inheritance doesn't work.

This would be a good basis for an explanatory article, I think.

The following was originally written by @fge at
https://github.com/json-schema/json-schema/wiki/Determining-what-schemas-an-object-member-value-should-validate-against
https://github.com/json-schema/json-schema/wiki/Determining-what-schema-an-array-element-should-validate-against

It goes into greater detail on child schema validation than fits into the specification proper:

Object properties

Implied keywords

For one object member, the set of schemas which the associated value must be valid against depends on the member itself and the following keywords:

• properties,
• patternProperties,
• additionalProperties.

NOTE: the default value for these keywords is an empty object (which MUST be considered as an empty schema for additionalProperties).

NOTE 2: in the text below, the following terminology will be used:

• the member is the object instance member's name;
• the value is the value associated with that member.

Algorithm

We start with an empty set of schemas, which we will call s.

Schemas from properties

If one member of the properties keyword value has the same value than the target member, the corresponding value of properties is added to s.

Schemas from patternProperties

For the recall: members of patternProperties are ECMA 262 regular expressions (see pattern). For convenience, these members will be referred to as regexes from now on.

For each regex, if it matches the target member successfully, then the value associated to that regex is also added to s.

This means that several schemas may be added to the set at this step!

additionalProperties

At this stage, the value of additionalProperties is added to the set if and only s was previously empty.

Example

(note: the set s above will be materialized as a JSON array in this section)

Consider this schema:

{
    "type": "object",
    "properties": {
        "p1": { "type": "string" }
    },
    "patternProperties": {
        "p": { "minLength": 10 },
        "1": { "format": "host-name" }
    },
    "additionalProperties": {
        "disallow": "boolean"
    }
}

And this object instance:

{
    "p1": "json-schema.org",
    "p2": "slippery slope",
    "x": null
}

For member p1

• properties in the schema has a member by the same name. The associated schema is therefore added to the set which is now:

[ { "type": "string" } ]

• both regexes in patternProperties successfully match p1, so schemas associated with both of these regexes are added to the set, which is now:

[ { "type": "string" }, { "minLength": 10 }, { "format": "host-name" } ]

• the set is not empty at this point, therefore we don't need to add the schema associated with additionalProperties. The final set of schemas which the value must validate against is therefore:

[ { "type": "string" }, { "minLength": 10 }, { "format": "host-name" } ]

For member p2

• there is no member by the same name in properties. At this step, the set is therefore empty:

[]

• regex p matches p2 successfully, not regex 1. The schema associated with regex p is therefore added to the set:

[ { "minLength": 10 } ]

• as in the previous example, as the set is not empty at this point, additionalProperties needs not be considered; the final set of schemas which the value must validate against is therefore:

[ { "minLength": 10 } ]

For member x

• there is no member by the same name in properties. At this step, the set is therefore empty:

[]

• none of the regexes in patternProperties match x successfully. The set is still empty:

[]

• the set being empty at this point, this time, the schema associated with additionalProperties must be added; the final set of schemas which the value must validate against is therefore:

[ { "disallow": "boolean" } ]

Array Elements

Implied keywords

For one array element, the schema which this element must validate against depends on its index in the array and the following keywords:

• items,
• additionalItems.

NOTE: array indices start at 0.

If items is absent

If items is absent, its default value is the empty schema. Which means all elements are valid. The end ;)

If items is an object

In this case, all elements of the array instance MUST be valid against the items keyword value, which is a JSON Schema.

Otherwise: items is an array

If this is an array, then the schema is determined by the index of the array element to validate. There are two possibilities:

The element index is less than, or equal to, the highest index in the items array

In this case, the element MUST be valid against the schema found at the given index in the items array.

The element index is greater than the highest index in the items array

In this case, it depends on the value of additionalItems:

If additionalItems is boolean true, or absent

This is equivalent to additionalItems being an empty schema, which means the element always validates successfully.

If additionalItems is an object

If it is an object, then by the rules, it is a valid JSON Schema. In this case, the element MUST validate successfully against that schema.

On http://json-schema.org/implementations.html#validator-javascript the link to the Persevere implementation is being rendered as:

• [json-schema</a> (AFL or BSD) as part of Persevere](http://github.com/kriszyp/json-schema)

Section 5.26 of the validation spec has an example using "type": "integer" which should presumably be "type": "number".

I suspect some sort of change in ajv/ajv-cli that now automatically recognizes draft-06 where before we needed to pass it explicitly.

@epoberezkin did this change at all recently?

I'd really like to highlight/promote implementations that have updated to support new drafts. How would folks feel abound changing the software page to group first by the most recent draft supported, then by the type of implementation, then by the language?

The great work @adamvoss has done splitting the data out into structured YAML should make this a lot easier.

@Relequestual any thoughts on this? I think it would be good for people to see the availability of support without poring through the list for the draft support notes, and it might encourage implementations to update in order to get a more prominent spot on the page.

I don't think this necessarily should be the main docs link (though we're also discussing how to improve that here, but I think it would be good to have a page somewhere on the site that lists the links to every single specification (including Core, Validation, etc) and links to the changelog(s) within those documents.

I think json-schema.org should be served other SSL. json-schema.org does not really serve sensitive information (maybe http://json-schema.org/draft-04/schema ). anyway having only http:// will make it harder and harder to link to and embed content from json-schema.org (eg: a browser based json-schema validator trying to download http://json-schema.org/draft-04/schema).

unfortunately, github does not yet support serving pages over SSL. but apparently cloudflare could be used for this instead : https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/ (given someone has access to the DNS configuration of json-schema.org)

It seems like this one should be the right one. But the website seems to be in sync with gh-pages branch of https://github.com/json-schema/json-schema...

So where do I update it?

Note: Originally filed as json-schema-org/json-schema-spec#214, but really more of a usage to document and explain rather than an issue for the spec.

Now that we have "propertyNames", it is easier to cause validation to fail on unexpected properties without using "additionalProperties": false. The general idea is that names in "properties" become an "enum" in "propertyNames", while each pattern in "patternProperties" becomes a "pattern" in "propertyNames".

It seems like this would be worth writing up as a possible solution on the web site. The following description is not the most concise and confused at least one person on the old issue, so it's worth discussing some here to find a good way to present this.

While the names and patterns involved still must be listed twice, it is possible to do this for each schema that needs to be re-used. Then, unlike with "additionalProperties", you can combine them however you want. This makes the process relatively easy to manage with well-structured "definitions" (and perhaps we can come up with a way to make it simpler?)

{
    "definitions": {
        "fooSchema": {
            "properties": {
                "foo1": {"type": "number"},
                "foo2": {"type": "boolean"}
            },
            "patternProperties": {
                "foo[A-Z][a-z0-9]*": {"type": "string"}
            }
        },
        "fooProperties": {
            "propertyNames": {
                "$comment": "Need to anyOf these or else the enum and pattern conflict",
                "anyOf": [
                    {"enum": ["foo1", "foo2"]},
                    {"pattern": "foo[A-Z][a-z0-9]*"}
                ]
            }
        },
        "barSchema": {
            "properties": {
                "bar1": {"type": "null"},
                "bar2": {"type": "integer"}
            }
        },
        "barProperties": {
            "propertyNames": {"enum": ["bar1", "bar2"]}
        }
    },
    "$comment": "Even with allOf schemas, need anyOf propertyNames or else they conflict",
    "allOf": [
        {"$ref": "#/definitions/fooSchema"},
        {"$ref": "#/definitions/barSchema"}
    ],  
    "anyOf": [
        {"$ref": "#/definitions/fooProperties"},
        {"$ref": "#/definitions/barProperties"}
    ]
}

This is much better than:

{
    "definitions": {
        "fooSchema": {
            "properties": {
                "foo1": {"type": "number"},
                "foo2": {"type": "boolean"}
            },
            "patternProperties": {
                "foo[A-Z][a-z0-9]*": {"type": "string"}
            }
        },
        "barSchema": {
            "properties": {
                "bar1": {"type": "null"},
                "bar2": {"type": "integer"}
            }
        }
    },
    "allOf": [
        {"$ref": "#/definitions/fooSchema"},
        {"$ref": "#/definitions/barSchema"},
        {
            "properties": {
                "foo1": true,
                "foo2": true,
                "bar1": true,
                "bar2": true
            },
            "patternProperties": {
                "foo[A-Z][a-z0-9]*": true
            },
            "additionalProperties": false
        }
    ]
}

In this version, you have to construct the correct "additionalProperties": false schema for every combination individually. With the "anyOf" + "propertyNames" approach, you can package up the property name rules and re-use them as easily as you do the corresponding schemas.

While this is not the simplest construct possible, it is much simpler than "$combine"/"$combinable", (#119) and unlike "$merge"/"$patch" (#15) it cannot be abused to produce JSON that is not even a schema, or to splice things in ways that authors of the source of the splice never intended.

I feel like this is a more promising avenue than the other proposals so far. Would it be reasonable to recommend this and put some guidance on the web site and see how that goes in draft 6? Then maybe we'll find that we don't really need the more complex solutions at all.

Hi,

I want to add a dependency on presence of a property inside an object that is at the same level.

Example

{
    "Name": "Something", 
	"Data": {
        "Somekey1": "Some value"
    }
}

I need "Name" to be conditionally present, and it should depend on presence (or value of; hierarchy is the primary concern here) of Somekey1. Is this possible? If yes, can you please tell me the JSON schema for this?

Thanks.

I'd like to come up with a few different ideas for ways to rework the front page so people who don't know what JSON Schema is both (1) understand where they would use it and (2) are introduced to the core concepts (like the recursive nature, $ref, usage with HTTP, and the default-validates/empty-schema concept) as early as possible.

The build: https://travis-ci.org/json-schema-org/json-schema-org.github.io/builds/327592609

The reason the build fails after ajv update is that now draft-07 meta-schema is already added to the ajv instance and it is slightly differently defined in ajv than in the spec (the latest change in the spec was to replace empty schemas with true).

I will update the meta-schema in ajv and the issue will go away, but in general the test here needs to be updated to do one of the following:

• replace validations against meta-schema, e.g. ajv test -s schema -d "_includes/person.json" --valid with ajv compile -s _includes/person.json (that will validate against meta-schema by default).
• do not add meta-schema to the instance: ajv test -s schema -d "_includes/person.json" --valid --meta=false --validate-schema=false.

cc @Relequestual

There are quite a few things that you can do with $id that would be ill-advised when writing schemas for human consumption, but that have clear applications in processing tools. People often complain about the complexity of $id for this reason, and suggest removing functionality (or removing it entirely). Explaining the use cases, and why they are important despite being rarely seen in human-authored schemas, would help people to understand the keyword better.

Here's an explanation of one of those use cases that I wrote in json-schema-org/json-schema-spec#349 (lightly edited to stand better on its own):

An $id such as bar#/definitions/bar is allowed, although probably confusing for human readers. I've seen it in tools that "dereference" schemas by replacing all $refs with the things to which they refer (this only works when there are no circular references). To make that work right, you need to preserve the $id of the schema when you replace $ref with it.

That often includes a JSON Pointer fragment, especially when that $ref target does not declare a plain-name fragment $id of its own. But I've only seen that done as a processing step to produce a single in-memory non-circular data structure, and not as something that is presented to a schema user directly.

Clojure has a library for doing JSON Schema validation and I thought I would mention it since it's not listed on the implementations page :)

https://github.com/metosin/scjsv

Cheers,
code-ape

We're not even referencing this thing, I have no clue why it's suddenly not working

https://travis-ci.org/json-schema-org/json-schema-org.github.io/builds/355658613

$ bundle exec jekyll build
Configuration file: /home/travis/build/json-schema-org/json-schema-org.github.io/_config.yml
Source: /home/travis/build/json-schema-org/json-schema-org.github.io
Destination: /home/travis/build/json-schema-org/json-schema-org.github.io/_site
Incremental build: disabled. Enable with --incremental
Generating...
Liquid Exception: Could not locate the included file 'icon-github.html' in any of ["/home/travis/build/json-schema-org/json-schema-org.github.io/_includes", "/home/travis/.rvm/gems/ruby-2.4.1/gems/minima-2.4.0/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source. in /_layouts/default.html
jekyll 3.6.2 | Error: Could not locate the included file 'icon-github.html' in any of ["/home/travis/build/json-schema-org/json-schema-org.github.io/_includes", "/home/travis/.rvm/gems/ruby-2.4.1/gems/minima-2.4.0/_includes"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source.
The command "bundle exec jekyll build" exited with 1.

no disrespect but this kinda makes me eww:

what was the problem with the old site?