Understanding the Data Dictionary building block assets

The data dictionary is a catalog of data elements, and their descriptions, used in a business domain using a business vocabulary. The data dictionary also contains metadata for managing the data model to provide descriptions of the data structures and their associated attributes. Typically, business users do not require knowledge of metadata representations like XSD (xml schema), FML (Adobe application modeling language), Java classes, and ActionScript classes, used by developers. However, they usually require access to these data structures and attributes to build solutions. The Data Dictionary building block provides an independent representation of metadata and back-end integration. Business users, with no knowledge of back-end system integration, can use this building block to create and use models at a solution level. Within LiveCycle, business users are able to express conditions or use data in the solution's workflows using the data dictionary.

Tools

Developing a solution that uses a data dictionary typically involves the use of the following tools:

Data Dictionaries. The user interface that enables browsing, creating, editing, and exporting data dictionaries. It is accessed through the Manage Assets page in your portal within the Admin pane.
Data Dictionary Editor. The user interface that allows creation and maintenance of the data dictionary that is shipped with this building block.
- Enables import of domain-specific XSD schema to create a data dictionary.
- Allows addition/deletion of data dictionary elements (DDEs) over/from a data dictionary
- Allows association of attributes at data dictionary level.
- Allows association of attributes at DDE level.
- Allows exporting of a data dictionary into annotated FML.
- Allows importing of an annotated FML to create a data dictionary.
- Allows creation of sample data xml for a data dictionary. The sample xml can be used to enable the data dictionary instance-dependent use cases, quickly, without having back-end support in place.
Java Development Tools:
- IDE for creating Java/Spring projects
- ANT build tools
LiveCycle Tools
- Adobe® LiveCycle® Designer
- Adobe® Flash® Builder™

For additional information about the Data Dictionary building block services, see these resources:

For information about the Flex APIs, see the ActionScript 3.0 Reference for the Adobe Flash Platform.
For information about the Java APIs, see the Correspondence Management Solution API Reference.

Data Dictionaries

Using the Data Dictionaries pane you can create and manage data dictionaries. Within this pane, you can create or edit existing data dictionaries by clicking New or Edit to launch the Data Dictionary Editor.

View full size graphic

Data Dictionaries Pane

Data Dictionary Editor

The Data Dictionary Editor is used for managing data dictionaries and its associated elements. A middleware developer can create, modify, and delete metadata properties for both the data dictionary and its elements using the Data Dictionary Editor.

View full size graphic

Data Dictionary Editor

The Data Dictionary Editor enforces validations while creating or updating a data dictionary. For more information on the rules for creating DDEs for a valid schema, see Data dictionary elements.

View full size graphic

Data Dictionary Elements

The Data Dictionary Editor allows business process owners to create data dictionaries by importing them from a valid XML schema or FML model. Business process owners can also export their data dictionaries to FML or generate a sample xml data from the Data Dictionary Editor.

If the middleware developer attempts to import a schema with multiple top-level elements, the Data Dictionary Editor prompts for a single top-level element. The developer selects one of the top elements for use in creating a data dictionary tree. The data dictionary represents a cohesive instance of data for a given context, rather than a set of disjointed data. An XSD with a forest of elements represents multiple trees of elements - with each tree being an unrelated data set. A data dictionary is created over one such tree. It does not allow import of annotated FMLs with multiple top-level entities. Specify the name, reference name, and element type for a data dictionary/DDE since these are required parameters. A parent DDE (composite) cannot have two children with the same name.

Data Dictionary Editor validations

The Data Dictionary Editor enforces following validations when creating or updating a data dictionary.

Only composite type is allowed as Top-level Element in a data dictionary.
Composite and Collection elements are not allowed at leaf level. Only Primitive (String, Date, Number, Boolean) elements are allowed at leaf level. This validation ensures that there is no composite and collection element without a child DDE.
While importing XSD to create a data dictionary, the Data Dictionary Editor Prompts for a top-level element, if multiple exist, to create the data dictionary.
While importing a generic FML/LiveCycle data model to create a data dictionary, the Data Dictionary Editor Prompts for a top-level element, if multiple entities exist, to create the data dictionary.
Does not allow import of annotated FMLs with multiple top-level entities.
The name is the only required parameter for a data dictionary.
A parent DDE (composite) can't have two children with the same name
Ensures a DDE is marked computed, only if it is not a required parameter. A required element cannot be computed and a computed element cannot be required. Also, Collection and Composite Element cannot be computed elements.
Ensures a DDE is marked required, only when it is not computed. It also ensures that it is not the "collectionElement" denoting the type of Collection (that is the only children of a collection Element).
Empty keys or Duplicate keys are not allowed in extendedProperties for a data dictionary or DDE.
Do not use the colon(:) or vertical bar(|) characters within the key or value of an extended property. There is no validation for the use of these prohibited characters.

Validations that are applied at the Data Dictionary Level

The Data Dictionary name must not be null.
The Data Dictionary name must only contain alphanumeric characters.
The child element list in the Data Dictionary must not be null or empty.
The Data Dictionary must not contain more than one top-level Data Dictionary Element.
Only composite type is allowed as Top-level Element in a Data Dictionary.

Validations that are applied at the Data Dictionary Element Level

All DDE names must not be null.
All DDEs must have a "not null/non null" element type.
All DDE reference names must not be null.
All DDE reference names must be unique.
All DDE reference must only contain alphanumeric characters and “_”.
All DDE display names must only contain alphanumeric characters and “_”.
Composite and Collection elements are not allowed at leaf level. Only Primitive (String, Date, Number, Boolean) elements are allowed at leaf level. This validation ensures that there is no composite and collection element without a child DDE.
A composite parent DDE must not have two child elements with the same name.
The ENUM subtype is only used for String and Number elements.
Collection and Composite elements cannot be computed.
A DDE cannot be both computed and required.
Computed DDEs must contain a valid expression.
Computed DDEs must not have XML binding.
A DDE that denotes the type for a Collection DDE cannot be computed or required.
DDEs of subtype ENUM must not contain null or empty value sets.
The XML binding of a collection DDE must not map to an attribute.
The XML binding syntax must be valid, such as, only one @ appears, the @ is only allowed when followed by an attribute name, and so on.

Data Dictionary Editor Definition Panel

The Data Dictionary Editor Definition Panel is the user interface for creating DDEs which is displayed in a tree format. The Data Dictionary Structure panel displays the list of the DDEs. The Field and Variable List panel displays the list of properties associated to the selected DDE. A data element can also be entered by right-clicking an element.

View full size graphic

Data Elements Panel

Data Dictionary Services

The Data Dictionary building block services are exposed as OSGi services. Following is the list of services that are provided in Data Dictionary building block:

Name

Description

DataDictonaryRegistryService

Provides operations creating, retrieving, updating, and deleting (CRUD operations) for a data dictionary.

DataDictionaryUtilService

Provides data dictionary utility functions to:

Import an XSD to create a data dictionary.
Import/export of a data dictionary as annotated FML.
Import a generic FML (LiveCycle data model) to create a data dictionary.
Create a data dictionary object from XSD/FML. The data dictionary object can then be persisted through the APIs in the DataDictionaryRegistryService.
Create sample xml data.
Serialize DDI to XML
Create DDI from XML/Java Object

Default endpoints

The Data Dictionary building block services are exposed by default over Flex remoting and Spring HTTP.

Dependence of the Data Dictionary building block on Expression Evaluator Service (EXM)

The Expression evaluator (EXM) service is exposed as a building block. The Data Dictionary building block is dependent on the EXM, which is a pluggable component. The Expression evaluator supports JSP EL evaluation. The expression evaluator service is used for evaluating computed DDEs for the data dictionary. The following points detail the DDE evaluation capabilities that the Data Dictionary building block supports using the EXM.

A DDE can be marked as Computed and the corresponding JSP EL expression can be provided for it through the Data Dictionary Editor user interface.
The computing expression for a DDE can be based on the values of other DDEs. For example, a DDE with name 'fullName' can bear an expression - ${firstName}$ {lastName} which evaluates full name as concatenation of first and last name.

Note: "firstName" and "lastName" are the reference names of respective DDEs.
The Data Dictionary building block does not support nesting of computed expressions. An operand in the expression cannot be another computed expression. The computed DDE evaluation is done on the server side when a DDI is being created.
The computed DDEs are created as non-Required, which means null values are permitted in a DDI.

Data Dictionary runtime workflow

The Data Dictionary runtime is responsible for returning the data dictionary instances (DDI) corresponding to a data dictionary. The Data Dictionary runtime supports creation of DDI from Input XML Data only. The solution has an initiating input XML data file that is used to run off its processes. For example, a letter generation process that is triggered with an input XML file containing all the relevant details. The input XML data must confirm to the schema of the XSD from which a data dictionary was created.

If a data dictionary was created manually, there would not have been any default XSD schema. When a data dictionary is created from an XSD schema, the import was modified, it's possible for its structure to decouple with the starting XSD schema. To prevent these errors, the Data Dictionary building block provides a tool to generate a sample XML corresponding to the data dictionary. The driving system ensures that input XML data is provided to the system in the format consistent with the sample XML. The Data Dictionary runtime creates a DDI out of the input XML based on a given data dictionary reference. The DDI can then be used to fill in the values in the application. There is no support of writing back data dictionary instances in the system. However, a data dictionary instance can be serialized and passed around in the workflows.

End-to-end flow definition

The following diagram details the end-to-end data dictionary definition. It includes the integration process including the personas involved, tools used, metadata storage, and its access at runtime:

View full size graphic

Data dictionary definition

The Business Process Owner can use the Data Dictionary Editor to create a data dictionary manually. For information on creating the data dictionary using the Data Dictionary Editor, see Creating a data dictionary.
The Business Process Owner can also use the Data Dictionary Editor to create data dictionary by importing a schema.
On saving the data dictionary, the data dictionary metadata definition gets stored in the back-end that is, in the content repository.
The business process owner can export the data dictionary using the Data Dictionary Editor, in form of an annotated FML model. This annotated model can then be imported to create a data dictionary.
A developer can use the domain XSD to create both the data dictionary and the artifacts such as the forms for the application. Designer can be used for importing an XSD and creating relevant forms from it.
The Solution Developer creates the solution in terms of artifacts, such as forms required by the application, corresponding Java classes, Flex components, and so on.
The Solution Developer assembles them into a deployable archive. The solution is then deployed. The solution can be tested with sample data dictionary XML generation capability exposed through the Data Dictionary Editor.
The deployed customer solution accesses both the Data Dictionary metadata and Data Dictionary runtime to accomplish its flows. For example, a document composer application accesses a letter data dictionary to render the required fields.
The Data Dictionary runtime accesses the Data Dictionary metadata to create the Data Dictionary Instances (DDI). For more information on the Data Dictionary runtime, see Data Dictionary runtime workflow.
The Data Dictionary runtime does not integrate directly with back-end legacy systems.

Mapping Data Dictionary Elements to XML schema

The Data Dictionary building block permits data dictionary creation from an XML Schema or directly from the Data Dictionary user interface. All the Data Dictionary Elements (DDEs) within a data dictionary have an XML Binding field to store the binding of the DDE to an element in the XML schema. The binding in each DDE is relative to the parent DDE.

The following details sample models and code samples which show implementation details for the Data Dictionary building block.

Mapping Simple (Primitive) Elements

A primitive DDE represents a field or attribute which is atomic in nature. Primitive DDEs defined outside the scope of a complex type (composite DDE) or a repeating element (collection DDE) can be stored in any location within the XML Schema. The location of the data corresponding to a primitive DDE is not dependent on the mapping of its parent DDE. Primitive DDE uses the mapping information from the XML Binding field to determine its value and the mappings translate into one of the following:

an attribute
an element
a text context
nothing (an ignored DDE)

The following example shows a simple schema.

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
  <xs:element name='age' type='integer'/> 
  <xs:element name='price' type='decimal'/> 
</xs:schema>

Data Dictionary Element	Default XML Binding
age	/age
price	/price

Mapping Composite Elements

Binding is not supported for Composite elements, if binding is provided, it is ignored. The binding for all the constituent child DDEs of primitive type, must be absolute. Allowing absolute mapping for child elements of a composite DDE provides more flexibility in terms of XPath Binding. Mapping a composite DDE to a complex type element in XML schema limits the scope of binding for its child elements.

The following example shows the schema for a note.

<xs:element name="note"> 
    <xs:complexType> 
        <xs:sequence> 
            <xs:element name="to" type="xs:string"/> 
            <xs:element name="from" type="xs:string"/> 
            <xs:element name="heading" type="xs:string"/> 
            <xs:element name="body" type="xs:string"/> 
        </xs:sequence> 
    </xs:complexType> 
</xs:element>

Data Dictionary Element	Default XML Binding
note	empty(null)
to	/note/to
from	/note/from
heading	/note/heading
body	/note/body

Mapping Collection Elements

A collection element is only mapped to another collection element which has cardinality > 1. The child DDEs of a collection DDE have relative(local) XML Binding with respect to its parent's XML Binding. Since the child DDEs of a collection element must have the same cardinality as that of parent, the relative binding is mandated to ensure the cardinality constraint so that the child DDEs do not point to a non-repeating XML Schema element. In the example below, the cardinality of "TokenID" must be same as "Tokens" which is its parent collection DDE.

When mapping a collection DDE to an XML Schema element:

the binding for the DDE corresponding to Collection element must be the absolute XPath
Provide no binding for the DDE representing the type of Collection element. If provided, the binding would be ignored.
The binding for all the child DDEs of Collection element must be relative to the parent Collection element.

The XML Schema below declares an element with the name Tokens and a maxOccurs attribute of “unbounded”. Thus, Tokens is a collection element.

<?xml version="1.0" encoding="utf-8"?> 
<Root> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
  <Tokens> 
    <TokenID>string</TokenID> 
    <TokenText> 
      <TextHeading>string</TextHeading> 
      <TextBody>string</TextBody> 
    </TokenText> 
  </Tokens> 
</Root>

The Token.xsd associated to this sample would be:

<xs:element name="Root"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="Tokens" type="TokenType" maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 
  
<xs:complexType name="TokenType"> 
  <xs:sequence> 
    <xs:element name="TokenID" type="xs:string"/> 
    <xs:element name="TokenText"> 
      <xs:complexType> 
        <xs:sequence> 
          <xs:element name="TextHeading" type="xs:string"/> 
          <xs:element name="TextBody" type="xs:string"/> 
        </xs:sequence> 
      </xs:complexType> 
    </xs:element> 
  </xs:sequence> 
</xs:complexType>

Data Dictionary Element	Default XML Binding
Root	empty(null)
Tokens	/Root/Tokens
Composite	empty(null)
TokenID	TokenID
TokenText	empty(null)
TokenHeading	TokenText/TextHeading
TokenBody	TokenText/TextBody

Samples

The following details code samples which show implementation details for the Data Dictionary building block.

Sample Schema that can be imported into the Data Dictionary

The following example shows the schema for a company.

<?xml version="1.0" encoding="utf-8"?> 
<xs:schema xmlns="DCT" targetNamespace="DCT" xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"> 
  <xs:element name="Company"> 
    <xs:complexType> 
      <xs:sequence> 
        <xs:element name="Name" type="xs:string"/> 
        <xs:element name="Type" type="xs:anySimpleType"/> 
        <xs:element name="HeadOfficeAddress" type="Address"/> 
        <xs:element name="SalesOfficeAddress" type="Address" minOccurs="0"/> 
        <xs:element name="HeadCount" type="xs:integer"/> 
        <xs:element name="CEO" type="Employee"/> 
        <xs:element name="Workers" type="Employee" maxOccurs="unbounded"/> 
      </xs:sequence> 
    </xs:complexType> 
  </xs:element> 
  <xs:complexType name="Employee"> 
    <xs:complexContent> 
      <xs:extension  base="Person"> 
        <xs:sequence> 
          <xs:element name="CurrAddress" type="Address"/> 
          <xs:element name="DOJ" type="xs:date"/> 
          <xs:element name="Phone" type="xs:integer"/> 
        </xs:sequence> 
      </xs:extension> 
    </xs:complexContent> 
  </xs:complexType> 
  <xs:complexType name="Person"> 
    <xs:sequence> 
      <xs:element name="PersonName" type="Name"/> 
      <xs:element name="DOB" type="xs:dateTime"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="Name"> 
    <xs:sequence> 
      <xs:element name="FirstName" type="xs:string"/> 
      <xs:element name="MiddleName" type="xs:string"/> 
      <xs:element name="LastName" type="xs:string"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="Address"> 
    <xs:sequence> 
      <xs:element name="Street" type="xs:string"/> 
      <xs:element name="City" type="xs:string"/> 
      <xs:element name="State" type="xs:string"/> 
      <xs:element name="Zip" type="xs:string"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:schema>

Sample data model

The following code example details the FML export of a Company data dictionary, the data dictionary annotations use the DDS annotation. This example also contains two annotation groups: General and XmlBinding. The description and XPath are two respective annotations which are captured as part of these two annotation groups.

<model xmlns="http://ns.adobe.com/Fiber/1.0"> 
  <annotation name="DDS"> 
    <item name="name">Company</item> 
    <item name="displayName">Company</item> 
    <item name="version">1.0</item> 
    <item name="type">NONSYSTEM</item> 
    <item name="extended_k1">v1</item> 
    <item name="extended_k2">v2</item> 
  </annotation> 
  <annotation name="General"> 
    <item name="description"/> 
  </annotation> 
  <entity name="Company"> 
    <annotation name="DDS"> 
      <item name="setAsTopLevelWithName">Company</item> 
      <item name="displayName">Company</item> 
      <item name="extended_k3">v3</item> 
      <item name="extended_k4">v4</item> 
    </annotation> 
    <annotation name="General"> 
      <item name="description"/> 
    </annotation> 
    <annotation name="XMLBinding"> 
      <item name="xpath">/Company</item> 
    </annotation> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="Name" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Name</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Name</item> 
      </annotation> 
    </property> 
    <property name="Type" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Type</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Type</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="HeadOfficeAddress" required="true" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">HeadOfficeAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/HeadOfficeAddress</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="SalesOfficeAddress" required="false" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">SalesOfficeAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/SalesOfficeAddress</item> 
      </annotation> 
    </property> 
    <property name="HeadCount" required="true" type="double"> 
      <annotation name="DDS"> 
        <item name="displayName">HeadCount</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/HeadCount</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="CEO" required="true" type="Employee"> 
      <annotation name="DDS"> 
        <item name="displayName">CEO</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/CEO</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-many" name="Workers" required="true" type="Employee[]"> 
      <annotation name="DDS"> 
        <item name="displayName">Workers</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Workers</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Address"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="Street" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Street</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Street</item> 
      </annotation> 
    </property> 
    <property name="City" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">City</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/City</item> 
      </annotation> 
    </property> 
    <property name="State" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">State</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/State</item> 
      </annotation> 
    </property> 
    <property name="Zip" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">Zip</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Zip</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Employee"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property cardinality="one-to-one" name="PersonName" required="true" type="Name"> 
      <annotation name="DDS"> 
        <item name="displayName">PersonName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/PersonName</item> 
      </annotation> 
    </property> 
    <property name="DOB" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">DOB</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/DOB</item> 
      </annotation> 
    </property> 
    <property cardinality="one-to-one" name="CurrAddress" required="true" type="Address"> 
      <annotation name="DDS"> 
        <item name="displayName">CurrAddress</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/CurrAddress</item> 
      </annotation> 
    </property> 
    <property name="DOJ" required="true" type="date"> 
      <annotation name="DDS"> 
        <item name="displayName">DOJ</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/DOJ</item> 
      </annotation> 
    </property> 
    <property name="Phone" required="true" type="double"> 
      <annotation name="DDS"> 
        <item name="displayName">Phone</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/Phone</item> 
      </annotation> 
    </property> 
  </entity> 
  <entity name="Name"> 
    <annotation name="LiveCycleES"> 
      <item name="generate_type">true</item> 
    </annotation> 
    <property name="FirstName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">FirstName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/FirstName</item> 
      </annotation> 
    </property> 
    <property name="MiddleName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">MiddleName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/MiddleName</item> 
      </annotation> 
    </property> 
    <property name="LastName" required="true" type="string"> 
      <annotation name="DDS"> 
        <item name="displayName">LastName</item> 
      </annotation> 
      <annotation name="General"> 
        <item name="description"/> 
      </annotation> 
      <annotation name="XMLBinding"> 
        <item name="xpath">/LastName</item> 
      </annotation> 
    </property> 
  </entity> 
</model>

Start data dictionary through the Flex client

To use this sample, add adobe-dct-flex-services.swc to your Flex project's classpath.

Get the singleton instance of data dictionary service.

 DataDictionaryUtilServiceImpl ddUtilService = DataDictionaryUtilServiceImpl.getInstance();

Start the data dictionary Util Service, and pass the data dictionary Id as parameter to export a data dictionary as annotated FML.

/** 
 *  Exporting Data Dictionary 
 */ 
private function exportAsFML(event:*):void 
{ 
  var ddId:String = //The id of an existing data dictionary. 
  ddUtilService.exportDataDictionaryAsFML(ddId, handleSuccess, handleFault); 
} 
/* Success Handler */ 
private function handleSuccess(event:DCTServiceEvent):void 
{ 
   var ddFML:String = event.data as String;         
} 
/* Fault Handler */ 
private function handleFaultevent:FaultEvent):void 
{ 
   trace("Error exporting DataDictionary"+ (event.message as ErrorMessage).faultCode );                  
}