XSLToolbox Home

    Rationale
    Download
   +APEX <-
       Article
       Examples
       PythonPoint
    ATTS
    Links
    Old News

APEX

Note

This page assumes familiarity with the notions of architectures and architectural forms. If you are unfamiliar with these concepts, you might want to read this document and look at some of the references on the “Related Links” page.

APEX (Architectural Processor Employing XSLT) implements a simple subset of the Architectural Form Definition Requirements (AFDR) specified in Annex A.3 of ISO/IEC 10744:1997. APEX behaves similarly to David Megginson's XAF package for Java and differs from the AFDR in the same ways as XAF. Input to APEX consists of an XML document plus stylesheet parameters identifying an architecture used by the document. APEX produces as output an architectural document, i.e. an XML document containing only the markup and data defined by the architecture specified.

Using APEX

Since XSLT provides no standard syntax for specifying stylesheet parameters, APEX's architecture use declaration syntax is XSLT processor-dependent. To understand how this affects the use of APEX, assume that APEX uses a fictitious XSLT processor called xslt whose command line syntax is as follows:

xslt xml-document style-sheet [parameter=value ...]

The following invocation of APEX would process the document doc.xml using the architecture arch1:

xslt doc.xml apex.xsl name=arch1

The XSLToolbox distribution contains several APEX usage examples.

APEX Stylesheet Parameters

The APEX XSLT transform uses the following parameters:

name

A required parameter specifying the name of the architecture being processed.

form-att, auto, renamer-att, suppressor-att, ignore-data-att

Optional parameters corresponding to pseudo-attributes from the architecture use declaration.

strip

An optional parameter specifying a list of attributes to be stripped during architectural processing. The list is specified as a space-delimited string. strip is useful for suppressing architectural support attributes from architectures other than the architecture being processed.

For example, if your XML document, doc.xml, is a client of architectures foo and bar, you want to create an architectural document for foo, and your document contains bar form attributes and bar-atts renamer attributes for the bar architecture, you would use strip as follows:

xslt doc.xml apex.xsl name=foo strip="bar bar-atts"

Customizing APEX

Because APEX is written in XSLT instead of in a programming language, APEX's functionality is easy to extend using xsl:import or xsl:include. Thus adding transformation capabilities to APEX that are supported by XSLT but not by the Architectural Form Definition Requirements is simple.

The XSLToolbox distribution includes an APEX customization example.

Differences from the AFDR

Like XAF, APEX differs from the Architectural Form Definition Requirements as follows:

  1. APEX ignores the public-id, dtd-public-id, dtd-system-id, and options pseudo-attributes in the architecture use declaration.

  2. Since APEX does not read an architecture's DTD, it cannot pick up any DTD-specified information about the architecture. As a result APEX does not allow architectures to inherit from other architectures. Also, because APEX cannot determine where an architecture allows character data, cArcIgnD causes APEX always to ignore data in non-architectural elements.

  3. APEX permits only simple attribute renaming. APEX does not support #CONTENT, #ARCCONT, or #MAPTOKEN.

  4. Renaming an attribute to #DEFAULT causes the attribute to be removed from the architectural document. If the architecture specifies a default value for this attribute, removing the attribute from the architectural document has the effect of replacing the attribute's value with the default.

  5. APEX uses the special element form #IMPLIED to specify elements in the input document that are not part of the architecture. This is needed because APEX does not read an architecture's DTD.

    Note

    This is a non-conforming addition.

APEX also exhibits the following additional differences from the AFDR:

  1. Bridge forms (architectural forms used to help resolve cross references during architural processing) are not supported.

  2. The architecture use declaration processing instruction is ignored. Information about an architecture is instead conveyed to APEX through stylesheet parameters.


Last modified $Date: 2003/03/12 20:34:14 $HomeFeedback