Aggregation with XMLSPY
Aggregation with XMLSPY
By: Andrew Solymosi
Aug. 6, 2003 12:00 AM
Aggregation in XML is not trivial. Altova's XMLSPY offers a number of features facilitating this process. This article presents an example, including best practices and practical programming techniques - especially useful for those who don't like typing a lot of angle brackets.
Aggregation of XML (or HTML) documents means to collect the content of several XML files in one XML (or HTML) document (see Figure 1).
A portal product, for example, would aggregate the content of several data sources into one HTML page and present their contents in boxes in the user's browser. Most portals do this with programs written in Java, Perl, or some other programming language; however, XSLT includes the function document(), which is suitable for this purpose.
XMLSPY is a high-level XML editing tool, offering many visual capabilities for creating, changing, formatting, and presenting XML documents. The following example shows how XMLSPY's features can be used for aggregation.
An .xml document contains the data. XMLSPY can check (with the function key F7) if it is well formed, i.e., if it satisfies XML's syntax. With its data structure defined in an XSD document, XMLSPY can check (with F8) if it is valid (if it uses only the structures defined in the schema). The reference to XSD can be written into the XML document.
XMLSPY can automatically generate XSD for an existing XML document; however, it must be reviewed because it might contain undesired constraints.
An XSL document usually contains formatting information for XML data. It can be visually developed with Stylesheet Designer for an existing XSD document, and formatting can be assigned to every structure element contained there. The result can be viewed in HTML preview if a working XML file (with data) has been assigned. Stylesheet Designer stores the result in its internal .sps format (a special XML language) for further processing by XMLSPY's Stylesheet Designer for the "authentic view." Stylesheet Designer can also generate an XSL (or XSLT) document, which can be used by any XML processor (e.g., XMLSPY or an XML-enabled browser such as Netscape 6 or Internet Explorer 6.0). For this the XML document needs to contain a reference to the XSL document or vice versa (see Figure 2).
XMLSPY can process (with F10, with F11 even debug) the XSL document either way. Similarly, a link to SPS can be put into XML (used only by XMLSPY for the "authentic view").
Stylesheet Designer also allows you to take an HTML document, but not an XSD, for the design's base. It can also be saved as .sps and .xsl.
XMLSPY can present XML data in the following views:
For the authentic view it is necessary to have defined an SPS
document with Stylesheet Designer. XMLSPY will then present the XML
data in the defined format, offering very convenient editing and
extending. However, only data elements that exist in the original XML
file can be changed or extended. So the steps to working with XMLSPY
Alternative designs (e.g., through modifying the SPS file) would present the same data in a different style.
There is no principal difference between XSL and XSLT: both document types are processed against an XML document. However, it's a good convention to put formatting information into XSL (as a stylesheet) and transforming information into XSLT documents. XSLT should output XML data, and XSL can output XML or HTML.
The XSLT document aggregate.xslt performs the actual aggregation (see Listing 1). aggregate.xslt contains two rules: the first one, xsl:template match, matches the whole input XML document ("/"), generates a <result> tag (with an XSD reference), and then looks for <families> tags in the XML document (xsl:apply-templates select). The second rule matches all the <location> tags in the input XML document and copies the document with the URL given in the tag's data.
An example with families shows how this aggregation works - the idea is to have several XML documents describing families (with country, last name, father, mother, and children):
<!-- orlando.xml -->
and one index file listing all the family documents (named by the residences of the author's family members, suggesting that those XML files can be scattered all around the world, just like today's families):
<!-- index.xml -->
The goal of the aggregation is to present all the families on one page.
Table 1 shows the result of aggregating the files and presenting their content in a table with a stylesheet. There are two main steps in this process: aggregation and presentation. They are described in the two files aggregation.xslt and style.xsl. In aggregation.xslt we program the aggregation (i.e., pulling the content of the documents together); in style.xsl we store formatting information.
All these files can be downloaded from www.solymosi.com/Andreas/Family/Aggregation.html.
Example: Aggregation with XMLSPY
The document family.xsl is not necessary if the data documents are not going to be presented in a browser. family.sps is necessary only if they are going to be visually edited in XMLSPY (a very convenient feature). family.xsd is necessary every time an XML processor is going to validate a data document (like XMLSPY does when opening it).
Create aggregation file
Note: In step 10 we created the index file with two location tags; not with four (or more) because in the authentic view (step 12) it's easier to edit; not with one so that the schema file index.xsd contains the repetition. If the complete index file is created in step 10, steps 11-12 can be omitted.
The aggregation process (step 16) can also be debugged with Alt-F11 and F11. The aggregation can be started either with index.xml (as described) or with aggregate.xslt. In this case a working XML file must be assigned (menu XSL, assign sample XML). The assignment
can be written into the document aggregate.xslt (after the ?xml instruction) - this is a processing instruction evaluated by XMLSPY. Alternatively, the document index.xml can contain the reference
<?xml-stylesheet type="text/xsl" href="aggregate.xslt"?>
in order to eliminate step 15 (see Figure 4).
Step 22 (assigning style.xsl) can be eliminated if the assignment is generated by aggregate.xslt; it should then contain the following instruction:
before the line
<!-- index.xml -->
XMLSPY and popular XML-enabled browsers (like Netscape 6 or Internet Explorer 6.0) would perform only the first step (aggregate.xslt) and present the result without formatting by the stylesheet. This is because they are not designed for actual XSLT processing, just for formatting with a stylesheet. Many XSLT programmers might tend to solve the problem by combining aggregate.xslt and style.xsl into one stylesheet document. However, I believe it's better to separate transforming XML information (which is structural) from formatting HTML information (which is presentational).
Maybe the greatest advantage of using XMLSPY for those who don't like angle brackets (i.e., low-level XML editing) is its authentic view for visual editing of XML data. Altova also offers a plug-in for popular browsers, allowing XML editing in Web clients (without XMLSPY installed).
Reader Feedback: Page 1 of 1
Tweets by @BigDataExpo
Digital Transformation Blogs