In this video we'll be learning about XML schema.
Like document type descriptors, XML
schema allows us a way
to give content specific specifications for our XML data.
As you may remember, we send
to a validating XML parser or
XML document as well as a description.
We talked about DTDs in the last video.
We'll talk about XSDs in this one.
The validating XML parser will
check that the document is well
formed, and it will also check that it matches it's specification.
If it does, XML comes out.
If it doesn't we get
an error that the document is not valid.
XML schema is an extensive language, very powerful.
Like document type descriptors we
can specify the elements we
want in our XML data,
the attributes, the nesting of
the elements, how elements need
to be ordered, and and number of occurrences of elements.
In addition we can
specify data types we can
specify keys, the pointers
that we can specify are now
typed like in DTDs and much, much more.
Now, one difference between XML
schema and DTDs is that
the specification locations in XML schemas
called XSD's are actually written in the xml language itself.
That can be useful for example
if we have a browser that nicely renders the XML.
The languages I said is vast.
In this video, we're going
to show one sort of quote easy example.
But that example will give
very much the flavor of XML schema.
And we'll try to highlight the
differences between XML schema and using document type descriptors.
Ok, here were are with our XML document on the left.
On the right we have our
XML schema descriptor or XSD
and we have a
little command line that we're gonna use for our validation command.
Now let me just say up front
that we're not going to be
going through the XSD line
by line in detail the way we did with DTDs.
As you can see it's
rather long and that
would take us far too long and be rather boring.
So what I highly suggest is
that you download the file for
the XSD so you can
look at it yourself and look
at the entire file as well
as the XML and give it a try with validating.
What I'm gonna do in this
demo primarily is focus
on those aspects of
the XSD that are different,
are more powerful than we had in document type descriptors.
First, let's take a look at the data itself.
So we have our bookstore data as usual with two books and three authors.
Its slightly restructured from any of the versions we've used before.
It looks closest to the
last one we used because the
books and authors are separate
and the authors are actually exactly the same.
The have an identifier and a
first name - last name sub element.
But the primary difference is in
the books, instead of using
ID refs attributes to refer
from books to authors, we still,
we now back our back having
an author's sub-element with the
two authors underneath and then
those authors themselves have what
are effectively the pointers to the identifiers for the authors.
And we'll see how that's
going to mesh with the XML
schema descriptor that we're using for this file.
So, the other thing I want
to mention is that right now
we have the XML schema
descriptor in one file and the XML in another.
You might remember for the DTD,
we simply placed the DTDs
specification at the top
of the file with the XML.
For DTDs you can do it either way in the same file or in a separate file.
For XSDs, we always put those in a separate file.
Also notice that the XSD
itself is in XML.
It is using special tags.
These are tags that are part
of the XSD language, but
we are still expressing it in XML.
So we have two XML files, the data file and the schema file.
To validate the data file
against the schema file, we
can use again the XML link feature.
We specify the schema file,
the data file and when
we execute the command
we can see that the file validates correctly.
So I'm now going
to highlight four features of
XML schema that aren't present in DTD's.
One of them is typed values.
One of them is key declarations.
Similar to IDs but a little bit more powerful.
One is references which are again
similar to pointers But a little
more powerful and finally a currents constraints.
So let's start with tights.
In our data we see
that the price attribute is
denoted with a string and
when we had DTDs, all attribute
values were in fact stringed.
In excess fees we can
say that we want to check
that the values which are
still look like strings actually confirm to specific types.
For example we can say that the price must be in integer.
Again I'm not going to
be labor the syntactic details but rather
I'm just going to highlight the
places in the XSD where
we're declaring things of interest.
So specifically here's where we
declare the attribute price and
we say that the type of price must be an integer.
So our document validated correctly, what
if we change this one hundred to be foo instead.
Of course with a DTD this
would be fine because all attributes are treated as strings.
But if we try to validate
now we see an error,
specifically foo is not a value of the correct type.
So let's change that foo back
to a hundred so that we validate correctly.
Next, let's talk about keys.
In DTD's, we were able to specify ID's.
ID's were globally unique
values that could be
used to identify specific elements.
For example, when we wanted
to point to those elements using ID refs .
Keys are a little
bit more powerful or more specific I should say.
If you think about the relational model
a key in the relational model
is an attribute or set of
attributes that must be
unique for each tuple in a table.
So, we don't have tables or
tuples right now but, we
do have elements and we often have repeated elements.
So similarly we can specify
that a particular attribute or component
must be unique within every element of the same type.
And we have two keys
in our specification, one key
which we can see here for books and one for authors.
Specifically we say for books
that the ISBN attribute must be a key.
And we say for authors
that the ident attribute must be a key.
So let's go over to
our data and let's start by looking at the authors.
So if we change, for
example, U to HG
then we should get a key
violation because we'll have two
authors that have the same ident attribute.
Let's try to validate.
In fact, we do correctly get
a key validation we also get
a couple of other errors and
those have to do with the fact
that we are using these items as
the destination of what are affect doubly pointers or references.
So let's change that back
to JU, make sure everything
now validates fine, and it does.
Now lets make another change.
So we have the ident
key here and we have
the ISBN number, being the
number for books, what if changed
the ISBN number to one
of the values we used as a key for the author, say 2HG.
When we did something similar with
DTDs we got an error
because in DTDs, IDs have be globally unique.
Here we should not get an error.
HG should be a perfectly
reasonable key for books because
we don't have another value that's the same.
And in fact it does validate.
Now let's undo that change.
Next, let's talk about references.
So, references allow us to
have what are Possibly typed
pointers, using the dtd.
So, they are called key
refs, and here we
have an example - let me just change this to the middle of the document.
So, one of the reference types
that we've defined in our DTD
is a pointer to authors
that we're using in our books.
Specifically, we want to specify that this
attribute here, the auth ident,
has a value that is
a key for the author elements.
And we want to make sure it's
author elements that its pointing
to and not other types of elements.
Now the syntax for doing
this in XML schema is rather detailed.
Its alright here and
just to give you a flavor,
this middle selector here is
actually using the XPath language
which we'll be using, which we'll
be learning later but what it
says is that when we navigate
in the document down to one of these auth elements.
Within that auth element, the
auth ident attribute is
a reference to what we
have already defined as author keys.
We've done something similar with books.
We have our book /remark/bookref
that brings us down to this element here.
And there we specified that the
book attribute must be
a reference to a book key,
and the book key was earlier
defined to be the ISBN number.
Again, I know this is all
complicated, and the syntax is
very clunky, so I urge
you to download the specification and spend time looking at it on your own.
Now let's make a couple of
changes to our document to
demonstrate how the checking of these typed pointers works.
For example lets change
our first reference here to food.
Let's validate the document and
we should get an error and indeed
we do, the author key rep is incorrect.
Now lets change that FU to JW,
so originally it was JU
But now we're going to have two
authors, both of whom refer to JW.
Now this should not be a problem.
It's simply two pointers to
the same author, and we did
not prohibit that in our
XMLs schema specification and indeed our document validates.
We'll change that one back.
And the last, as a last
change, we'll change our book
reference here to refer
to JW.
This should not validate because this
time, unlike with DTDs, we're,
we've actually specified typed pointers.
In other words, we've specified that
this pointer or this
reference must be to
a book element and not to an author element.
So we'll validate and indeed it fails.
I've undone that change and
now let's move to the last
feature that we're gonna look at
in this demonstration which is a currents constraint.
So in, let me just
bring up the first instance of
it, in XML schema,
we can specify how many
times an element type is allowed to occur.
Specifically we can specify the
minimum number of occurrences and the maximum number of occurrences.
As a default if
we don't specify for an
element the minOccurs or maxiOccurs the default for both of them is one.
So here for books we've
said that we can have
zero Books and we can have any number.
So this is the maximum flexibility, any number of elements.
For authors we've also said
we can have any number of authors
that's in the actual database itself.
Remember that our book store consists of a set of books and a set of authors.
But we are going to specify
something a little different for
how many authors we have within a specific book.
So let's continue to look
at other cases where we've specified
occurrence constraints.
Here is the case where we're
specifying how many authors we
have within a book and
again few boy this
is a lot of XML here
so take your time when looking
at it; or for now just take my word for it.
What we're specifying here is
how many sub elements, how
many auth sub elements we
have within each author's element.
And here we have no minOccurs
specification only a maxOccurs.
That means by default minOccurs is one.
So what this is saying specifically, is
that every book has in
it's authors sub element, atleast
one off, but we can have.
any number of them, that's the string unbounded.
Looking at the remaining occurrence constraints,
for remarks, we have the
minimum number of occurrences is zero.
In other words, we don't have to have a remark.
And we haven't specified max
occurs so the default max occurs is one.
So what we're saying here is that
every book may have either
no remark or exactly one
remark but it may not
have more than that.
And there's a few more occurrence constraints that
you can take a look at again
as you browse the XML schema description on your own.
Now let's make some changes in
the document to test these occurrence constraints.
So first let's remove the authors from our first book.
We won't remove the whole author
sub element but just the two
off sub elements of authors.
We attempt to validate and we see that it doesn't validate.
We're missing some child elements,
specifically the off-child elements
because we expected there to be at least one of them.
Incidentally, if we took
the entire author sub-element out,
we'll also get an error since
we've specified the books must have author sub element.
So now we're missing the entire
author structure in that book and again we don't validate.
Let's put authors back; and
now let's look at the
remark occurrence constraint so
we said that every book can
have zero or one
remarks, so let's just add another remark to this book.
Oh, hi, actually remarks are allowed to be empty.
In any case, we have added a small remark.
We validate and we see
that we have too many remarks
again because we specified that
every book can have at most one remark.
So that concludes our
demonstration of XML schema again,
it's been rather cursory we've
only covered a few of
the constructs but I did
focus on the constructs that
we have in XML schema
that are not specifiable in DTDs.
Finally one more time I
urge you download the access
fee and the document and play around with it yourself