OUTLINE OF A SOLUTION

A possible approach to solve the variability problems is to introduce an interface-based type mechanism for XML. This implies that an XML document becomes a component-like entity that conforms to a particular interface. As long as the interface remains the same, the schema of an XML document can be freely changed 2

without affecting the processing of the XML documents by the component. Essentially, the interface defines the assumptions the users of the document can make about the tasks that can be carried out with the document.

On the other hand, a different interface is needed to define the assumptions the XML document can make about the services that help to carry out those tasks. These two types of interfaces correspond closely to the conventional provided and required interfaces of components, respectively. The provided interfaces define the services the “XML-component” can give to its users, and the required interfaces define the callback functions to be called by the “XML-component” when carrying out its services. Naturally, an XML-document (or its schema) can provide and require several interfaces.

Consider again the two types of variability problems discussed in Section 2 (figure 1). The variation point of the first type can be realized using provided interfaces of the XML-document. That is, the XML-documents are viewed as components providing certain services related to their information contents. In this case all the different XML- documents implement the same interface, and only the latter is known to the client component. For example, the service could be “process all the purchase orders by producing statistics on the demand of each product”. The XML-documents for purchase orders may follow different schemata, and there may be completely different kinds of XML-documents (say, billing documents) that can provide the same service.

The variation point of the second type can be realized using required interfaces of the XML-documents. The XML- documents are in this case interpreted as components calling the services of other components through a well- defined interface. For example, such a service could be “process a single purchase order”. Typically (although not necessarily) the component which provides these services is the same component that calls the services in the provided interface of the XML-document. Thus the client of an XML-document can perform an action on the XML- data, and specialize it by giving its own implementation for the callback function called during the processing of the XML-document.

To summarize, in the case of unmanaged variability, the variation points are scattered throughout the schema specification and the client component processing the XML-document (figure 2a). In the case of extension-based (or inheritance-based) variability management, both the schema and the client are extended with product-specific parts (figure 2b). In the case of interface-based variability management, the fixed part of the architecture consists of the interfaces, while the schemata and the XML clients requiring and providing these interfaces are (or can be) product-specific (figure 2c). In the sequel we will study the interface-based approach in more detail.

XML-doc XML-schema Client depends reads product-specific parts

Fig. 2a. Unmanaged variability in XML

XML-doc XML-schema Client depends reads product-specific extension

Fig. 2b. Extension-based variability in XML

XML-doc XML-schema Client required Proxy provided generates depends (calls) reads implements product-specific schemata and components

Fig. 2c. Interface-based variability in XML

To be able to attach traditional interfaces to an XML- document, a proxy object is needed that actually implements the provided interface and calls the methods in 3

the required interface (figure 2c). The proxy component is an executable representative of the XML-document in the environment of the consumer; the proxy is actually the “XML-component”. The proxy is generated automatically on the basis of the schema of the XML-document. The consumer calls the "services" of the XML-document by calling the methods of the provided interface of the proxy. On the other hand, the proxy registers the client component, and calls back the client’s services through the required interface.

This solution implies that the architect should figure out the roles an XML-document can play in the system, and present these roles as provided interfaces of the XML- documents. In a platform architecture, these interfaces become a variation point, under which different XML- schemata can be introduced, implementing the same interfaces. If a new logical task emerges for the XML- documents, a new interface must be introduced, and the schema must be augmented with an implementation for that interface. However, if the structural parts of the schema remain the same, the old XML-documents can still rely on the new schema.

We have assumed that it is possible for the XML-document (or its schema) to define how the services of the provided interface are to be implemented making use of the services of the required interface and the information present in the XML-document instance. In principle this problem is analogous to the problem of attaching computation to a hierarchic structure. A solution to this problem has been presented a long time ago: attribute grammars [Knu68]. Attribute grammars associate semantic attributes to the nodes of a syntax tree of a context-free grammar, and rules defining the relationships of the attribute values in the branches. Various methods have been developed to compute the values on the basis of the rules, and to generate efficient evaluators from the attribute grammar. Attribute grammars have been the most successful technique for structure-oriented processing, applied mostly in the realm of compiler generation. Since XML elements can have attributes as well, the idea of applying attribute grammars looks very attractive.

However, in their general form attribute grammars are too clumsy and difficult to use for an average schema writer. We will apply a simplified version of attribute grammars, which is more close to so-called L-attributed grammars [LRS74]. The idea of L-attributed grammars is to restrict the dependencies of attributes in such a way that the evaluation of attributes can be carried out during a single left-to-right, top-down pass over the hierarchical structure. A benefit is that the schema writer can think of an attribution rule as a simple assignment statement executed at a time determined by its position in the structure. This makes the writing of the statements intuitively easier and close to normal programming. Any complex type definition

in the schema can be augmented with such statements. The statements are executed in the left-to-right, top-down order with respect to the DOM-tree (that is, the internal object representation of an XML-document produced by an XML parser).

We have now the constituent parts of the solution on a very abstract level: provided and required interfaces, and a mechanism to express how the provided interfaces are implemented using the required interfaces and the data values in the XML-file. We will next refine these concepts.