Now let's see this all at work by looking at the test page, which is included in the source download as default.asp. We will use the JavaScript alert() function to display the XML because if we show it in the browser the tags will not be visible.

Now let's start looking at the process of generating the XSL file. Normal XML rules apply. The XML generated by our ASP page must be well-formed, which means that case matters.

This case-study uses three XML files:
- The incoming data (input, aka: "incoming.xml")
- The translation definition file (process, aka: "interpreter.xml")
- The translated data (output, seen from the test page)

As business to business commerce and inter-enterprise communication via XML continues to explode, developers will continually be faced with situations where they must convert XML documents from an incoming structure to the structure they use internally. It is this translation requirement that we will use as the premise for this case study.

A significant flaw may have been noticed in the final structure we arrived at in the last section - when building documents using this DTD, there's no place to add a <Customer> element. It's not the root element of the document, and it doesn't appear in any of the element content models of any of the other elements in the structure. This is because it is only pointed to, not contained.

The next step is to create an ID attribute for each of the structural (nondata point) elements we have defined so far in our XML database (with the exception of the root element). This is to uniquely identify elements that need to be referred to by other elements.

Once we've clarified the scope of the document that we need to create, which may be driven by business needs, we need to create the root element within which our XML representation of the data is nested.

The first rule when designing an XML structure to hold relational information is to decide what the scope of the document is. The scope refers to the data and relationships that we want to reproduce when creating our XML document - after all, when exposing the database content, we may not need all of the data that the database stores.

We'll be using an example to see how the rules we are creating would be applied in a real-world situation. The structure we'll be migrating to XML is an invoice tracking and reporting system.