File layout

XML is an excellent format to exchange data with, because it is basically a hierarchical text file, that is readable in Internet Explorer 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 an Adlib 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 Adlib 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) Adlib XML, like the example, in which also all used field elements are identical to field names in the Adlib target database (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. 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. 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 7.3, 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: