Publisher’s version / Version de l'éditeur:
Vous avez des questions? Nous pouvons vous aider. Pour communiquer directement avec un auteur, consultez la première page de la revue dans laquelle son article a été publié afin de trouver ses coordonnées. Si vous n’arrivez pas à les repérer, communiquez avec nous à [email protected].
Questions? Contact the NRC Publications Archive team at
[email protected]. If you wish to email the authors directly, please see the first page of the publication for their contact information.
https://publications-cnrc.canada.ca/fra/droits
L’accès à ce site Web et l’utilisation de son contenu sont assujettis aux conditions présentées dans le site LISEZ CES CONDITIONS ATTENTIVEMENT AVANT D’UTILISER CE SITE WEB.
Proceedings of International Conference on Flexible Automation and Intelligent
Manufacturing (FAIM): 01 January 2004, Toronto, Canada, 1, pp. 648-655,
2004-01-01
READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THIS WEBSITE. https://nrc-publications.canada.ca/eng/copyright
NRC Publications Archive Record / Notice des Archives des publications du CNRC :
https://nrc-publications.canada.ca/eng/view/object/?id=3beb0973-6782-415b-99a7-7750d718be32 https://publications-cnrc.canada.ca/fra/voir/objet/?id=3beb0973-6782-415b-99a7-7750d718be32
NRC Publications Archive
Archives des publications du CNRC
This publication could be one of several versions: author’s original, accepted manuscript or the publisher’s version. / La version de cette publication peut être l’une des suivantes : la version prépublication de l’auteur, la version acceptée du manuscrit ou la version de l’éditeur.
Access and use of this website and the material on it are subject to the Terms and Conditions set forth at
Web-based generic product configuration using CSP
http://irc.nrc-cnrc.gc.ca
W e b - b a s e d g e n e r i c p r o d u c t c o n f i g u r a t i o n
u s i n g C S P
I M T I - X P - 2 0 3
X i e , H . ; H e n d e r s o n , P . ; N e e l a m k a v i l , J . ;
K e r n a h a n , M .
A version of this document is published in / Une version de ce document se trouve dans: Proceedings of International Conference on Flexible Automation and Intelligent
Manufacturing (FAIM), Toronto, Ontario, Jan. 1, 2004, pp. 648-655
The material in this document is covered by the provisions of the Copyright Act, by Canadian laws, policies, regulations and international agreements. Such provisions serve to identify the information source and, in specific instances, to prohibit reproduction of materials without written permission. For more information visit http://laws.justice.gc.ca/en/showtdm/cs/C-42
Les renseignements dans ce document sont protégés par la Loi sur le droit d'auteur, par les lois, les politiques et les règlements du Canada et des accords internationaux. Ces dispositions permettent d'identifier la source de l'information et, dans certains cas, d'interdire la copie de documents sans permission écrite. Pour obtenir de plus amples renseignements : http://lois.justice.gc.ca/fr/showtdm/cs/C-42
Web-Based Generic Product Configuration Using CSP
Helen Xie
*, Philip Henderson, Joseph Neelamkavil, and Michael Kernahan
Integrated Manufacturing Technologies Institute National Research Council Canada
800 Collip Circle, London, Ontario N6G 4X8, Canada ABSTRACT
Today’s manufacturers increasingly face demands on customized products to meet the challenges of global competition and customer satisfaction. As a result, many manufacturers have adapted their business models to mass customization, which enables customers to order customized products tailored to their specific needs. This new model combines mass production’s economies of scale with custom manufacturing’s flexibility. In order to successfully achieve mass customization, manufacturers have to overcome a major challenge on the time spent designing products to satisfy individual customer needs. A configuration system is becoming a key enabling technology in solving this mass customization issue. There are three kinds of configuration systems: procedure-based, rule-procedure-based, and constraint satisfaction based systems. The constraint satisfaction based system has advantages over the others in flexibility and generality. However it currently limits to search a solution within a finite and discrete domain. That means, during a design, components or parts can only be chosen from a limited number of existing models. This paper presents a system that extends the constraint satisfaction search to a continuous domain. It aims at a generic solution to automatically solve design problems of various product families. The system consists of a configuration engine to effectively find a constraint satisfied solution, a product model to facilitate the configuration engine, a product modeling tool to generate product descriptions, and a web framework dealing with online presentation.
1. INTRODUCTION
Today’s manufacturers increasingly face demands on customized products to meet the challenges of global competition and customer satisfaction. Customers demand products with lower prices, higher quality and faster delivery, but they also want products customized to their unique needs [1]. To meet these demands, manufacturers have to adapt their business model to mass customization, allowing customers to order customized products, often choosing from among hundreds of product features and options, usually at low cost. However, without the support of significant information technology capabilities, manufacturers would face numerous challenges in implementing mass customization, like the following:
(1) Lead time: Custom configuration of a product becomes a highly complex and time-consuming task as the number of configurable parts increases. A simple product with 100 parts can easily generate hundreds of thousands of combinations or product variations. Configuring such a huge number of possible combinations can result in a significant increase in lead time.
(2) Quality: As configuration may involve hundreds of configurable parts, there is increased possibility of making errors. Such configuration errors can create major slips in schedules and also leads to costly iterations downstream.
(3) Training: Configuration of a complex product requires good product knowledge and expertise. It takes training and time to gain such expertise and also requires additional efforts to keep up with frequent technical changes.
These challenges have become barriers for manufactures to deliver products tailored to individual customer needs. Thus successful implementation of mass customization requires significant information technology capabilities with broad application supports. A key technology that enables the implementation of mass customization is a product configurator [1].
A product configurator is a software application that captures customer’s requirements as input and automatically generates a product configuration matching the customer’s specific needs, based on pre-defined
*
design constraints. There are three types of configurators, which include procedure-based, rule-based, and constraint-based configurators. A procedure-based configurator embeds business rules of configuration into a software package; thus, it lacks the flexibility to adapt to different product families. A rule-based configurator uses an inference engine and production rules to provide flexibilities, but the high interaction between domain knowledge and control knowledge in production rules makes them difficult to maintain [2], especially in today’s dynamically changing product design environment. A constraint-based configurator models the product configuration task as a constraint satisfaction problem (CSP). The benefits of applying CSP for product configuration are two fold: flexibility and generality. Domain knowledge can easily and flexibly be represented in a constraint model, while, separating domain knowledge from control logic allows for the development of a generic product configurator.
A constraint satisfaction problem (CSP) is formulated by a set of variables, a domain of possible values for each variable, and a set of constraints defined over the variables. A solution to a CSP is a complete assignment of values to the variables such that all constraints are simultaneously satisfied. In product configuration, component types are represented as variables with discrete and finite domains, and the restrictions dictating how the various components can be combined to form a valid configuration are represented as constraints [3]. A configuration task is to assign values to all the variables without violating any constraints. The configuration framework has proven highly successful in product configuration. In practice, however, variables and constraints may take a wide variety of forms. Thus, configuration problems present several challenges in modeling constraints:
(1) While variables can be modeled in discrete and finite domains, they may also be modeled in continuous and numeric domains.
(2) Constraints can be unary and binary, but they can also be n-nary, meaning more than two variables may appear in a constraint.
(3) Constraints can be represented extensionally as compatible tuples or intensionally as mathematical expressions [4] or computable procedures.
(4) Some variables in an intensional constraint can be independently modified, while others may depend on variables outside of the constraint. This type of constraint is called a dependent constraint. For example, say we have the constraint x1+x2<10 with a domain [-20, 20] for x1and x2. Now, x1 cannot take any value
from [-20, 20] just yet, if it also has to satisfy the formula x1=2x3+4x4.
To address the complexity in constraint models, several extensions to CSP have been proposed including Dynamic CSP [5], Generative CSP [6], Composite CSP [7], and Mixed and Conditional CSP [4]. Although many types of constraints can be pre-defined, constraints with mathematical expressions and computable procedures require more flexible representation for general relations. One of the main contributions in this paper is a generic constraint modeling and solving framework to accommodate a variety of constraints including (but not restricted to) dependent constraints applicable to product configuration. In addition to the framework, the methodologies for constraint acquisition and solution presentation are also described. The goal of our approach is to leverage flexibility and generality of a constraint satisfaction paradigm for complex product configuration tasks and provide a generic solution to automatically solve design problems pertaining to various product families.
The remainder of the paper is organized as follows. Section 2 presents an overview of system architecture designs. In section 3, a generic framework for constraint modeling and search strategies is described. In section 4, a product modeling tool is introduced to facilitate representation of constraints with mathematical expressions and computable procedures. Section 5 provides conclusions.
2. SYSTEM ARCHITECTURE DESIGN
The architecture design aims at providing a generic solution of product configuration for a variety of product families. To achieve this end, it should also provide a product modeling tool that is embedded with features for defining different products. In addition, applying a constraint satisfaction paradigm to product configuration naturally achieves a generic solution for a configuration engine by separating domain constraint models from search algorithms. As shown in Figure 1, the system is designed to facilitate product modeling and product configuration for two groups of users: advanced user group and end user group. The advance user group, including engineers and information specialists, performs product modeling to generate a detailed product description as a constraint satisfaction problem before a product can be configured. The end user group, including customers, sale persons, engineers and production managers, performs a configuration task using a product configuration engine. Customers and sale persons enter customer requirements as input, and the configuration engine would automatically generate design results, which satisfy both customer requirements and design constraints. Engineers would review the design
results generated, and approve them as is, or make slight modifications. Production managers would take the approved design results and bill of materials into production stages.
Configuration Engine Product Modelling Tool Customer or Sale Person Production Manager Engineer Engineer and Information Specialist needs choices configuration pricing availability
design approval configuration
configuration bill of materials
product structure design constraints manufacturing info
Figure 1: Functional modules of the configurator system
The configurator system is designed as a web-enabled application using multi-tier application architecture. The multi-tier application architecture is generally divided into client-side presentation, server-side presentation, business logic, and data repository (Figure 2). The client-side presentation is responsible for accepting and validating the user input, communicating the user inputs to the web application server, and presenting the results received from the Web application server to the user. Clients, such as web browsers, use HTTP, the Internet standard protocols to communicate with the Web application server.
The server-side presentation is the focal point of Web application topology. Most of the contents presented in the configurator system are dynamic in nature. Thus, capacity to support dynamic content generation is a major design requirement. The responsibilities of the server-side presentation should include: receiving requests from the clients, selecting and executing the appropriate business logic based on these requests, coordinating with external database to retrieve data, and formulating the response and dispatching it back to the client. Model-View-Control design pattern is applied in designing the Web presentation framework to separate data, Web page, and business logic. The display beans are served as a data model to capture both submitted data from clients and displayed data from a server. JavaServer Page (JSP) is used as view to hold the dynamic content. Java Servlet and handlers are served as control to process all user actions, call the appropriate methods on the business logic, store the results into display beans, and then call the appropriate JSP pages to return the results of the action to the user.
Client-side Presentation Server-side Presentation Data Repository Business Logic Database Product Repository Product Constraint
Web Server/ Application Server Model Display Bean View JSP Control Servlet Handlers Search Algorithm Product Constraint Model Product Structure Abstract Constraint Model XML Modeler Code Generator XML Modeler Web Browser Modeling GUI Configuring GUI
Figure 2: Configuration system architecture design
The business logic is responsible for product modeling and product configuration. The product modeling tool automatically generates codes based on product descriptions from either user input or constraint database. The product descriptions are first represented as a XML model and then transformed into a product constraint model, a
product structure model, and display beans. The modeling task is to be done only once for a product family before performing configuration tasks. The configuration engine integrates a product constraint model with an abstract constraint model and search algorithms to automatically generate product configuration based on customer requirements. The configuration results are encapsulated into a hierarchical product structure model to be displayed back to users and to be saved into product repository.
The data repository is a server-side database system. It is responsible for establishing database connection, receiving and processing data operation requests, and responding the results to its calling client. The product constraint database, containing design parameters and design constraints, can be dynamically accessed by search algorithms for product configuration. The product repository database stores product configuration results along with customer requirements to be retrieved by users, including customers, sales representatives, and engineers.
During a configuration process, user inputs and configuration results are transferred between client and server using HTTP protocol. To keep these data alive, a user session is established to facilitate the communication. Because the Web application is designed to allow multiple users to perform configuration tasks simultaneously, the data transferred between client and server can become rather large. To avoid overloading the network, the user session is designed to keep a small footprint. After input data is transferred to server, they are deleted from the user session. To view the configuration results, the user session loads only what is required for display.
3. CONFIGURATION ENGINE
The fast response required by Web applications makes the efficiency of search algorithms a high priority in the design of a configuration engine. The need for a generic configuration engine to handle different product families is also a major design requirement. In addition, these two issues have to be considered for general relation constraints. To address these issues, we designed an abstract constraint model and search algorithms at a generic level. At the same time, we designed a product constraint model and a product structure model as templates for domain specific solutions. Put together, this generic framework meets the challenge of efficient and generic solutions for the configuration engine.
3.1 ABSTRACT CONSTRAINT MODEL
In order to accommodate general relation constraints in engineer-to-order product configuration, we introduce an extension to constraint satisfaction problems as a dependent constraint satisfaction problem.
Definition. A dependent constraint satisfaction problem is defined as triplet <X, D, C>, where • X={x1, x2, …, xn} is a finite set of variables,
• Each variable xi∈Xin can take its value from its domain Di, Di∈D, Xin is a set of independent variables,
a nonempty subset of X,
• Each variable xj∈Xde depends on its relations to its ancestors Xa⊆ Xin, Xde is a set of dependent variables. We partition X into the set of independent variables Xin and the set of dependent variables Xde.
• A set of constraints C restricts the combination of values that variables can take.
• A solution to a CSP is an assignment of a value from its domain to every variable from X, in such a way that every constraint from C is satisfied.
The domain of variables can be discrete or continuous. The ancestors of dependent variables can be independent variables or a subset of dependent variables. Eventually, the dependent variables are linked to independent variables by mathematical expressions or computable procedures. A constraint may be expressed as a satisfying tuples, but more generally, a constraint can be expressed as a Boolean function on mathematical expressions or computable procedures. The function takes instantiation of the variables participating in the constraint and returns true if the instantiated variables satisfy the constraint, and false if they do not.
In the abstract constraint model, domain is classified as symbolic domain or numeric domain. While the symbolic domain is a set of enumerable strings, the numeric domain is modeled by an interval with starting and ending values. Variables are classified as independent variables and dependent variables. While an independent variable contains a domain, a dependent variable only contains a value, because it cannot take a value from a domain independently. Nevertheless, the dependent variables require specific definitions with mathematical expressions or computable procedures in the product constraint model. All the constraints follow the same convention with a
Boolean function. However, they are categorized as pre-defined constraints and general relation constraints. The pre-defined constraints may be defined as unary constraints and binary constraints with various operators, including =, <, <=, >, >=. They may also be defined as n-ary constraints with tuples. The general relation constraint, in an abstract level, is only modeled as a Boolean value to indicate if the constraint is satisfied. In the product constraint model, it is specified by mathematical expressions or computable procedures among dependent variables and/or independent variables. In summary, independent variables and pre-defined constraints can be defined in the abstract constraint model, while dependent variables and general relation constraints are specified in the product constraint model. The abstract constraint model provides a unified framework to interact with search algorithms.
3.2 SEARCH ALGORITHMS
In a CSP paradigm, a solution can be found by searching through the possible assignments of values to variables. From the theoretical point of view, solving a CSP is a trivial exercise using systematic exploration of the solution space. However, from the practical point of view, efficiency is a major concern. Therefore, advanced and efficient algorithms are needed to overcome such shortfalls.
The first strategy is to reduce search space by eliminating the number of variables. As defined in the dependent constraint satisfaction problem, variables are partitioned into two subsets as independent variables and dependent variables. The assignment of a dependent variable is based on independent variables or other dependent variables. Since the dependent variables can not take a value independently during a search, they can be effectively eliminated from the search space.
A constraint often links to independent variables through dependent variables. Thus, whenever an independent variable takes another value during a search, dependent variables should be updated to reflect the value change. Since an update occurs frequently during consistency checks for constraints, it becomes a bottleneck for the efficiency of search algorithms. Therefore, some form of updating mechanism is essential for an efficient search algorithm involving dependent constraints. To ensure that dependent variables and constraints are not updated unnecessarily during consistency checks, a special updating mechanism is designed. In this updating mechanism, a directed acyclic graph (DAG) is constructed to describe dependent relations among independent variables, dependent variables, and constraints (Figure 3). While the dependent relations are considered as arcs, the independent variables, dependent variables, and constraints are considered as nodes in the DAG. The independent variables do not have any ancestors; and the constraints do not have any descendants. The nodes in the DAG can be assigned a topological order. This topological order indicates when a dependent variable needs updating, or a consistency check should be performed. Updating criteria are established for both dependent variables and constraints. A dependent variable should not be updated until its last ancestor from the topological order list is updated. Similar criteria should apply to constraints: a consistency check should not be performed for a constraint until its last ancestor from the topological order list is updated. By implementing this special updating mechanism during a search, unnecessary updates are avoided. As a result, performance of the search algorithm is significantly improved.
IV1 IV2 IV3 IV4
CPVi DVi 1 2 3 4 5 6 7 8 9 10 11 12 13 C1 C2 C3 C4 Independent variable Dependent variable Constraint Dependent relation
Figure 3: A directed acyclic graph for variables and constraints
The efficiency of the search algorithm can be further improved by choosing the order of variable instantiation. The variable ordering technique applies solely to independent variables. Because many-to-many relations between
independent variables and constraints exist, a variable can interact with other variables not only through its constraints, but also through connected variables. Thus, the first heuristic of ‘variable ordering’ is instantiating a variable with the maximum connected variables. If variables break ties in the first heuristic, a variable with the fewest domain values would be chosen as a second heuristic.
3.3 PRODUCT CONSTRAINT MODEL AND PRODUCT STRUCTURE MODEL
As previously described, it is not practical to define dependent variables and general relation constraints in an abstract constraint model when a specific product to be configured is not known yet. Thus, a product constraint model is designed to describe the domain knowledge for a particular product family. In the product constraint model, mathematical expressions or computable procedures are defined for dependent variables and general relation constraints. The product configuration problem will contain both the abstract constraint model and the product constraint model. By combining these two models together, search algorithms can be applied for searching a solution.
While a product constraint model is considered as an internal model for searching a solution, an external model is preferred for representing a product in a hierarchical structure so that, the product configuration would be more appealing to end users, such as customers, sale persons and engineers. A product structure model is designed to place independent variables and dependent variables into their corresponding components and organize components into a hierarchical structure as in a product structure tree. In an abstract level, product information common to all components are defined, such as component name, type, quantity, and description. The product information specific to individual component are organized under its corresponding component. A composite design pattern is used for modeling the hierarchical relationship among a product root, assemblies, and parts. The product structure model is used as the data source for displaying product configuration results to the Web presentation.
4. PRODUCT MODELING TOOL
Product descriptions in the product constraint model are considered as domain knowledge specific to a particular product family. The search engine must incorporate such product information to search for a solution. However, writing source codes applicable to a product constraint model for each product family may not be desirable as it requires programming knowledge. Thus, a product modeling tool is essential to automatically generate source codes and byte codes based on user input from a graphical user interface (GUI). In addition, since product information of the product constraint model is also shared with the product structure model and display beans in the Web presentation tier, the product modeling tool will be very beneficial for generating codes in the product structure model and display beans based on single source of input, which will ensure integrity and accuracy. By taking advantage of today’s rich and platform independent XML (eXtensible Markup Language) related technologies, XSLT (Extensible Stylesheet Language for Transformations) [8], the product modeling tool is able to generate codes automatically for the product constraint model, product structure model, and display beans. The tool is implemented as two modules: XML Modeler and Code Generator.
4.1 XML MODELER
The objective of XML Modeler is to generate XML files that describe the product information required for the product constraint model. XML provides a flexible mechanism to define a structured document. The advantage of XML is its ability in the exchange of a wide variety of data source and data format. The XML modeler is designed to support two scenarios: modeling from scratch through a graphical user interface and modeling with existing information retrieved from database. In the first scenario, the graphical user interface is essential to allow a user to enter information for variables and constraints. In the second scenario, as indicated by some real world applications, there have been variables and some constraints stored in database. In order for a user to model constraints with GUI, variables first has to be retrieved from database and presented to the user. Then, the user may supplement more information on constraints interactively through GUI. In this scenario, XML Adapters (Figure 4) can be designed to convert information from database into a XML document, as long as the conversion conforms to a XML schema defined for the product constraint model. In essence, the main purpose of the XML modeler is to generate XML files for defining variables and constraints. The XML modeler consists of XML schema, XML processor, Graphical User Interface, and XML adapter.
Central to the XML Modeler is the XML processor. Based on input from the user interface, it constructs in-memory tree structured object models for XML documents conforming to the XML Schema. The XML Schema, as specified by W3C (World Wide Web Consortium) [9], is an abstract data model describing the structures of the
Product Definition Graphical User Interface XML file XML Schema XML Processor XML Adapter Figure 4: XML modeler
XML document. It contains information similar to the Abstract Constraint Model. The XML document represents a domain model and contains information similar to the Product Constraint Model. In choosing XML processing API, we investigated standard models of SAX and DOM, and java language specific models of dom4j. SAX (Simple API for XML) provides an event-based framework for parsing XML data. However, it only provides access to the XML data and does not support creating a XML document. On the other hand, DOM (Document Object Model) is the official W3C standard for representing XML documents in a platform and language neutral manner. It is designed to provide a means of manipulating XML data. The DOM model makes heavy use of interfaces and inheritance for the different components of an XML document. This provides the advantage of using a common interface, but it also adds some complexity to the API. The java API dom4j provides an ease of use solution for Java development by making use of common Java components such as the Collections classes. It also supports XTSL integration. According to [10], dom4j has the performance advantage over DOM implementations. Therefore, the java model dom4j is chosen as our XML document processing API.
4.2 CODE GENERATOR
The code generator takes an XML document of product descriptions as input, and generates source codes of product constraint model, product structure model, and display beans as output (Figure 5). The most fundamental task for the code generation is to locate a particular element or set of elements within the input XML document and apply a rule or set of rules for the resulting codes. This can be accomplished by using an XSL template with XPath. While XPath provides a mechanism for referring to the wide variety of element and attribute names and values in an XML document, an XSL template is defined as a set of rules for each XPath expression and is applied to an XML document. X M L P A R S E R I N P U T T R E E T R E E T R A N S F O R M Product Constraint Model XSL Template Code Generator XML File X M L W R I T E R O U P U T T R E E Product Structure Model Display Beans
The next task is to use XSLT processor to handle the actual transformation and generate the output codes. As previously mentioned, dom4j integrates with XSLT, thus, it is also used as an XSLT processor in the implementation. A dom4j document can be used as the source of an XML document, the source of the XSL template, or the result of a transformation. Through dom4j XSLT processor, an XML document is transformed to output codes according to the XSL template.
As a summary to this section, the product modeling tool can automatically generate source codes and byte codes for the product constraint model. In essence, it provides a generic tool to allow the search engine to work with different product families.
5. CONCLUSIONS
Customized products offer great market potential to manufacturers in the current market of global competition and improved customer satisfaction. With more manufacturers adapting their business model to mass customization, the complexity of customized products brings new challenges to product configuration technology. The focus of the research here is general relation constraints in complex product configuration. The objective is to provide a generic solution for product configuration. The paper presents a system architecture design for Web-based generic product configurator. To deal with the general relation constraints, we proposed an extension to constraint satisfaction problems with numeric and dependent constraints. An efficient search strategy is presented for these types of constraints, including the search space reduction, the update mechanism and heuristic variable ordering. A product modeling tool is presented for modeling the general relation constraints and automatically generating source codes. The solution presented in this paper can be applied to a wide variety of product configuration problems. REFERENCES
[1] R. W. Bourk: “Product Configurators: Key Enablers for Mass Customization”, MIDRANGE ERP, <http://www.midrangeerp.com>, August 2000
[2] M. Stumptner: “An Overview of Knowledge-Based Configuration”, AI Communications: The European Journal on Artificial Intelligence, Vol. 10, No. 2, pp.111-125, 1997
[3] S. Mittal and F. Frayman: “Towards a Generic Model of Configuration Tasks”, Proc. of the 11th IJCAI, Detroit, MI, pp. 1395-1401, 1989
[4] E. Gelle and B. Faltings: “Solving Mixed and Conditional Constraint Satisfaction Problems”, Constraints Vol.8, No.2, pp.107-141, 2003
[5] S. Mittal and B. Falkenhainer: “Dynamic Constraint Satisfaction Problems”, Proceedings AAAI Conference, pp. 25-32, 1990
[6] M. Stumptner and A. Haselbock: “A generative constraint formalism for configuration problems”, 3rd Congress Italian Assoc. for AI, Torino, Italy, Lecture Notes in AI, Springer-Verlag. vol. 729, pp. 302-313, 1993
[7] D. Sabin and E. C. Freuder: “Configurations as Composite Constraint Satisfaction”, Working Notes, AAAI Fall Symposium on Configuration, Boston, pp. 28-36, 1996
[8] V. Okunev: “Generate JavaBean Classes Dynamically with XSLT”, Java World, February 2002 http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-xslt.html
[9] W3C: “XML Schema Part 0: Primer”, http://www.w3.org/XML/Schema#dev, May 2001
[10] D. M. Sosnoski: “XML in Java: Document Models, Part 1: Performance—A Look at Features and Performance of XML Document Models in Java”, http://www-106.ibm.com/developerworks/xml/library/x-injava/, September 2001
