Home | Business News | Browse by Publication | X | XML Journal

XML Schemas in an object-oriented framework: established best practices and emerging design patterns. (Data Management).

Article Excerpt
XML Schemas provide the grammar and constraints of XML documents. Given the increasing prevalence of XML as a data and command transport format in enterprise software systems across industries, it's important to have a methodology when designing the structure of the XML you will create.

In this article, I will discuss how to leverage established object-oriented frameworks to design XML Schemas. The three tenets of object-oriented design--encapsulation, inheritance, and polymorphism--are examined along with emerging design patterns and when to apply them. Since industry consortia are creating industry XML standards, I will also discuss how to use and extend standards for your business needs. Finally, there is a brief overview of how to use Unified Modeling Language (UML) to follow the best practices described in this article.

Case Study: BigPharma

To illustrate, I'll use the fictional example of a large pharmaceutical company called BigPharma. BigPharma is one of the leading pharmaceutical companies in the world and is keen to take advantage of the genetic data rapidly becoming available. The retrieval and analysis of genetic data is done in the research department of the company. The research department must get the DNA sequences from different sources, analyze them using different analytical techniques, and then send the data to BigPharma's headquarters (see Figure 1). This analysis is then passed on to the drug-making department, and all this information is transported using XML. Since the data is complex and is crucial to the company's future profitability, BigPharma insists that the XML be structured properly and hires an expert to design the XML Schemas for the entire firm.

[FIGURE 1 OMITTED]

Encapsulation

The first thing the expert designs is a Data Types library for the firm. A Data Types library keeps all the common types used in a company in one place. For instance, the definition of an Employee is relevant to many departments in the firm--BigLab, Accounting, Drug Creation, Marketing--since all these departments contain and exchange information on employees. In order to create consistency in the definition used across the firm, the complex type Employee is kept in the Data Types library. You can name this file datatypes.xsd.

Whenever you need to send information about an employee, you will use the same definition of Employee. Observe the UML representation of Employee in Figure 2. You can see that Employee has a Name, an EmployeeID, and a Department. If BigLab's research.xml is using Employee, the schema research.xsd will just refer to Employee.



[FIGURE 2 OMITTED]

This is known as encapsulation...