Just like CSV, XML is a much used exchange file format that is used and recognized by many database programs but with much better support for repeated fields.

The paragraphs below describe the unstructured XML format and tag mapping for import with Designer or import.exe. Importtool.exe however, can only import AdlibXML (not any deviating XML types) for this new tool the mapping of source fields from the XML exchange file has been simplified in version 7.13.1.6881. Where the Designer import functionality requires full XML paths in the Source field column (see below) on the Mapping tab of an import job, importtool.exe only allows field names in this column (without any path in front of them or any sharp brackets). For execution with ImportTool (which is the recommended tool), the import jobs themselves can still be made in Designer, but not all options are supported in importtool.exe currently: please see the full topic for more information.

File layout

XML is an excellent format to exchange data with, because it is basically a hierarchical text file, that is readable in a browser or a text editor, and in the latter you may even edit the file, if you are familiar with the XML language. Also, repeated fields are properly supported: multiple occurrences of fields are typically listed below each other in separate nodes with the same field name (see the example of part of a so-called unstructured XML file below). (The XML nodes underneath a record node typically represent the field names.)

<adlibXML>
- <recordList>
   - <record>
        <objectname>mug</objectname>
        <objectname>cup</objectname>
        <objectnumber>087-198</objectnumber>
     </record>
   - <record>
        <objectname>dish</objectname>
        <objectnumber>056-012</objectnumber>
     </record>
  </recordList>
</adlibXML>

Conversion

With Designer, these files (unstructured XML only) can only be imported, not exported; from a Collections application you can export to XML though.

For the tag mapping in an import job, you enter the full XML path of the fields in the exchange file as source tags, and the Collections field tags as destination tags. As the last tag pair you define the record separator: this must be the last (/) node of a record in the XML file.
Or, if the imported XML is (unstructured) AdlibXML, like the example, in which also all used field elements are identical to field names in the Collections target database table (the example would require objectname en objectnumber to appear in your database written exactly like this), then you can also use ** as the single source "tag" and ** as the single destination "tag" to indicate that you'd like to import all fields to the identical fields in the target database table. To exclude certain fields from being being imported if you use the mapping ** | **, map each of those fields literally to: <null> (the word "null" enclosed by sharp brackets). Fields mapped to <null> will be ignored during import.

Any element attributes like lang, occurrence and invariant are supported. Do of course only import multilingual data into a similar multilingual database table. Note that although unilingual field elements usually do not have attributes, the occurrence attribute can in principle (via a separate XSLT conversion of the source XML) be added to these elements without causing problems, if you need to keep track of the numbers of (empty or filled) occurrences of different unilingual and multilingual fields which are part of a field group.
Also note that in Designer, importing of one or more multilingual values into a linked field is not supported if the linked multilingual record doesn't exist yet. In other words, if a record in your exchange file contains e.g. a single object name (linked field) in English and Dutch, then you can only hope to import this record without errors if the thesaurus already contains a multilingual record with at least these two translations. In this case the link from the new object record to the existing thesaurus record will be made correctly. So as long as an import procedure doesn't have to force a multilingual record into a linked database, everything should go as planned. This also means that you may very well import multiple translations of a single multilingual value into a non-linked (multilingual) field. It follows from the above that the typical way to import multilingual data is to import multilingual data into non-linked fields in authority databases like the thesaurus first and only after that, import object records containing the multilingual data (or just one of the translations of the linked value, including the proper attributes) while processing links.

Example of a tag pair definition: