Here is a motivating example for HEPTOX:

The source DTD is for the Montreal (General) Hospital database, and the target DTD is for the Boston Mass General Hospital schema.

In (a), every patient is assigned a unique hospital ID and has a unique MedCr#.  Patient elements contain sub-strees corresponding to their symptoms and treatments, while admissions data is maintained separately and is captured via the ID/IDREF link @PatRef->@ID (showned as a grey solid line in the above figure).

If a patient is transferred from Montreal to Boston, that patient's data must then be able to be queried by the Boston Hospital schema (b).  (b) is organized quite differently; it is grouped into an admission complaint (e.g., Pulmonary, or Coronary) and Progress.  The usual patient details are stored under Admission.  The Progress sub-tree records the patients' history of health problems and the treatments administered tracked, which is connected to the patients via the ID/IDREF link @PatRef->@ID.

The arrows provide informal correspondences between the two DTDs, and are illustrated by different lines to differentiate them from the structure of the DTDs. The arrows capture simple 1-1 correspondences between terms such as "MedCr#  in (a) to Patient in (b)".

Consider the correspondence between Desc in the two DTDs.  Desc has a unique parent in (a) while it has two parents in (b).  For disambiguation, we use the same line style for the edges Treat/Desc in (a), Treatment/Desc in (b), and the arrow connecting them.  Other arrows can be understood similarly.  In the only more complicated mapping in this figure, consider the green dashed box enclosing the Pulmonary and Coronary nodes.  Boxes are used to group together tags of nodes in a DTD that correspond to instances of a tag in another DTD, as part of the correspondence specification.  For example, the green dashed arrow Admission/Problem in (a) to the green box in (b) says that Pulmonary and Coronary correspond to values of the element Admission/Problem in (a).  In effect, illnesses, which may be instances of Admission/Problem in (a), correspond to tags in (b).  However, this correspondence makes no assumption that the set of illnesses occurring in the two databases are the same or even overlap.

HEPTOX lets users perform the whole process, from the creation of the peer-to-peer mapping to translating of queries.  Users only need to specify simple correspondences using arrows and boxes, and then HEPTOX will infer mapping expressions from the correspondences and translate queries over the inferred mappings.

Below are the inferred mapping expressions for the above example.

After the mapping has been created as shown above, translating the queries themselves can be difficult if not impossible.  Rather than using a view based rewriting schema, HEPTOX uses a different mechanism which allows it to translate queries simply and very efficiently over a simple but compelling subset of XQuery.