When element types represent hierarchy that exists in the XML document
but not in the database, they can be eliminated by "passing-through"
the unwanted elements -- that is, by treating their properties as if
they were properties of their parent. For example, suppose a Customer
element type has the following structure:

   <Customer>
      <Name>ABC Incorporated</Name>
      <Address>
         <Street>123 Main St.</Street>
         <City>Chicago</City>
         <State>IL</State>
         <PostCode>60609</PostCode>
         <Country>USA</Country>
      </Address>
   </Customer>

Under the standard tree-of-objects view used by XML-DBMS, Address
requires its own table. But what if the street, city, state, etc.
existed as columns in the Customer table? It is relatively easy to
eliminate the Address element and treat its children as properties
of the Customer element. The problem with this is that there is no
general solution for reconstructing passed-through elements when
retrieving data from the database. In the case above, we know that
there is a single Address element and that Street, City, etc. are
its children. Now imagine the case in which an element A can have
multiple children B, each of which can have multiple children C:

   <A>
      <B>
         <C>...</C>
         <C>...</C>
      </B>
      <B>
         <C>...</C>
         <C>...</C>
      </B>
   </A>

If we pass through the element B, we store four C's in the database
as properties of A. However, when retrieving the C's from the database,
we have no way of knowing whether these all came from a single B, they
can from the two B's shown above, or they came from four different B's.

In the simple case -- a passed-through element occurs exactly once in
its parent -- the following mapping language constructions can be used
to pass-through an element type:

<!ELEMENT ClassMap (ElementType,
                    (ToRootTable | ToClassTable),
                    PropertyMap*, RelatedClass*, PassThrough*)>

<!ELEMENT PassThrough (ElementType,
                       PropertyMap*, RelatedClass*, PassThrough*,
                       OrderColumn?)>

Note that a PassThrough element looks almost the same as a ClassMap.
This is not surprising, as the passed-through element is simply an
element type-as-class that does not have its own table. For example,
the following declares that the Address element type is to be passed
through. Like element types-as-properties, passed-through element
types are mapped on a per-parent basis, so this map is nested inside
the class map for Customer.

   <PassThrough>
      <ElementType Name="Address"/>
      <PropertyMap>
         <ElementType Name="Street"/>
         <ToColumn>
            <Column Name="Street"/>
         </ToColumn>
      </PropertyMap>
      ...other property maps...
      ...related class maps...
      ...pass-through maps...
   </PassThrough>

The first ElementType element gives the name of the passed through
element type. Because passed-through element types are viewed as
classes, the PassThrough element must map the properties, related
classes, and passed-through child classes of the passed-through
class, just like a class map does. Shown above is a property map
that maps the Street element type to the Street column of the
parent table (Customers).

There are a number of comments in the code to show where/how
pass-through can be implemented. When transferring data to the
database, the function to get a child element needs to check if
the next child is pass-through. If so, the children of that element
are processed immediately. That is, the grandchildren of the element
being processed are treated as if they were children. When
transferring data from the database, properties need to be checked
to see if they have a pass-through parent; if so, the parent needs
to be reconstructed before the children are added. Note that, in the
case of children of passed-through elements, order refers to the
order in the passed-through element, not the grandparent.