Links

apps.gotdotnet.com/
Don't feel like writing your own Schema? This clever on-line "Inference" tool will derive a Schema given an XML document. Note, the solution may not be as elegant / minimal as doing it by hand, but still worth a look!
Printer friendly version of this Page

'Happy XML Scheming' - An XML Schema Demo

A demonstration of how an XML file is validated against a given XML Schema file (XSD)


A buring hot Schema

The demo allows you to change the XML file and see the effect on the validation process. The summary explains why this process is so useful.

The different Schema types...

When people talk about validating XML documents, they might be referring to one of a number of different methods:

  1. DTDs (document type definition) files. This is the oldest standard, and it has been replaced because it has limitations. Amongst these are : A DTD must describe the XML document in its entirety, we can not validate against just the bits we want to be strict on; there is no provision for specifying datatypes in DTDs, i.e. Date, integer, or more complex types; DTDs are not themselves represented in XML, they have their own syntax.
  2. XDR - XML Data Reduced Schema. This is a simplified interim solution that overcomes the limitations of DTDs. However, this solution was only an interim measure whilst the full XML Schema standard was still being created and argued about.
  3. XSD - XML Schema. This is the latest fully flexible solution for specifying XML documents, now a full W3C Recommendation standard. The latest version of the Microsoft XML parser supports XSD Schemas (download MSXML4 from Microsoft, you must enter 'MSXML4' in the download search field). The following demo uses a XSD Schema!!!

XSD Validation Demo

The following demo presents an XML document that you may change. The point of the demonstration is to show you that this XML file is validated using a specific Schema. This means, obviously, if you change the XML in such a way that it is disallowed by our Schema rules then the validation will fail... So before you try editing it understand this:

The XML describes a list of Favourite websites - something that is easy to relate to! The Schema has 4 rules:

  1. The root xml (first tag) must be "favourites".
  2. "favourites" can contain any number of "favitems" followed by any number of "groups".
  3. Each "favitem" consists of an internal string type, and must have a url "link" attribute.
  4. Each "group" has the same definition as point (2), and in addition must have a group "name" attribute.

Great, nice rules, concise, but how on earth do we specify this in a schema? Why not take a look at the real XSD file that describes these rules - open it up in a separate window here. The XSD file is XML that you can read and hopefully, with a bit of effort, you should be able to understand how to get back to the above rules! XSD files can be far more complex than this example: we can specify sequences, choices, groups of elements and attributes; restrictions on data content and range; we can even import external schemas and join them to our schema... the power and flexibility is enormous (this article does not attempt to teach how to write schemas; it simply demonstrates how they may be used!).

Ok, so here is the XML file... (alternatively you can view it in IE in a nice friendly tree format). Go-ahead and change it if you wish (best to keep it subtle to start with - e.g. try removing a 'name' attribute from a group), then press the Validate button.


Summary

We can use the schema to describe to others (computers, companies, people) how we expect XML data given to us to be formatted. Or, looking at it in the opposite direction, we can test our own XML documents to see whether they are valid according to schemas belonging to others. In short, we are formalising our data interfaces using an industry standard. Believe me, when I say this offers a tremendous benefit across all industry sectors. Think of the huge amount of time people have spent in meetings thrashing out how proprietary interfaces will work both within their own organisation and externally; all of this effort only to come up with something that is completely unintelligible to newcomers and outsiders, and in all probability is difficult to support and maintain! Now compare it with the XML solution; anybody can 'join the party' so to speak, because everybody has access to the XML schema specification and XML itself. The data is in XML format, thus we can leverage all the added benefits of using XML... "XSL Transformations" for example, which happens to be the subject of the next article! Happy XML Scheming!

October 2003
 
© Copyright 2003 Mark V Williamson