Why Schemas?
As you develop distributed Web applications, you will need a way to represent
your structured data and send it from one tier to the other possibly over the
Web. XML is an excellent choice for representing structured data. For example,
you’ll find yourself sending XML data between the middle tier and the user
interface. The result is a set of middle-tier methods that emit or receive XML
strings. You might have a method that receives invoice data like this:
Public Function SaveInvoice(sInvoiceXML As String) As Boolean
This function receives an XML string that contains the invoice document. The
function then validates the invoice data according to your business rules then
saves it to the database and returns a Boolean indicating success or failure.
When the UI tier wants to invoke this function, they look at the above function
declaration and wonder just what the heck does the invoice XML look like? So
you might give them an example invoice XML document and tell them this is what
they have to send you. This works for a while, until you change the invoice XML
document to accommodate a new feature that you’re adding. Now all of a sudden,
saving an invoice from the UI does not work and you spend hours troubleshooting
the problem before you realize it’s a mismatch between what the UI is sending
and what you expect.
The problem here is that declaring XML data as just a String means your function
must handle validating the contents of that string to make sure that it is XML
and that it is a valid invoice document. It becomes very difficult to ensure
the UI is sending you the right invoice document unless you write lots of tedious
validation code and you maintain that code as the invoice document evolves. XML
schema solve this problem by providing a standard language to communicate the
invoice document structure to the UI tier and to validate the invoice document
that the UI sends to the middle tier before the middle tier starts processing
it. Think of the invoice XML schema as an extension to the above function declaration
where you specify exactly what the invoice XML looks like.
XML Schema is a W3C Recommendation (a standard) as of May 2, 2001. It is comprised
of three specifications: XML Schema Part 1: structures, XML Schema Part 2: Datatypes,
and XML Schema Part 0:Primer. The W3C’s XML Schema is sometimes referred
to as XML Schema Definition language or XSD for short. XSD is an XML-based grammar
for describing the structure of XML documents. A schema-aware validating parser,
like MSXML 4.0, can validate an XML document against an XSD schema and report
any discrepancies.
To solve the problem outlined above, you’d create an XSD schema that describes
the invoice document. You’d then make this schema available to the UI tier
developers. The schema is now part of the “interface contract” between
the middle tier and the UI. While the application is in development, the UI tier
can validate the invoice documents that they send against that schema to ensure
they are valid. Similarly, the SaveInvoice function can validate the input invoice
document against the schema before attempting to process it. Now if you change
the invoice document to support a new feature, you must change the schema accordingly.
Now the UI team tries to validate the invoice documents they’re sending
and this validation fails so they immediately realize that the schema has changed
and that they must change the invoice documents they are sending. This can also
help catch version mismatch problems where you have an older client trying to
talk to a newer middle tier or vice versa.