json-schema-org / json-schema-org.github.io Goto Github PK
View Code? Open in Web Editor NEWJSON Schema website
Home Page: http://json-schema.org
JSON Schema website
Home Page: http://json-schema.org
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.
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.
We've got #json-schema on Freenode now. We should link to this on the website.
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
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:
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.
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 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?
@json-schema-org/owners
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.
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.
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.
Add it to the editor list in http://json-schema.org/implementations.html?
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.
On http://json-schema.org/implementations.html#validator-javascript the link to the Persevere implementation is being rendered as:
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)
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?
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 $ref
s 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.
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
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:
schema
to indicate a non-standard POSTencType
to indicate PATCH by specifying a patch media typeI 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.
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".
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?
It still points to the old repo: https://github.com/json-schema-org/json-schema-org.github.io/blob/master/implementations.html#L14
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.
@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.
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.
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 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?
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.
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:
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:
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:
We start with an empty set of schemas, which we will call s.
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.
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!
At this stage, the value of additionalProperties is added to the set if and only s was previously empty.
(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
}
[ { "type": "string" } ]
[ { "type": "string" }, { "minLength": 10 }, { "format": "host-name" } ]
[ { "type": "string" }, { "minLength": 10 }, { "format": "host-name" } ]
[]
[ { "minLength": 10 } ]
[ { "minLength": 10 } ]
[]
[]
[ { "disallow": "boolean" } ]
For one array element, the schema which this element must validate against depends on its index in the array and the following keywords:
NOTE: array indices start at 0.
If items is absent, its default value is the empty schema. Which means all elements are valid. The end ;)
In this case, all elements of the array instance MUST be valid against the items keyword value, which is a JSON Schema.
If this is an array, then the schema is determined by the index of the array element to validate. There are two possibilities:
In this case, the element MUST be valid against the schema found at the given index in the items array.
In this case, it depends on the value of additionalItems:
This is equivalent to additionalItems being an empty schema, which means the element always validates successfully.
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.
Section 5.26 of the validation spec has an example using "type": "integer"
which should presumably be "type": "number"
.
Originally filed by @JulienPalard as json-schema/json-schema#197
shared.html has several 404 links
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.
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:
ajv test -s schema -d "_includes/person.json" --valid
with ajv compile -s _includes/person.json
(that will validate against meta-schema by default).ajv test -s schema -d "_includes/person.json" --valid --meta=false --validate-schema=false
.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.
"title": "Person",
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.
This material originally written by @fge and further updated by @sam-at-github at https://github.com/json-schema/json-schema/wiki/$ref-traps
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.
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.
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.
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.
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 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!
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.
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!'
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 ?
http://json-schema.org/examples.html
404 on
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.
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 ?
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.
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
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.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.