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.
Comments