This video introduces JSON.
Let's start by talking about its pronunciation.
Some people call it Jason, and some call it J-sahn.
I'll do a little bit of
investigation and discovered that the
original developer of JSON calls
it JSON so, I'll do that too.
Like XML, JSON can be thought of as a data model.
An alternative to the relational data
model that is more
appropriate for semi-structured data.
In this video I'll introduce the
basics of JSON and I'll
actually compare JSON to the
relational data model and I'll compare it to XML.
But it's not crucial to have
watched those videos to get something out of this one.
Now among the three models
- the relational model, XML, and
JSON - JSON is by
a large margin the newest,
and it does show there aren't
as many tools for JSON
as we have for XML and
certainly not as we have for relational.
JSON stands for Javascript object notation.
Although it's evolved to become pretty
much independent of Javascript at this point.
The little snippet of Jason in the corner right now mostly for decoration.
We'll talk about the details in just a minute.
Now JSON was designed
originally for what's called
serializing data objects.
That is taking the objects that
are in a program and sort
of writing them down in a
serial fashion, typically in files.
one thing about json
is that it is human readable,
similar to the way xml
is human readable and is
often use for data interchange.
So, for writing out, say
the objects program so that
they can be exchanged with another
program and read into that one.
Also, just more generally, because
json is not as rigid
as the relational model, it's generally
useful for representing and for
storing data that doesn't
have rigid structure that we've been calling semi-structured data.
As I mentioned json is
no longer closely tied to
Many different programming languages do
have parsers for reading json
data into the program and
for writing out json data as well.
Now, let's talk about the basic
constructs in JSON, and as
we will see this constructs are recursively defined.
We'll use the example JSON
data shown on the screen
and that data is also available
in a file for download from the website.
The basic atomic values in JSON are fairly typical.
We have numbers, we have strings.
We also have Boolean Values
although there are none of those
in this example, that's true and false, and no values.
There are two types of composite
values in JSON: objects and arrays.
Objects are enclosed in curly
braces and they consist
of sets of label-value pairs.
For example, we have an
object here that has a first name and a last name.
We have a more -
bigger, let's say, object here
that has ISBN, price, edition, and so on.
When we do our JSON demo,
we'll go into these constructs in more detail.
At this point, we're just introducing them.
the second type of composite
value in JSON is arrays,
and arrays are enclosed in square
brackets with commas between the array elements.
Actually we have commas in the objects
as and arrays are list of values.
For example, we can see
here that authors is a
list of author objects.
Now I mentioned that the constructs
are recursive, specifically the values
inside arrays can be anything,
they can be other arrays or objects,
space values and the values
are making up the label value
pairs and objects can also
be any composite value or a base value.
And I did want to
mention, by the way, that sometime
this word label here for
label value pairs is called a "property".
So, just like XML, JSON
has some basic structural requirements in
its format but it doesn't
have a lot of requirements in terms of uniformity.
We have a couple of examples
of heterogeneity in here, for
example, this book has an
edition and the other one
doesn't this book has a remark and the other one doesn't.
But we'll see many more examples
of heterogeneity when we do
the demo and look into JSON data in more detail.
Now let's compare JSON and the relational model.
We will see that many of
the comparisons are fairly similar
to when we compared XML to the relational model.
Let's start with the basic structures underling the data model.
So, the relational model is based on tables.
We set up structure of
table, a set of columns, and
then the data becomes rows in those tables.
JSON is based instead on
sets, the sets of label
pairs and arrays and as we saw, they can be nested.
One of the big differences between
the two models, of course, is the scheme.
So the Relational model has a
Schema fixed in advance,
you set it up before you
have any data loaded and then
all data needs to confirm to that Schema.
Jason on the other other
hand typically does not require a schema in advance.
In fact, the schema and the
data are kinda mix together
just like an xml, and
this is often referred to as
self-describing data, where the
schema elements are within the data itself.
And this is of course typically
more flexible than the to a model.
But there are advantages to having schema [sp?]
as well, definitely.
As far as queries go, one
of the nice features of the
relational model is that there
are simple, expressive languages for clearing the database.
In terms of json, although a
few New things have been proposed;
at this point there's nothing widely
used for querying Jason data.
Typically Jason data is
read into a program and it's manipulated programatically.
Now let me interject that this
video is being made in February 2012.
So it is possible
that some json query languages
will emerge and become
widely used there is just
nothing used at this point.
There are some proposals.
There's a JSON path language,
JSON Query, a language called jaql.
It may be that just like
XML, the query language are
gonna follow the prevalent use
of the data format or the data model.
But that does not happened yet, as of February 2012.
How about ordering?
One aspect of the relational model is that it's an unordered model.
It's based on sets and
if we want to see relational
data in sorted order then we put that inside a query.
In JSON, we have arrays as
one of the basic data structures, and arrays are ordered.
Of course, there's also the fact like
XML that JSON data is
often is usually written files
and files themselves are naturally ordered,
but the ordering of the data
in files usually isn't relevant,
sometimes it is, but
typically not finally in
terms of implementation, for the
relational model, there are
systems that implement the relational model natively.
They're very generally quite
efficient and powerful systems.
For json, we haven't yet
seen stand alone database systems
that use json their data
model instead JSON is
more typically coupled with programming languages.
One thing I should add however
JSON is used in NoSQL systems.
We do have videos about NoSQL
systems you may or may not have, have watched those yet.
There's a couple of different ways that JSON is used used in those systems.
One of them is just as
a format for reading data
into the systems and writing data out from the systems.
The other way that it is
used is that some of the
note systems are what are
called "Document Management Systems" where
the documents themselves may contain
JSON data and then the systems
will have special features for manipulating
the JSON in the document is better stored by the system.
Now let's compared json and XML.
This is actually a hotly debated comparison right now.
There are signification overlap in
the usage of JSON and XML.
Both of them are very
good for putting semi-structured data
into a file format
and using it for data interchange.
And so because there's so
much overlap in what they're used
for, it's not surprising that there's significant debate.
I'm not gonna take sides.
I'm just going to try to give you a comparison.
Let's start by looking at the
verbosity of expressing data in the two languages.
So it is the case
that XML is in general,
a little more verbose than Jason.
So the same data expressed in
the 2 formats will tend to
have more characters [xx] than Json
and you can see that
in our examples because our big
Json example was actually pretty
much the same data that we used when we showed XML.
And the reason for
XML being a bit more
verbose largely has to
do actually with closing tags,
and some other features.
But I'll let you judge
for yourself whether the somewhat
longer expression of XML is a problem.
Second is complexity, and here,
too, most people would say
that XML is a bit more complex than JSON.
I'm not sure I entirely agree with that comparison.
If you look at the subset
of XML that people really
use, you've got attributes,
sub elements and text, and
that's more or less it.
If you look at Json, you got
your basic values and you've got your objects and your arrays.
I think the issue is that
XML has a lot of
extra stuff that goes along with it.
So if you read the entire XML specification.
It will take you a long time.
JSON, you can grasp the
entire specification a little bit more quickly.
Now let's turn to validity.
And by validity, I mean the
ability to specify constraints or
restriction or schema on
the structure of data
in one of these models, and
have it enforced by tools or by a system.
Specifically in XML we
have the notion of document type
descriptors, or DTDs, we also
have XML Schema which
gives us XSD's, XML Schema Descriptors.
And these are schema like
things that we can specify, and
we can have our data checked to
make sure it conforms to the
schema, and these are, I would say,
fairly widely used at this point for XML.
For JSON, there's something called JSON Schema.
And, you know, similar to
XML Schema, it's a way
to specify the structure and then
we can check that JSON conforms
that and we will see some of that in our demo.
The current status, February
2012 is that this is
not widely used this point.
But again, it could really just be evolution.
If we look back
at XML, as it was originally
proposed, probably we didn't
see a whole of lot of use
of DTDs, and in fact not
as XSDs for sure until later on.
So we'll just have to see whether JSON evolves in a similar way.
Now the programming interface is where JSON really shines.
The programming interface for XML can be fairly clunky.
The XML model, the attributes
and sub-elements and so on,
don't typically match the model
of data inside a programming language.
In fact, that's something called the impedance mismatch.
The impedance miss match
has been discussed in database
systems actually, for decades
because one of the original
criticisms of relational database
systems is that the data
structures used in the database,
specifically tables, didn't match
directly with the data structures and programming languages.
So there had to be some manipulation
at the interface between programming languages and the database system and that's the mismatch.
So that same impedance mismatch
is pretty much present
in XML wherein JSON is
really a more direct mapping
between many programming languages and the structures of JSON.
Finally, let's talk about querying.
I've already touched on this
a bit, but JSON does not
have any mature, widely
used query languages at this point.
for XML we do have
XPath, we have XQuery,
we have XSLT.
Maybe not all of
them are widely used but there's
no question that XPath at least and
XSL are used quiet a bit.
As far as Json goes there
is a proposal called Json path.
It looks actually quiet a lot
like XPath maybe he'll catch on.
There's something called JSON Query.
Doesn't look so much like
XML Query, I mean, XQuery.
and finally, there has been a
proposal called [xx] language, but
again as of February 2012
all of these are still very
early, so we just don't know what's going to catch on.
So now let's talk about the validity of JSON data.
So do JSON data that's
syntacti[xx]  valid, simply needs
to adhere to the basic structural requirements.
As a reminder, that would be
that we have sets of label
value pairs, we have arrays
of values and our values
are from predefined types.
And again, these values here are defined recursively.
So we start with a JSON
file and we send
it to a the parser
may determine that the file
has syntactic errors or if
the file is syntactically correct then
it can parsed into objects in a programming language.
Now if we're interested in semantically
valid JSON; that is
JSON that conforms to
some constraints or a schema,
then in addition to checking the
basics structural requirements, we check
whether JSON conforms to the specified schema.
If we use a language like JSON
schema for example, we put
a specification in as a
separate file, and in
fact JSON schema is expressed in
JSON itself, as we'll see
in our demo, we send it
to a validator and that
validator might find that there
are some syntactic errors or
it may find that there are
some symantic errors so the
data could to be correct syntactically
but not conform to the schema.
If it's both syntactically and semantically
correct then it can move
on to the parser where
will be parsed again into
objects in a programming language.
So to summarize, JSON stands for Java Script Object Notation.
It's a standard for taking data
objects and serializing them into a format that's human readable.
It's also very useful for
exchanging data between programs,
and for representing and storing
semi-structured data in a flexible fashion.
In the next video we'll go
live with a demonstration of JSON.
We'll use a couple of JSON
editors, we'll take a
look at the structure of JSON
data, when it's syntactically correct.
We'll demonstrate how it's very
flexible when our data might
irregular, and we'll also
demonstrate schema checking using
an example of JSON's schema.