DDX principles

This section discusses the meaning of DDX elements and their relationships. The following example describes a single PDF document called doc1.pdf that assembles the contents of two existing PDF documents, doc2.pdf and doc3.pdf.

Example: Basic assembly

<DDX xmlns="http://ns.adobe.com/DDX/1.0/">

	<PDF result="doc1.pdf">

		<PDF source="doc2.pdf"/>

		<PDF source="doc3.pdf"/>

	</PDF>

</DDX>

The rest of this section explains some important points illustrated by this example.

First, DDX element names reflect the content that they represent:

•	The PDF elements shown in the example represent PDF documents.

•	Other DDX elements such as Bookmarks, Links and Headers represent specific content that is part of a PDF document (and can also be represented in external files). These types of content are also implicitly contained within the PDF element.

Second, a number of DDX elements can be used in different ways and are categorized depending on the context in which they are used. These elements are identified using the following terminology:

•	A result element typically has a result attribute and represents data being returned. Result elements have no initial content but accumulate the content of their child elements. See Result elements for details.

•	A source element typically has a source attribute and represents initial content. See Source elements for details.

•	A filter element is used much the same way as a source element, but its content comes from source elements nested within it. Filter elements have neither a result nor a source attribute but contain child elements of a certain type. See Filter elements for details.

A PDF element may be either a result or source element, depending on the presence of the result attribute or the source attribute. In this guide, these elements are usually referred to as PDF source or PDF result elements, rather than simply PDF elements.

Third, the strings appearing as values of the result and source attributes are names that refer to data streams. The data streams appear in the output and input HashMap objects, described in the "Programmatically Assembling PDF Documents" section in Programming with LiveCycle ES.

Note: As of LiveCycle ES 8.2, the Assembler service also supports the value of source and result elements being URLs, in which case the content is read from or written to the source or result destination, respectively. If the strings are URL references then the output or input HashMap object is not used to get or place data. (See URL References for Sources and Strings.)

The type of data is determined by the element name (for example, PDF or Bookmarks). The names can have extensions for clarity (for example, .pdf or .xml), although this is not required. The names do not refer to files in the file system, although the data typically originated from files (in the case of source elements) or will be saved to files (in the case of result elements). (See Input and output.)

Fourth, sibling elements aggregate content of the same kind. In the example, the two PDF source elements combine their PDF pages to contribute content, in the order specified, to the parent element. This principle does not apply to page property and content elements. (See Using page elements.)