|

Buy
Professional ASP XML
Introduction
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.
For an example situation where you might want to carry out such
translations, consider converting an invoice sent by a field
office into a format that is used by central office. The central
office computer would have an application, or a web page, that
could load the incoming invoice, extract only the information
required by central office, and present it in a way that is
relevant to the staff at central office, that is, with its data
labels changed. Such a utility would save much time and trouble
sifting through lots of data just to pick out the snippets of
useful information.
In this case study we will show how to use ASP to create an
XSL file dynamically, and we will data-drive the process using
an XML file to define the contents of the XSL file. It is not
the intent of this case-study to provide the ultimate translation
tool. In fact, this is a simple translation tool that will only
map elements to other elements, working within a fixed container/item
structure. The mapping process that takes place could be achieved
by a simple XSL transformation, which is effectively what we
are doing, with the exception that the XSL is being generated
on demand.
Meet the Puzzle Pieces
Our example consists of the following pieces:
File name + Description
incoming.xml
In-bound XML that needs to be translated
default.php
Client-side test page that shows the translation at work
interpreter.php
The ASP page that generates the XSL
interpreter.xml
The definition file for the translation. This is the data that
defines the mapping between structures
The pieces are related to each other as shown below:
The Data
This case-study uses three XML files:
q The incoming data (input, aka: "incoming.xml")
q The translation definition file (process, aka: "interpreter.xml")
q The translated data (output, seen from the test page)
Let's look at the structure of each of these:
Input XML
<?xml version='1.0'?>
<shipments>
<shipment>
<waybill>123WXZ99</waybill>
<carrier>Fedex</carrier>
<shipDate>20000110</shipDate>
<boxes>3</boxes>
</shipment>
<shipment>
<waybill>79843A</waybill>
<carrier>UPS</carrier>
<shipDate>20000110</shipDate>
<boxes>2</boxes>
</shipment>
<shipment>
<waybill>XXX12A</waybill>
<carrier>Fedex</carrier>
<shipDate>20000110</shipDate>
<boxes>8</boxes>
</shipment>
</shipments>
Output XML
<?xml version='1.0'?>
<shipments>
<shipment>
<waybill>123WXZ99</waybill>
<shippedby>Fedex</shippedby>
<shipped>20000110</shipped>
<numberOfBoxes>3</numberOfBoxes>
</shipment>
<shipment>
<waybill>79843A</waybill>
<shippedby>UPS</shippedby>
<shipped>20000110</shipped>
<numberOfBoxes>2</numberOfBoxes>
</shipment>
<shipment>
<waybill>XXX12A</waybill>
<shippedby>Fedex</shippedby>
<shipped>20000110</shipped>
<numberOfBoxes>8</numberOfBoxes>
</shipment>
</shipments>
The Translation Process
As you can see, the input and desired output files have a similar
structure, but there are three differences:
q "carrier" becomes "shippedby"
q "shipDate" becomes "shipped"
q "boxes" becomes "numberOfBoxes"
The required element mapping is defined in the following XML
file:
<?xml version='1.0'?>
<shipments>
<shipment>
<xlat>
<in name="waybill"/>
<out name="waybill"/>
</xlat>
<xlat>
<in name="carrier"/>
<out name="shippedby"/>
</xlat>
<xlat>
<in name="shipDate"/>
<out name="shipped"/>
</xlat>
<xlat>
<in name="boxes"/>
<out name="numberOfBoxes"/>
</xlat>
</shipment>
</shipments>
As you can see, each <xlat> element contains an input
element name and an output element name. This is the mapping
we will use when we build our XSL. Note that the first of the
<xlat> elements does something rather pointless – replacing
"waybill" with "waybill". This has been
included just to keep the code as simple as possible. You could
put in some code to tell the interpreter not to process the
<waybill> tags and only change the others.
We could easily create similar translation documents for any
number of input documents. This would allow us to translate
all input documents with the same ASP page.
Buy
Professional ASP XML
|