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: