W3C’s XML Schema that is itself a form of XML. XSD stands for XML
Schema Definition. It is often simply called XML
Schema. It offers much finer control of XML document content than the
older DTD-style schema borrowed from HTML. XSD has a schema written in XSD used
to validate other schemas. You can download
it. It is 88k. Unfortunately, by default, Opera treats it as raw text. IE nicely
listed it with colours.
The two two main advantages of XSD over DTD for specifying an XML grammar are:
- The XSD grammar of the schema is simpler than DTD. XSD is just a flavour of XML.
- XSD lets you restrict in much more detail just what constitutes a valid file.
Sample XSD Schemas
The academics who wrote the XSD spec were more interested in impressing you than
informing you. Therefore there are no examples or even anything remotely like
English language descriptions of what the various grammatical elements are for.
Your only hope of making sense of it is to find example documents. Even the
primer fairly tough slogging. Keep looking at the example XML and XSD to clarify
the text. People can learn languages from a set of examples, heavily commented
gradually adding features much more easily than from descriptions of the grammar
in some esoteric formal grammar. That is how we learned English.
Note how it allows forward and backward references to permit a top-down
description of the document. In typical XML fashion, it is revoltingly verbose.
Oddly, you specify the attributes on a tag after you describe all the nested
tags that tag may enclose, even though when you write the actual XML the schema
describes, the attributes come first. NMTOKEN is an
atomic string without spaces, often the name of an enumeration value. The 2-letter
country codes would be NMTOKEN. XML lets you specify
the types of the fields with a rich set of built-in types which included bounded
integers, float, double, fixed decimal, dates, times, strings, urls, hex,
boolean, durations… You can set up enumerated types where you give a list
of the legal values of a field. There is even a pattern scheme, similar to Perl
regex, for describing legal string values. XSD also allows you to enforce
ordering of fields. Complete
list of types.
XSD allows you to specify the minimum and maxmimum number of times a field may
appear with the minOccurs="0"
maxOccurs="unbounded".
You can specify the types of fields with: type="xsd:positiveInteger"
type="xsd:string" type="xsd:anyURI"
options.
You can specify the allowable low and high bounds on a numeric field with: mininclusive
and maxinclusive.
There is a scheme to insist a data value be unique.
Sometimes the files are peppered with xs: and
sometimes with xsd:. This is an arbitary string to
abbreviate the xmlns name space defined at http://www.w3.org/2001/XMLSchema.
You can make it anything you like so long as it you use it consistently. It lets
the parser know that a word is an xms keyword. This way you can accidentally use
keywords for field names without confusion.
Understanding an xsd Schema
Understanding the keywords used in schemas, and comparing a schema with a known
valid compliant xml/jnlp file will be almost all you need to make sense of the
schema.
- attribute
- a keyword="value" modifier on a tag.
- choice
- A group of possible tags. You can pick any combination of them.
- complexType
- A tag that contains other tags nested inside it.
- element
- a tag that must appear in a particular order within a sequence group..
- enumeration
- describes one possible value of an attribute that has only a limited set of
legal values.
- maxOccurs
- the maximum number of times this tag can appear, "unbounded" for
no upper limit.
- minOccurs
- the minimum number of times this tag can appear, "0" for optional.
- NMTOKEN
- describes a enumerated field that can only have a value selected from a list.
What an idiotic name for such a keyword!
- restriction
- describes an attribute whose value is restricted in some way.
- sequence
- a group of tags that must appear in a particular order.
- simpleType
- usually describes an attribute that has restrictions on it.
Validating
Here is an example of validating xml with an XSD schema. This schema describes a
valid JNLP 1.0 xml file. You can check that your JNLP file is correctly formed
using an XSD Schema originally from Vampqh. You must copy the JNLP 1.0 XSD
schema posted below into the current directory as file jnlp1.xsd
or use the JNLP 6.0 XSD jnlp6.xsd then run the Java
validation posted below with:
java.exe ValidateJNLP jnlp6.xsd C:\mydir\myapp.jnlp
The above validator is not user friendly. You can get a good idea what it is
looking for by reading the XSD file. It only understands JNLP version 1.0 not
1.5, so it will complain bitterly about your kind="splash"
icons. You can temporarily comment out JNLP 1.5+ features in your jnlp
file to validate the rest. You would be surprised how many errors you will find.
I am on the lookout for 1.5 and 6.0 XSDs. I may have to compose them myself. It
is a bit like a BNF description of JNLP, written by someone with a terrible
lexical stutter.
Learning More
Sun’s Javadoc on the
Schema class : available:
Sun’s Javadoc on the
SchemaFactory class : available:
Sun’s Javadoc on the
Validator class : available:
Sun’s Javadoc on the
XMLConstants class : available:
Sun’s Javadoc on the
SAXParser class : available: