Example: An Address Book

The folder C:\Documents and Settings\<username>\My Documents\Altova\StyleVision2008\StyleVisionExamples\Tutorial\ModularSPS contains examples of modular SPSs. The example files in this folder comprise a project in which an address book containing business and personal contacts is modularized. The example not only demonstrates the mechanisms in which modularization is implemented, but also illustrates the main reasons why one would modularize.

•

The complete address book is composed of two modules: (i) a business address book, and (ii) a personal address book, each of which has a separate SPS defining different designs. The two modules together make up the composite address book. Modularization in this case is used to compose: the modules are the components of a larger unit.

•

Although the content model of each module (business and personal address books) differs slightly from the other, both have a common module, which is the ContactPoints module, consisting of the core contact details: address, telephone, fax, and email. The ContactPoints module can therefore be shared between the two address books (business and personal). Modularization in this case enables a single module to be used as a common unit within multiple other units.

•

Further, the ContactPoints module can be modularized to provide more flexibility. In the example project, we have created a separate Address module to contain the postal address, which may have one of three content models, depending on whether the address is in the EU, US, or elsewhere. The output for all three content models is defined in a single SPS. However, they could have been defined in separate SPSs, which would have provided finer granularity. In this case, modularization would provide more flexibility as modules could be re-used more easily.

When creating schemas for modular SPSs, the most important thing to bear in mind is to create the elements that you wish to re-use as global elements. The schema for the address book is AddressBook.xsd. This schema has been constructed by importing the schemas for the business address book (BusinessAddressBook.xsd) and personal address book (PersonalAddressBook.xsd). The BusinessAddressBook.xsd schema provides a content model for companies, while the PersonalAddressBook.xsd schema provides a content model for persons.

Both schemas import the ContactPoints.xsd schema, which defines a content model for contact details.

Finally, the ContactPoints.xsd schema includes the Address.xsd schema, which defines the three address-type content models: for EU, US, and other addresses.

Imports are used when the imported schema belongs to a different namespace than the importing schema. Includes are used when the included schema belongs to the same namespace as the including schema. Notice that the XML Namespaces namespace (http://www.w3.org/XML/1998/namespace) has also been imported in some schemas. This is in order to be able to create the xml:base attribute by reference on the biz:Companies and per:Persons elements. The xml:base attribute is required to enable the XInclude mechanism supported by StyleVision.

The XML data is modularized using the XInclude mechanism, which is supported by StyleVision. The top-level XML document (which contains the entire address book) is AddressBook.xml. This file is shown in its entirety in the listing below.

xsi:schemaLocation="http://www.altova.com/stylevision/tutorials/myaddresses AddressBook.xsd"

This file is structured so that the AddressBook element contains the XML data from the files, BusinessAddressBook.xml and PersonalAddressBook.xml. The data from these two files is included by means of the xi:include element. When the two xi:include elements are resolved by StyleVision's XML parser, an xml:base attribute is created on the document element of these two XML documents when these are inserted. The xml:base attribute must therefore be specified as part of the content model definition of these elements (see the description of the schema files above).

Of course, there is no need to modularize the XML data into three files; the data in BusinessAddressBook.xml and PersonalAddressBook.xml could alternatively exist directly in AddressBook.xml. The reason the XML data in the project is modularized is to demonstrate the use of the XInclude mechanism and StyleVision's support of the XInclude specification. Note, however, that Authentic View currently does not support XInclude.

The description of the SPS modules starts with the most basic module (Address.sps) and progresses in compositionally incremental steps to the complete address book (AddressBook.sps). All the SPS modules use AddressBook.xsd as its schema.

•

Address.sps uses AddressBook.xsd as its schema, but the schema could equally well have been Address.xsd, ContactPoints.xsd, BusinessAddressBook.xsd, or PersonalAddressBook.xsd—since the Address element is present in all these schemas and would be available as a global element. When the SPS module is added to another SPS module, the schema of the imported module is ignored, so which one is used is not important when the SPS is added as a module.

•	The Working XML File is AddressBook.xml. Note that the main template in Address.sps specifies that only the Address element should be processed, and that global templates for Address-EU, Address-US, and Address-Other have been defined.

Because only the Address element is processed, the output previews show only the output of Address. When Address.sps is used as a module, the global templates are added and the main template is ignored.

This SPS imports one module. Note the use of global templates within other global templates and the main template.

•	Address.sps is added as a module, thus making the global templates of the Address-EU, Address-US, and Address-Other elements available.

•	Global templates for the ContactPoints and Email elements are defined. Note that the ContactPoints definition uses the global template of Email (screenshot below).

•	The main template—required for the previews—uses the global template of the ContactPoints element, thus enabling previews of the ContactPoints output.

This SPS imports one module, which in turn imports another. Note that the main template simply applies global templates.

•	Each of these two modules uses AddressBook.xsd as its schema. The Working XML Files are, respectively, BusinessAddressBook.xml and PersonalAddressBook.xml.

•	ContactPoints.sps is added as a module. This causes Address.sps to be indirectly imported. All the global templates in these two modules are available to the referring SPS module.

•	In BusinessAddressBook.sps, global templates are defined for the Companies and Company elements. Note that the Company definition uses the global template of ContactPoints.

•	In PersonalAddressBook.sps, global templates are defined for the Person and Persons elements. The Person definition uses the global template of ContactPoints.

There are two global templates for the Email element; any one can be activated..

•	BusinessAddressBook.sps and PersonalAddressBook.sps are added as modules, and this causes ContactPoints.sps and Address.sps to be indirectly imported.

•	A global template is defined for the Email element. This means that there are now two global templates for Email, one in ContactPoints.sps and the other in AddressBook.sps (see screenshot below).

•	In the Global Templates list in the Design Tree (screenshot above), you can select which of the two global templates should be active. StyleVision allows only one to be active at a time. Whichever is active is used within the ContactPoints global template.

Creating a Modular SPS, for a detailed description of creation of how to create a modular SPS.

Schema Sources, for a description of how schemas are used as sources for the SPS design.

Output Structure, which contains detailed descriptions of main templates, global templates, and Design Fragments.