Here is an example of what can go wrong if you do not understand how the Dynamo Application Framework combines XML files. Suppose you extend the userProfile.xml definition file with your own file in the localconfig configuration layer. You want to use the receiveEmail property that appears in the standard user profile repository definition, but you want this property to be stored in the my_user table, rather than the dps_user table. The receiveEmail property is defined in the standard profile repository definition like this:

<!-- DPS userProfile.xml -->

  <item-descriptor name="user" ...>
    <table name="dps_user" ...>
...
      <property category="Email" name="receiveEmail" data-type="enumerated"
                default="yes" column-name="receive_email"
                display-name="Receive email">
        <attribute name="useCodeForValue" value="false"/>
        <option value="yes" code="1"/>
        <option value="no" code="0"/>
      </property>
...
    </table>
  </item-descriptor>

To replace this property with a similar property that is stored in the my_user table rather than the dps_user table, you might try to define this property in a /atg/userprofiling/userProfile.xml file in your application module or your localconfig directory, using the xml-combine="replace" directive, like this:

<!—Bad Example -->
<!-- my userProfile.xml -->

  <item-descriptor name="user" ...>
    <table name="my_user" ...>
      <property category="Email" name="receiveEmail" data-type="enumerated"
                default="yes" column-name="receive_email"
                display-name="Receive email" xml-combine="replace">
        <attribute name="useCodeForValue" value="false"/>
        <option value="yes" code="1"/>
        <option value="no" code="0"/>
      </property>
    </table>
  </item-descriptor>

This approach won’t work. In the Personalization module’s userProfile.xml, the receiveEmail property is defined under the dps_user table. But in the second userProfile.xml file, that property is defined under the my_user table. XML combination operates recursively starting from the outermost tags and working inwards. In this case, the <table> tags are matched by name. Since the table names dps_user and my_user don’t match, these two <table> tags are not combined. And since the <table> tags don’t match, the tags inside the <table> tags will not match up against each other. When the two userProfile.xml files are combined, you end up with two properties in the user item descriptor, each with the same property name: receiveEmail. So you end up with:

<!—Bad Example -->
<item-descriptor name="user" ...>
  <table name="dps_user" ...>
    <property name="receiveEmail" ... />
  </table>
  <table name="my_user" ...>
    <property name="receiveEmail" ... />
  </table>
</item-descriptor>

Since the resulting user item descriptor has two properties named receiveEmail, errors result.

To fix this is easy. Use the xml-combine="remove" directive in the dps_user table, rather than the xml-combine="replace" directive in the my_user table, as in this example:

<item-descriptor name="user" ...>

  <table name="dps_user" ...>
    <property name="receiveEmail" xml-combine="remove" />
  </table>

  <table name="my_user" ...>
    <property category="Email" name="receiveEmail" data-type="enumerated"
              default="yes" column-name="receive_email"
              display-name="Receive email" xml-combine="replace">
       <attribute name="useCodeForValue" value="false"/>
       <option value="yes" code="1"/>
       <option value="no" code="0"/>
    </property>
  </table>
</item-descriptor>

The xml-combine="remove" directive ensures that the old receiveEmail property is eliminated from the profile repository definition.