Is there a standard or specification which defines json file extensions?
I've seen .json used - is this just a commonly accepted practice or is it a requirement of some standards body for json saved in file format?
According to Douglas Crockford's draft of the JSON format found here:
"A JSON parser transforms a JSON text
into another representation. A
JSON parser MUST accept all texts that
conform to the JSON grammar. A JSON
parser MAY accept non-JSON forms or
extensions."
So, it's just a commonly-accepted practice; as long as your file conforms to the JSON grammar the extension doesn't necessarily need to be *.json (although it can certainly be helpful to you and other developers if it is).
Related
I'm looking for a way to generate a set of Angular2 form templates from a Swagger API definition file. I want a result that will allow me to test my POST/PUT requests, and even use it in my app.
After some research I found this Angular2 form library that takes a JSON schema as input: https://github.com/makinacorpus/angular2-schema-form
So if you know of a Swagger -> JSON Schema converter that will work too.
Cheers!
So if you know of a Swagger -> JSON Schema converter that will work
too.
Swagger 2.0 supports a subset of JSON schema draft 4. This is what swagger's Schema object is. From the docs:
The following properties are taken directly from the JSON Schema
definition and follow the same specifications:
$ref - As a JSON Reference
format (See Data Type Formats for further details)
title
description (GFM syntax can be used for rich text representation)
default (Unlike JSON Schema, the value MUST conform to the defined type for the Schema Object)
multipleOf
...
The following properties are taken from the JSON Schema definition but
their definitions were adjusted to the Swagger Specification.
items
allOf
properties
additionalProperties
It should be a fairly simple exercise to manually extract the schema from your swagger, but I don't know of any automated tool to do this. I think the fact some of the JSON schema properties have been modified by swagger may make auto conversion problematic in certain circumstances.
I'm working on a project where I ideally need to return a JSON object in an HTTP response where one field points to an xml snippet as a value. The object would look something like the following.
{
"driver1_url" : "https://driver.url.download.link",
"driver2_url" : "https://driver2.url.download.link",
"xml_snippet" : "<xml><snippet>value</snippet></xml>"
}
The xml snippet could be pretty long. Is it considered bad practice to embed XML into a JSON object? And if so, is there a better way to achieve what I've described?
It's not "bad" to add an XML string as a JSON value. It's only inconvenient if other programmers have to use your JSON response, because now they'd need an XML parser in addition to JSON abilities in their own programs. If you're the only one using JSON with XML values, then go ahead, have fun. It's your project, there's no wrong way to use these interchange formats so long as it works for your project and there's no expected need for compatibility with other systems.
If best practices are your concern, though, it is ideal to use either strict JSON or strict SOAP (the XML sibling of JSON, so to speak) for maximum compatibility.
I'm defining the structure of JSON documents. I'd like to know if how to validate the JSON documents against existing XSD, RelaxNG schemas or another standard schema language schema. I know of Jsonix, but I don't see that it uses the regular expressions from XSD or RelaxNG for validation against JSON schema (and I don't think that JSON schema is standardized).
Clarification: We already have existing XML and XSD. We can always go back to XML for validation, but it would be cool if we could validate the JSON directly, and would give us more confidence when we want to use the JSON and not XML.
Update: Here is the specification in question: http://www.web3d.org/specifications/x3d-3.4.xsd note that it doesn't have text nodes in the XML documents.
Preliminary answer (still a work in progress, but you can contribute):
If you want to convert XML schema to JSON schema, try downloading: XSD2OWL stylesheet which converts XML Schema to OWL. I converted my schema to owl like this:
$ xmlsh
$ xslt -f xsd2owl.xsl -cf file.xsd > file.owl
$ exit
Then download owl2jsonschema.js ** NO LICENSE ** and modify it until it until the demo works. The output will be in demo/OUTPUT/schema folder/*.json as separate JSON files.
XSD and RelaxNG are defined against XML, not JSON.
For JSON, see JSON Schema, but realize that it has nowhere near the adoption of XSD, and the latest draft of the specification expired August 3, 2013, casting doubts on the future of the effort.
Update
How do I validate JSON against XML Schema (XSD) or RelaxNG?
You don't.
The question is not "Can I?" but "How?" Say I have total control over
the JSON document.
When the answer to "Can I?" is "No" the question of how does not apply.
Clarification: We already have existing XML and XSD. We can always go
back to XML for validation, but it would be cool if we could validate
the JSON directly, and would give us more confidence when we want to
use the JSON and not XML.
You can validate the JSON directly against a JSON Schema, but not against an XSD. There are no tools that can do that; the standards are substantially different. The need to define standard vocabularies and grammars that is served by XSD and RelaxNG against XML was intended to be met by JSON Schema against JSON.
You're looking for "confidence when we want to use the JSON and not XML" in the wrong place. See reasons for choosing XML vs JSON instead.
As you're probably already aware of the information I'm about to post, this is just for reference.
Jsonix Schema Compiler supports generation of JSON Schema based on the XML Schema.
So with this you can convert you XML Schema into JSON Schema and validate your JSON against this JSON Schema using AJV.
This is still an experimental feature but that's the direction.
I'm confused what free-form JSON means. Does it mean you can put any types as values in {}?
I thought all JSON are like that (i.e. {'hi':123, 'abc':{'d':[1,2,3],'e':'yay'}}).
So what does free-form JSON mean. Is this a redundant term? Is there such thing as non-free-form JSON?
What you have just posted looks like a JavaScript object, but it is not valid JSON. JSON has some very strict rules, such as all strings must be in double quotes. See JSON.org
There's no such thing as "free-form"/"non-free-form" JSON as every valid JSON-string must be formatted according to the specific rules mentioned on JSON.org.
It's possible that "free-form" JSON is JSON that has been generated "by hand" meaning that you typed it out manually (error prone). Most languages either have built-in methods, or libraries that are available, that turn native data structures (like multi-dimensional arrays) into valid JSON.
PHP, for instance, has a native method called json_encode.
YAML 1.2 is (with one minor caveat regarding duplicate keys) a superset of JSON, so any valid JSON file is also a valid YAML file. However, the YAML 1.1 specification (which has the most library support) doesn't mention JSON. Most valid JSON files are valid YAML 1.1 files, but I found at least one exception by experimenting with PyYaml and Python's standard JSON library:
a double-precision floating-point overflow such as 12345e999 is interpreted as a string by PyYAML and IEEE infinity by Python's JSON library.
Does anyone have a complete list of differences, determined more robustly than by testing edge cases in a particular implementation? (That is, from a comparison of the specifications?) For example, I want to generate JSON strings that will be interpreted the same way by a JSON parser and a YAML 1.1 parser: what constraints must I place on my strings?
See here (specifically footnote 25). It says:
The incompatibilities were as follows: JSON allows extended character
sets like UTF-32 and had incompatible unicode character escape syntax
relative to YAML; YAML required a space after separators like comma,
equals, and colon while JSON does not. Some non-standard
implementations of JSON extend the grammar to include Javascript's
/*...*/ comments. Handling such edge cases may require light
pre-processing of the JSON before parsing as in-line YAML
See also https://metacpan.org/pod/JSON::XS#JSON-and-YAML
Related
What is the difference between YAML and JSON? When to prefer one over the other
As you noticed, one thing is what the specifications say the other what commonly available parsers (both YAML and JSON) process. You should therefore take several aspects into account and use the least common denominator to not be able to load your JSON with a YAML parser.
On the JSON side there are multiple standards and best practises. Originally a JSON text would have to have an object or array at the topmost level. This is still so according to the fail1.json files available on the json.org site:
"A JSON payload should be an object or array, not a string."
According to RFC7159 any value can be at the top level (apart from using a string, this leads to rather boring JSON files):
A JSON text is a serialized value. Note that certain previous
specifications of JSON constrained a JSON text to be an object or an
array. Implementations that generate only objects or arrays where a
JSON text is called for will be interoperable in the sense that all
implementations will accept these as conforming JSON texts.
Because of the problems with JSON hijacking *by redefining the array handing in older browsers) there have been implementations that only accept an object at the top level (i.e. the first character of the file has to be {.
On the YAML side there are fewer competing standards than with JSON, but things get muddled by the persistent usage of YAML 1.1, and is not helped by the fact that if you google for "yaml current spec" the first hit is yaml.org/spec/current.html and that is actually an old working-draft for YAML 1.1
Apart from the UTF-32 support the other answer mentioned, which is largely a non-issue in a world using UTF-8 almost exclusively, there are a few things to take into account, especially if you want PyYAML to to be able to parse your JSON (PyYAML still implements most of YAML 1.1 only, close to eight years after the YAML 1.2 spec release):
numbers in JSON don't need a dot in the mantissa, even if such a number has an exponent:
but the Floating-Point Language-Independent Type for YAML™ Version 1.1 does require that dot:
|[-]?0\.([0-9]*[1-9])?e[-+](0|[1-9][0-9]+) (scientific)
^--- no ? or * associated with this dot
(in the YAML 1.2 spec this regex has changed to:
-? [1-9] ( \. [0-9]* [1-9] )? ( e [-+] [1-9] [0-9]* )?.
allowing the dot to disappear even if there is an e (and no E) and exponent.
This is the cause for your 12345e999 being handled differently by JSON (overflow) and PyYAML (string). In YAML 1.1 this can only be interpreted as a string and hence doesn't need quotes and can be plain scalar.
In YAML 1.1 there are escape sequences, but this is not a superset from what JSON supports. The forward slash (/) can be escaped in JSON, but not in YAML 1.1 (it can in YAML 1.2, rule 53)
In JSON as well as in YAML 1.1 you can use \uNNNN to indicate a 16 bit unicode code point. Although the YAML 1.1 spec (and YAML 1.2) mentions surrogate pairs in conjunction with using UTF-16, nothing is mentioned about such pairs as escaped sequences ("\uD834\uDD1E"). This string sequence is explicitly mentioned in RFC 7159 as representing the G clef character (U+1D11E). I don't know of any YAML parser that support this, PyYAML throws a:
yaml.reader.ReaderError: unacceptable character #xd834: special characters are not allowed
So as long as you write your JSON
as UTF-8
with the top-level being an object
scientific numbers always with a dot
no \/ escape sequence
no \uNNNN characters between \uD7FF and \uE000 (exclusive), nor \uFFFE, nor \uFFFF
you should be fine for both JSON and YAML (1.1) parsers.
¹ In ruamel.yaml a YAML 1.2 parser of which I am the author, the \/ and scientific numbers without dot are handled correctly: your 12345e999 loads as type float and prints as inf.