XML Application 6.5 Development Guide

EMC® Documentum®
XML Applications
Version 6.5
Development Guide
P/N 300007228 A01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright © 2003 ‑ 2008 EMC Corporation. All rights reserved.
Published July 2008
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS
OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY
DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up‑to‑date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Table of Contents
Preface ........................................................................................................................... 9
Chapter 1 Introduction ........................................................................................... 11

What’s new for XML applications for Documentum 6.5 ................................. 11
XML applications overview ......................................................................... 12
How XML applications work....................................................................... 13
XML application architecture .................................................................. 13
XML application functionality ................................................................. 15
Documentum product support for XML applications .................................... 17
Chapter 2 Determining Requirements for Creating an XML Application ................ 19

Determining configuration requirements for the XML application ................. 19
DTD and schema management ................................................................ 20
Determining document chunking ............................................................ 21
Determining storage location................................................................... 21
Determining object types ........................................................................ 21
Determining repository properties ........................................................... 22
Determining ACLs ................................................................................. 22
Determining a document lifecycle............................................................ 23
Validating against the data dictionary ...................................................... 23
Best practices in XML content management .............................................. 23
Map chunked element name to a repository property ........................... 24
Map distinguishing content to repository properties ............................. 24
Empty content should not be chunked ................................................. 24
Repository constructs should reflect content ......................................... 24
Apply document lifecycles to manage content ...................................... 24
Use workflows to process content ........................................................ 24
Improve performance by downloading fewer supporting
documents ......................................................................................... 25
Prohibiting download of application support documents .................. 25
External reference patching with repository paths ............................ 26
Conducting a requirements analysis ............................................................ 26
Business process analysis ........................................................................ 27
Content authoring, entry, update and reuse .......................................... 27
Content review and approval .............................................................. 27
Content translation and localization ..................................................... 28
Content publishing ............................................................................. 28
Content archiving and end‑of‑life ........................................................ 28
Data model analysis................................................................................ 29
Data model scope ............................................................................... 29
Data model descriptiveness ................................................................. 30
Data model hierarchy and reuse .......................................................... 30
Data model categorization content ....................................................... 30
Data model rigor ................................................................................ 30
Legacy content analysis........................................................................... 31
Content management and repository design ............................................ 31
EMC Documentum XML Application Version 6.5 Development Guide 3

Table of Contents
Chapter 3 Creating the XML Application ................................................................ 33

Setting the oldest_client_version property on the Content Server ................... 33
Preparing to create the XML application ...................................................... 33
Overview of the components that make up an XML application ................ 34
Checklist of the files and information you need to create an
XML application ..................................................................................... 34
Creating repository object types .............................................................. 36
Adding Documentum attributes to DTDs and schemas ............................. 37
Adding Documentum attributes to a DTD ............................................ 37
Adding Documentum attributes to schemas ......................................... 39
Option 1......................................................................................... 39
Option 2......................................................................................... 39
Option 3......................................................................................... 39
Option 4......................................................................................... 40
Modifying path names for external parameter entity declarations .............. 41
Creating the XML application...................................................................... 41
Creating an XML application using Webtop ............................................. 42
Create the XML application folder ....................................................... 42
Setting the application folder’s properties and permissions ................... 42
Creating the application support documents folder............................... 43
Creating folders for non‑download supporting documents ................... 43
Importing the XML application configuration file ................................. 44
Importing a DTD ................................................................................ 44
Importing a schema ............................................................................ 44
Importing supporting documents ........................................................ 45
Testing and troubleshooting the XML application ......................................... 46
Verifying the XML application is set up correctly ...................................... 46
Testing your XML application ................................................................. 47
Troubleshooting import or checkin problems............................................ 47
Cannot import Epic document in Webtop............................................. 48
Parser looks for DTD or schema even when not validating .................... 48
Error: ʺ&xxx; is referenced but not declaredʺ ........................................ 48
Avoiding date/time format errors ........................................................ 49
XML application detection algorithm ................................................... 49
Troubleshooting export or checkout errors ............................................... 50
Parser cannot find DTD or schema after checkout ................................. 50
Distributing the XML application as a DocApp ............................................. 51
Chapter 4 The XML Application Configuration File ................................................ 53

Creating an XML application configuration file ............................................ 53
Anatomy of an XML application configuration file ....................................... 54
The configuration file prolog ................................................................... 54
Application‑level settings ........................................................................ 55
Rules ..................................................................................................... 55
Rule types .......................................................................................... 56
XML Content Rule .......................................................................... 56
Link Rule ....................................................................................... 57
Non‑XML Content Rule .................................................................. 57
Entity Rule ..................................................................................... 57
Task‑based classifications of rule elements ............................................... 57
Elements that interact with repository objects ....................................... 58
Elements that fine‑tune the rules.......................................................... 58
Overview of some rule features ............................................................... 59
Triggering a rule with <element_selection_pattern> .............................. 59
Rules and rule ordering ...................................................................... 60
Using variables to extract information from the XML document ............ 60
4 EMC Documentum XML Application Version 6.5 Development Guide

Table of Contents
Alias support ..................................................................................... 61

Constructing DRLs ............................................................................. 61
Syntax ........................................................................................... 61
Object specification ......................................................................... 61
ID value ..................................................................................... 61
Predicate .................................................................................... 62
DRL arguments .............................................................................. 62
Examples of DRLs for use in XML applications................................. 63
A simple folder DRL ................................................................... 63
A folder DRL with a query .......................................................... 63
A document DRL for the CURRENT version ................................ 64
A document DRL for a specific version number ............................ 64
Chapter 5 Queries .................................................................................................. 67

Queries with DQL ...................................................................................... 67
Queries for metadata .............................................................................. 68
DQL Clause for virtual document queries ............................................ 68
Finding paths ..................................................................................... 69
Finding links ...................................................................................... 69
Full‑text searches .................................................................................... 69
Zone searches ......................................................................................... 70
Queries with XDQL .................................................................................... 71
Queries with XQuery .................................................................................. 71
XQuery .................................................................................................. 71
Xquery Restrictions ................................................................................ 73
DFC XQuery interface ............................................................................. 73
Example using readResults() ............................................................... 75
Invoking DQL query from XQuery: Documentum Extension
function local:dql() ............................................................................. 76
iAPI interface ......................................................................................... 77
Chapter 6 Transformations .................................................................................... 79

Overview ................................................................................................... 79
Transformation support in DFC ................................................................... 80
Special considerations for XML transform operations................................ 82
Summary of using XSLT stylesheets to build documents dynamically ............ 82
Passing and using parameters in the stylesheet ......................................... 84
The NewsML XSLT stylesheet ..................................................................... 85
Appendix A Reference Information and Examples for Config_6.5.dtd ...................... 93

XML source notation .................................................................................. 93
Symbols ................................................................................................. 93
Attribute notation ................................................................................... 94
Internal parameter entities .......................................................................... 94
Elements declared in config_6.5.dtd ............................................................. 96
Appendix B Documentum Attributes ...................................................................... 229

Appendix C Resources at the Documentum Developer Site ................................... 233
Appendix D Sample XML Application Configuration File for NewsML .................... 235
Breakdown of the NewsML application configuration file ........................... 237
Naming the application ........................................................................ 237
Specifying which XML application applies to documents ........................ 237

Table of Contents
Chunking rule for <NewsML> ............................................................... 238

Chunking rule for <NewsItem> ............................................................. 238
Chunking rule for <NewsComponent>................................................... 243
XML content rule for <ContentItem> ...................................................... 251
Link rule .............................................................................................. 252
Appendix E Source Files for NewsML Sample ........................................................ 255

The NewsML DTD ................................................................................... 255
XML application configuration file for NewsML ......................................... 289
XML document to produce NewsML newsletter ......................................... 297
The NewsML XSLT stylesheet ................................................................... 298
Appendix F Source for Cell Phone Catalog Sample ............................................... 303

Cell phone catalog XML application configuration file ................................ 303
Cell phone catalog sample document ......................................................... 307
Cell phone catalog DTD ............................................................................ 321
Appendix G Sample Configuration File for a DocBook DTD ................................... 325

Overview of sample configuration file ....................................................... 325
Description of sample configuration file ..................................................... 327
Defining the XML application and application pattern ............................ 328
Setting rules ......................................................................................... 328
Defining the chunk level ....................................................................... 328
Defining variables ................................................................................ 329
Specifying the location and object name ................................................. 330
Specifying the object name .................................................................... 330
Specifying the type and attribute values ................................................. 330
Creating the chunk ............................................................................... 331
Chunking external graphics files............................................................ 331
Sample configuration file .......................................................................... 332

Table of Contents
List of Figures
Figure 1. XML application architecture .......................................................................... 14

Figure 2. Folder hierarchy defined by sample configuration file ..................................... 326

Table of Contents
List of Tables
Table 1. Checklist for creating an XML application ........................................................ 35

Table 2. Documentum attributes .................................................................................. 37
Table 3. Application detection based on XML document information ............................. 49
Table 4. Elements related to the XML application .......................................................... 55
Table 5. Elements that interact with repository objects ................................................... 58
Table 6. Elements that fine‑tune the rules...................................................................... 59
Table 7. Text entity references ...................................................................................... 62
Table 8. DRL arguments applicable to XML applications ............................................... 63
Table 9. Valid symbols in document type definitions (DTDs) ......................................... 93
Table 10. Content of <element_selection_pattern> ......................................................... 139
Table 11. How linked files are handled......................................................................... 156
Table 12. Documentum attributes for XML documents .................................................. 229
Table 13. NewsML elements to be chunked .................................................................. 236
Table 14. Variables declared for <NewsItem> ................................................................ 239
Table 15. Property values assigned to NewsItem chunk................................................. 240
Table 16. Variables declared for <NewsComponent> ..................................................... 243
Table 17. Property values assigned to NewsComponent chunk ...................................... 245
Table 18. Chunked XML source file elements................................................................ 326

Preface
This manual applies to XML applications that will run on client applications that use Documentum
Foundation Classes (DFC) 6.5. The manual describes how to create and use Documentum XML
applications to chunk and store XML documents in a Documentum repository, and how to publish
chunks of XML content from a repository.
This manual is written for application developers and system administrators who are implementing
XML management processes within their enterprise using Documentum.
To design, develop, and install an XML application in the repository, the following knowledge
is required:
• XML
• DTD or W3C schema
• Documentum object model and core capabilities
For publishing XML content, the following knowledge and skills may be required:
• XSL
• DQL (Documentum Query Language)

Preface

Chapter 1
Introduction
This chapter contains the following:

• What’s new for XML applications for Documentum 6.5, page 11
• XML applications overview, page 12
• How XML applications work, page 13
• Documentum product support for XML applications, page 17
What’s new for XML applications for

Documentum 6.5
This release includes the ability of Searching and retrieving XML content and
Documentum attributes through XQuery syntax using a new XQuery interface.
With XQueries, you can address any piece of information in an XML document, make
selections based on conditions, and construct new structures based query result sets.
Query results return XML documents or byte streams that adheres to Documentum
security.
This release adds a new extension function, that can be invoked through XQuery, which
returns DQL query results as an XML document. Using XQuery, you can join data (from
the relational database) returned by DQL queries with the data or metadata extracted
from the XML store.
XQuery (XML Query Language) is a XML standard. For more information on XQuery,
see http://www.w3.org/TR/xquery/.
The XQuery interface can be accessed through DFC and iAPI.
The following illustrates a couple common use cases:
• Search use case – find all documents that contain a particular XML tag and one
or more Documentum attribute values.

Introduction
• Constrained query use case – find a document or set of documents based on a

Documentum attribute value (such as project name or folder path).
• Metadata results use case: construct a result document by comprised of content from
a set of XML documents that matches the search criteria, and include Documentum
attribute values associates with those XML documents in the constructed document.
XML applications overview

An XML application customizes and automates how XML objects and linked entities
are stored in a repository. An XML application can control how XML documents are
imported, checked in, exported, and checked out. It can set permissions, set a binding
rule, or attach lifecycles. It can assign metadata to repository objects based on information
extracted from the XML, external variables, or expressions set by custom Java code.
You create an XML application within a repository. You create one or more XML
applications in a given repository.
An XML application can reuse content in more than one document or publish content
to more than one location. An XML application can automate the processing of XML
content using features available in the standard Documentum content management
system, such as source control, metadata, document lifecycles, workflows, and security.
XML applications can be configured to automatically recognize different types of XML
documents and set up rules to determine where they are to be stored, whether they
should be divided into smaller chunks, how to extract and assign metadata to an object
in the repository, what level of security to assign, whether to attach a document lifecycle,
and so on. On import or checkin, the XML content is automatically processed according
to these rules. These automated procedures help to increase efficiency and reduce error
in XML content management.
XML documents can also be generated from XML content using XDQL/XSLT. This is
especially useful when the structure is fixed but the content frequently changes, such
as for Web pages.
In a prototypical XML application that chunks XML content, the following is the
behavior that a repository user might expect to see when checking documents in and
out of a repository:
• After importing or checking in a single XML document, a user sees the document
represented in the repository as a virtual document, with a treelike structure
showing the XML container as the root and any objects that were chunked by the
XML application as child components.
• When a user checks out this document, the document is reassembled into a single
document in the user’s checkout directory.

Introduction
• Upon checkin, the document is once again chunked (accounting for any changes to
the document) and appears again as a virtual document in the repository.
• If the DTD or W3C Schema is managed by the XML application, the user does not
have to worry about associating a checked‑out document with a DTD or W3C
Schema, since it will download to the user’s system along with the document, and
the document’s declaration will be patched to point to that location.
• Users can share XML content by viewing or checking out the chunks or linked files
(such as a graphic) they want to share and copying them into their documents, or by
using one of the Documentum integrations with Arbortext Epic or Corel XMetal.
Upon import or checkin of the document, the content is automatically shared.
XML applications store chunked XML documents as virtual documents in the repository,
which offer the following advantages:
• Users can check out either an entire XML document or individual virtual document
components (corresponding to chunked XML objects).
• Individual components of virtual documents can be linked to other locations or
shared by other virtual documents. Content updated once appears everywhere.
• Components in the same virtual document can have different permissions and
metadata.
• You can attach a document lifecycle to a virtual document or any of its components.
• An entire virtual document or any individual component can be inserted as a
package in a workflow.
• If you do not want content of a component to be updated in a particular virtual
document, you can set a binding rule, which controls the version of the component
that is used within that virtual document.
For more technical information about virtual documents, see Documentum Content Server
Fundamentals Guide.
How XML applications work

XML applications are stored on the server but controlled by Documentum Foundation
Classes (DFC) accessed through a client application, and processed on the client host, as
the following sections describe in more detail.
XML application architecture

XML applications have interrelationships with a number of Documentum components,
as shown in Figure 1, page 14.

Introduction
Figure 1. XML application architecture
The XML application itself consists of the following:

• A folder of object type dm_xml_application, which can be created in any location
in a repository, but usually is installed into the System\Applications folder. XML
applications created by Documentum Application Builder (DAB) are always
installed to this folder.
• A configuration file of type dm_xml_config. The functionality available through the
XML application configuration file is controlled by the version of the Documentum
configuration DTD that you use.
• A folder called Application Support Documents, which can contain any documents
intended for download to local systems along with the DTD or W3C Schema. This
can include files such as CSS, FOSI, and stylesheets.
• A folder called XML Sample Documents, which will open in the XML Configuration
Editor that is supplied with DAB.
• Any other folders that you choose to create manually in order to store associated files
that will not be downloaded to local system.
Documentum Foundation Classes (DFC) provide API functionality to the Content Server
and do the actual processing associated with an XML application. Webtop is installed
with DFC on an application server and accessed with a client browser. In this case,
processing through XML applications occurs mainly through the DFC installed on the
application server machine.
Most of the XML application functionality is determined by the client or application
server DFC version.

Introduction
Documentum clients have differing capabilities to perform operations associated with

virtual documents. For example, you must use Virtual Document Manager to manually
create assemblies or set binding rules.
Although your XML application configuration file and the Documentum XML
configuration DTD that validates it reside on the Content Server, which version of the
XML application configuration DTD you use is determined by the oldest version of DFC
installed on any client that will process documents through the XML application. (The
version of DFC on the client is controlled by which version of the client is installed.)
XML application functionality

When an XML document or chunk is imported into the repository, a process takes
place that detects applicable XML applications, based on properties specified for
dm_xml_application folders. If no custom XML application is detected, Documentum’s
Default XML Application will be applied. It is also possible to use a processing
instruction in the XML document to specify which XML application should apply or to
instruct that the document should not be imported through any XML application.
Note: If you insert a processing instruction in the document prolog to ignore the XML
application (<?dctm xml_app=ʺignoreʺ?>), DFC will still invoke the Xerces parser, which
will parse up to the point of the processing instruction.
If you import an XML document and if your XML application manages your DTD or
W3C schema, Webtop does not download the DTD or schema. The DTD/schema needs
to be managed in the repository or accessible on the file system for import operations.
(URLs are not supported in this release.)
When a document is checked out or exported from the repository, the XML application
applies automatically. If a root document has descendants and the descendants are also
checked out, the chunks are integrated with the root into a single XML document, which
is placed in the user’s local checkout directory. If the DTD or schema associated with the
XML document is managed by the XML application, the DTD or schema is downloaded
to the local system and the XML document is patched to point to that location.
On checkout or when viewing an XML document, Documentum attributes are added
to each chunk. These attributes contain information about the object ID of that chunk,
whether the chunk is read‑only or editable, and what binding rule if any is set on
that chunk. You need to modify your DTD or schema to declare these Documentum
attributes. For more information, see Appendix B, Documentum Attributes.
Exported documents do not contain Documentum attributes. However, if Documentum
is managing your DTD or schema, it will be downloaded to the same location as the
exported document, and the XML document will be patched to point to that location.

Introduction
During checkin, the XML application applies and rechunks the document according
to the rules in the XML application configuration file. However, the Documentum
attributes override any configuration file settings. Chunks marked read‑only by the
Documentum attributes are not checked in. Chunks are checked in to the same location
from where they were checked out, even if the configuration file specifies a different
location for that chunk. Any binding rules set in a Documentum attribute will override
any binding rules set in the configuration file.
Note: Application support documents and the DTD or W3C schema are downloaded
only for export and checkout.
The concepts of import and checkin become blurred when you work with XML
documents that contain a mixture of checked‑out and new chunks. For example,
suppose you check out an entire document and add a new element that has an associated
chunking rule in the XML application. When the document is checked in and rechunked,
the new chunks, identified by the fact that they have no Documentum attributes, will
be imported. The checked‑out chunks will be checked in, as long as they were marked
editable in the Documentum attributes. Any chunks that were marked read‑only will
be discarded. If you use an editor that makes use of a Documentum integration, such
as Arbortext Epic or Corel XMetal, any chunks marked with a read‑only Documentum
attribute will not be editable.
Cancel checkout does not read the content of an XML document and thus ignores the
information in the Documentum attributes, so cancelling checkout of an entire document
will cancel the checkout for every single component of the virtual document.
Note: If any of the chunks were previously checked out to the same user, either alone
or as part of another document, checkout will be cancelled for those chunks also.
Superusers performing a cancel checkout will break all locks on chunks, even those
checked out to other users.
If validation is turned on in the XML application (see <validation>, page 211), the
document is validated during all inbound operations, unless the XML application
configuration file allows work in progress (through use of the <work_in_progress>
element) or unless a processing instruction is used to ignore the XML application entirely
(<?dctm xml_app=ʺignoreʺ?>).
On the output side, you can return XML data through the use of XDQL. You can use XSLT
stylesheets to run XDQL queries and transform the resulting content to another format
such as HTML or plain text. For more information, see Chapter 6, Transformations.

Introduction
Documentum product support for XML

applications
The Documentum products support XML content management. This list is not
comprehensive:
• Content Server and Documentum Foundation Classes
The Documentum Content Server provides the infrastructure that implements XML
application functionality, and Documentum Foundation Classes (DFC) expose
this functionality through the API. XML applications can be used through a
Documentum client such as Webtop or a custom DFC‑based or Web Development
Kit (WDK) application.
On the production side, Documentum Content Server and DFC provide DQL, zone
searching, and XDQL as ways to query XML documents (see Chapter 5, Queries),
Queries can be embedded in XSLT stylesheets (see Chapter 6, Transformations).
For more information about DFC, refer to the DFC documentation and the DFC
Javadocs.
• Web Development Kit (WDK)
Web Development Kit is a tool that allows the development of customized Web‑based
applications. It exposes the full range of XML functionality that is provided by DFC.
• Documentum Application Builder
Documentum Application Builder (DAB) provides tools for creating Content Server
applications in repositories and packaging them into DocApps that can then be
easily deployed from one repository to another. This application can be used to
assist with the creation and maintenance of XML applications.
• Webtop
Webtop is a Web‑based client that is built on the Web Development Kit (WDK),
which allows end users to interact with the repository. XML applications can be
set up through Webtop, and Webtop makes full use of XML applications for XML
content transfer between the repository and a local system. Webtop also allows users
to view XML documents in a virtual document structure.
• Web Publisher Editor can be used to author content with a customized user interface,
thereby allowing users to create content without any knowledge of the underlying
XML or schema. Editing is customized with an XML content template plus a Rules
file.

Introduction
In addition, there are third‑party integrations with Documentum’s XML functionality,

including Corel XMetal and Arbortext Epic, which allow users to interact with the
repository through the application.

Chapter 2
Determining Requirements for Creating
an XML Application
A successful implementation of an XML application is dependent upon a full understanding of

the XML content to be managed and the business processes to be performed for that content.
Fundamentally, a successful solution is built upon out‑of‑the‑box and configurable features, reusable
constructs, and uniform business processes that are refined based upon properties exposed from
the managed content.
The chapter contains the following:
• Determining configuration requirements for the XML application, page 19
• Conducting a requirements analysis, page 26
The first section provides more information about the types of detailed decisions you must make
before you begin to construct an XML application. The second section provides an overview of the
types of requirements analyses that will be helpful in creating a successful application.
Determining configuration requirements for the

XML application
You must make several decisions before you create an XML application. These decisions
include:
• Whether to have the XML application manage the DTD or schema
• Whether to save the entire document as an object or chunk it into smaller objects and
store it as a virtual document
• If chunking, which elements to chunk
• What object type to apply to each new object
• Where in the repository to store the chunked objects
• Whether to assign values to any repository properties for the new objects

Determining Requirements for Creating an XML Application
• What ACL to assign to each object created by the application

• Whether to attach any of the objects to a document lifecycle and, if so, which
document lifecycle
• Whether to validate the objects derived from the document against the data
dictionary
All of these decisions affect what rules you include in the configuration file for your
application. The following sections provide some guidelines for making these decisions.
For more information on how to implement these decisions within the XML application
configuration file, see Chapter 4, The XML Application Configuration File.
DTD and schema management

It is a best practice in the XML community to use a DTD or schema to create valid, not
just well‑formed, XML documents. It is also a best practice to let a Documentum XML
application manage your DTD or schema.
DTD/schema management eliminates the need to maintain DTDs or W3C schemas on
local systems. The XML application downloads the DTD or schema to the local system
and patches the XML document to point to the download location. If the DTD has
parameter entities or the schema has included member files, these are also downloaded.
The default location for download of the DTD or schema and their members is
C:\Documentum\XML Applications\repository_name\XML_application_name. For
DTDs, this path is added to the system ID of the XML document; for schemas, the path
is added to the URI in the xsi:SchemaLocation or xsi:noNamespaceSchemaLocation
attribute in the root element.
DTD/schema download occurs for outbound operations in Webtop.
Note: In Webtop, the DTD must exist on the local system in order to import the
document successfully. Even if the XML application configuration file is not configured
for validation, the Xerces parser looks for the existence of the DTD or schema when it
checks for well formedness during inbound operations.
A second advantage of DTD/schema management is the option to validate XML
documents against the DTD or schema on inbound operations. Validation is turned on
when the <validation/> element appears in the XML application configuration file.
A third advantage of DTD/schema management is that the DTD or schema name
becomes a factor in determining which XML application should be applied when an
XML document is imported, a process known as application detection. In order to
activate DTD/schema management, custom properties are set on the XML application
folder in the repository. This includes a system identifier and public identifier for DTDs,
or a schema file name. These properties are also used in application detection.

Determining document chunking

Two advantages of managing XML content in Documentum are the ability to retain
XML content in configurable chunks for reuse and the enforcement of distinct business
processes on specific parts of the XML content. Documentum XML applications can be
configured to chunk on any element tag in the document. You can also define a context
for the elements that will trigger a chunking rule: only in a particular hierarchical
structure, only with a particular attribute value, or only when it is the nth occurrence of
a parent element.
Documentum creates a separate repository object for content within the opening and
closing tag of any element designated in the configuration file as a chunking element.
For example, suppose you want the XML application to chunk all <Head1> elements in
an XML document. This means that all content in the document occurring within any
matched set of opening and closing <Head1> tags (<Head1> ‑ </Head1>) is saved in
the repository as a single object.
Chunks are nested in the virtual document just as they are nested in the original XML
document. For example, if <sect2> elements are nested under <sect1> element in the XML
document, and you chunk both <sect1> and <sect2> elements, then the <sect2> chunks
will be nested under the <sect1> chunks in the virtual document in the repository.
The appropriate level of chunking for a particular kind of XML document depends
on your manageability and reuse requirements. Smaller chunks may increase the
opportunity for reuse but will also lead to slower performance when working with
documents.
You can also decide not to create any chunks but use the XML application to perform
other automated tasks, such as assigning repository properties to a document.
Determining storage location

You can include a rule in the configuration file to define a storage location in the
repository for the XML document or document chunks. One or more locations can be
assigned dynamically from information extracted from the XML document. You can also
use a document lifecycle to set storage locations for a document as it moves through its
promotion stages.
Determining object types

The XML application configuration file allows you to include rules to assign custom
object types to be used for the entire XML document or for individual chunks. How

many custom object types you create, and which custom properties you create for those
types, depends on your business and data models.
Determining repository properties

You can set values of repository properties for the XML document or chunks when they
are imported or checked in to the repository. The values can be hard‑coded in the XML
application configuration file, they can come from external variables, XPath expressions,
or Java classes, or they can be extracted from the following sources in the XML document:
• The content of an XML element
• A specific attribute value for an XML element
• The tag name of the XML element
• External variables, XPath expressions, or Java classes
You can extract this information from the XML document to a variable in the XML
application configuration file, then assign this variable, or a combination of text and
variables, to the repository property.
You can optionally use two‑way attributes, in which changes made to repository
properties are propagated to the XML document the next time it is checked out.
Note: The new value of the repository property is not changed in the XML document
until the document is checked out and checked in again. This may cause problems with
full‑text searches.
Determining ACLs
ACLs define which roles of users can access an object and what level of access the users
have. For any chunk that is created, you can specify a particular ACL name and domain,
or you can specify one of the Documentum default ACLs. The values can be hard‑coded
in the XML application configuration file, they can come from external variables, XPath
expressions, or Java classes, or they can be extracted from the XML document in the
same way that repository properties are assigned. You can also use a document lifecycle
to set permissions.
For information about ACLs and how they are implemented in the repository, refer
to Documentum Content Server Fundamentals Guide and the Documentum Content Server
Administration Guide.

Determining a document lifecycle

A document lifecycle, also called a business policy, is a series of states that define the
stages of life for a document or other SysObject. Business rules defined in the document
lifecycle typically determine when an object can be promoted from one state to the
next. There may be actions defined for each state that are performed on the objects that
are promoted to that state. Document lifecycles are described in detail in Documentum
Content Server Fundamentals Guide.
You can configure the XML application to attach a document lifecycle to the XML
document or any chunked object. The information about which lifecycle to attach can
be hard‑coded in the XML application configuration file, it can come from external
variables, XPath expressions, or Java classes, or it can be extracted from the XML
document in the same way that repository properties are assigned.
Validating against the data dictionary

The data dictionary is a repository of information on the Documentum Content Server
about object types and metadata. The XML application configuration file includes
a <dds_validation> element (<dds_validation>, page 129), which directs the system
to validate the objects that make up a document against the information in the data
dictionary. The objects are validated against the data dictionary when they are created
and each time they are checked in to the repository.
Since there is a performance cost associated with data dictionary validation, whenever
possible it is better to validate through the XML application configuration file and your
own DTD or schema. For example, in your DTD declaration you can restrict values on
attributes set in XML documents that will be used to populate repository properties.
For information about defining data dictionary information, refer to Documentum Content
Server Fundamentals Guide.
Best practices in XML content management

Your decisions about XML content management should depend on the requirements
analysis, described in the next section. However, the following points are some general
best practices when managing XML content.

Map chunked element name to a repository property
The chunked object must be easy to find in the repository. Creating a repository property
for the root element of each chunk will aid in search, XDQL aggregation, and publishing.
Map distinguishing content to repository properties
Content within a chunked content boundary that distinguishes the content should
be mapped to repository properties for the chunked object. Although full‑text zone
searching is possible, the best search results occur when the repository properties set for
chunks carry values that can be used in a query.
Empty content should not be chunked
The granularity of chunking directly impacts server performance and scalability. Empty
content reuse will degrade performance of all XML content management processes.
Repository constructs should reflect content
User groups, permission sets, document lifecycles, and workflows should be named and
structured to reflect the mapped properties and scope of managed XML content.
Apply document lifecycles to manage content
Because the XML documents will be stored as a set of chunked objects, it is helpful
to apply a standard document lifecycle template to uniformly update the individual
chunked objects, such as applying a version label. If possible, create a single document
lifecycle template that adapts its actions based on the mapped properties that distinguish
each chunked object. It is also safer to automate the document lifecycle (for example,
from within a workflow) rather than relying on users to promote or demote objects.
Use workflows to process content
Workflow processes encapsulate defined business processes. Approval and rejection of

workflow review and approval tasks logically result in content promotion or demotion

in a document lifecycle. The optimal workflow result is to implement as few specific

workflow templates as possible and adapt the workflow templates based upon the
mapped, distinguishing properties of the XML content.
Improve performance by downloading fewer supporting documents
The XML application has an optional Application Support Documents folder for files
related to the XML application such as schemas, FOSI, XSLT stylesheets, and modular
components of DTDs. This folder is downloaded every time an XML document is
imported, checked in, exported, or checked out. When this folder contains a large
number of files, upload and download of XML documents may become very slow,
especially over a WAN connection.
If you experience slowness, one solution is to prevent download of this folder during
checkout and export. For more information, see Prohibiting download of application
support documents, page 25. A second solution is to include only files in this folder that
are needed on local systems. Other supporting files can be put in another folder in the
XML application folder. For more information on setting up the Application Support
Documents folder and related folders for supporting files, see Chapter 3, Creating the
XML Application.
Prohibiting download of application support documents
To specify that files in the Application Support Documents folder should not be
downloaded, set the following methods to ʺfalseʺ for export and checkout operations:
IDfExportOperation:enableManageApplicationSupportDocuments(boolean flag)
IDfCheckoutOperation:enableManageApplicationSupportDocuments(boolean flag)
This can speed up performance when downloading XML documents from the repository,
especially when users have a remote connection. This will also block download of the
application support documents when viewing or exporting a PDF rendition of an XML
document.
Note:
• Setting these methods to ʺfalseʺ will prohibit download of your DTD, even if the root
DTD is contained in the XML application folder. DTDs or schemas will be patched
as the object name only, unless setXMLSystemID is used), and the caller will be
responsible for managing the DTD on the local system.
• The Application Support Documents folder will continue to download when
XML documents are imported or checked in. If this leads to unacceptably slow
performance for inbound operations, you may prefer to keep only files required by
your DTD (external parameter entity files) in that folder.

External reference patching with repository paths
In some circumstances, it is necessary to patch the XML files so that references to external
files mirror the repository path on the local system (necessary for Site Caching Services),
or the repository paths are appended to a URL. By default, when an XML document is
checked out or exported, external files are downloaded, and the references to those files
in the XML document are patched to point to the locations of those files on the user’s
local system.
The following method can be used to patch external references using the repository path:
IDfExportOperation:setBaseFolder(String cabinetFolderPath,
String linkBase)
The parameters are:

• cabinetFolderPath: The cabinet/folder path where the external references need to be
patched. For any external links in an XML virtual document, that object’s cabinet
folder path will be calculated and prepended to the object name.
• linkBase: The URL to which the repository path will be appended, to point to the
location of the external references. If no link base is provided, the external reference
will be only the repository path.
Note:
• This method only patches the references to the external files in the XML documents
when they are checked out or exported. The external files themselves must be placed
in the specified location by another application (such as Site Caching Services).
• If an object is linked to multiple folders, the path will become the first path that is
returned by the query.
The following method can be used to ignore the link base during import and checkin
operations:
IDfImportOperation:setLinkBase(String)
IDfCheckinOperation:setLinkBase(String)
Conducting a requirements analysis

Because you must make detailed decisions about what rules need to be created in the
XML application configuration file, it is important to conduct a thorough requirements
analysis before you begin working on an XML application, including analysis of the
following areas:
• Business process analysis, page 27
• Data model analysis, page 29
• Legacy content analysis, page 31

• Content management and repository design, page 31

This section outlines some of the issues to be considered when doing a requirements
analysis.
Business process analysis

A business process analysis helps you to determine requirements for a data model, or
to determine whether an existing data model is adequate. It also is the foundation for
making decisions about how a Documentum XML application should handle XML
documents.
The analysis of business process can be divided into five areas:
• Content authoring, entry, update and reuse
• Content review and approval
• Content translation and localization
• Content publishing
• Content archiving and end‑of‑life
Content authoring, entry, update and reuse
XML content may be created from scratch or updated in an authoring client, aggregated
from existing content, transformed from content in another format, or provided by
an outside vendor. This analysis should elaborate upon all means in which your
organization currently creates, modifies, generates or receives content. The analysis
should also consider whether there is a more optimal means of content acquisition.
The following should also be considered:
• How validity can be enforced on all content acquisition processes
• How user roles are defined in content acquisition processes
• How to deal with redundancy of content, created or obtained
Content review and approval
In most cases, once content has been acquired or updated it must undergo review
and approval before release. This analysis should focus on the current and desired
review and approval processes. The objective is to standardize document lifecycles and
workflows by analyzing the following areas:

• Common properties of the routed content

• The sequence of participant roles in the workflow
• The possible automation of workflow activities
• The result of approval and rejection of the workflow
• The aggregation and transformation of content required for review and approval
Patterns in the stages of a document can be automated and controlled with document
lifecycles. Patterns in the process with which a document is handled by users can
be automated and controlled with workflows. Requirements for the aggregation and
transformation of content are related to the transformations of the XML documents that
must occur for this part of the business process to run smoothly.
Content translation and localization
Efficient reuse of XML content and proper language attributing can reduce the frequency
and amount of translation and localization. This analysis should consider how content is
currently translated and localized, with the objective of defining ways in which it can be
integrated with document lifecycles and workflows. It may also have a bearing on how
information is chunked and assigned repository properties.
Content publishing
Content publishing involves creation of the final output content and exporting that
content to a publishing venue. There are many reasons for creating published content,
including the following:
• The incorporation of dynamic content (such as price)
• The amalgamation of content managed by separate departments (such as
pharmaceutical labeling)
• Subscription to published content
• The need for multiple, varying transformations of content for multiple output formats
Transformation of XDQL‑aggregated content from a repository can create consumable
content in a streamlined manner. For more information on publishing content from the
repository, see Chapter 5, Queries and Chapter 6, Transformations.
Content archiving and endoflife
Content archiving is the process of moving the XML content to secondary storage and
is part of a document’s lifecycle. Content end‑of‑life implies the business conditions in

which the content can be fully removed (both content and metadata) from the repository.
This analysis should include both existing and desired business processes.
Data model analysis

The distinguishing aspect of an XML content management solution is its dependence
upon the data models implemented to minimize customizations, improve scalability and
administration, and reduce development time, testing time and overall complexity. The
data models should reflect both content and business processes. In return, the data
model may affect business process in ways that were not considered in your business
process analysis, leading to reconsideration and revision of that model.
Note: Failure to reflect business processes in the data model is the leading cause of
difficulty and failure in implementing a simple and successful XML content management
solution.
If you wish to adapt XML to your existing (non‑XML) tools, you should carefully
compare your business model with the full potential of XML for dynamic construction,
reuse, and publishing of content, and make sure that your data model reflects this
potential. You should also consider any industry standards that should be reflected in
your data model. In some cases, you may wish to revise your business process in order
to make your content easier to share with partners and customers by using a schema that
conforms to an industry standard schema.
Your analysis of the data model should examine any existing XML schema and determine
requirements for modification. This analysis should include the following factors:
• Data model scope
• Data model hierarchy and reuse
• Data model categorization content
• Data model rigor
Data models can enforce varying degrees of validity. You should check to see
whether there are any gaps between the enforced validity of your data model and
validity that you desire to enforce in your content after implementing the XML
application.
Data model scope
The first purpose of a data model analysis is to summarize and explain the scope of
content encapsulated by your data model. This analysis should explain the data model
entities, including their content, cardinality and dependencies, and how they relate to

the business process requirements. You should use different data models to facilitate
different business practices.
Data model descriptiveness
The XML data model should reflect the purpose and meaning of the content
encapsulated. Elements and attributes should be clearly named and reflect the
components of content requiring chunking reuse, review, aggregation, transformation,
and publishing. The elements that will be chunked in your XML application must exist
in your data model.
Data model hierarchy and reuse
Common, reusable constructs and nesting of encapsulated content in the data model
assists in content transformation and content chunking. As a result, the data model
analysis should evaluate how well common constructs are reused and whether the
data model is excessively flat or nested. Whenever possible, you should use common
constructs that can be defined once and used in multiple locations. This will simply
XSL transformation that are required for content aggregation, workflow review, and
content publishing.
Data model categorization content
Many data models implement a means to categorize their content with XML elements
and/or attributes. This section of the data model analysis should summarize how all
content conforming to the data model is categorized. The objective is to gauge the
uniformity and granularity of categorization implemented by the data model, and
the cohesiveness of the XML content with its associated categorization. This analysis
has an important bearing on how metadata will be assigned to chunked XML objects
created in the repository, and which repository properties are necessary for accurately
querying XML content.
Data model rigor
Data models are free to enforce varying degrees of validity. These enforcements can
include required content, cardinality, format, enumeration, sequencing, patterns and
syntax, character length, and fixed and default values. Some enforcement is only

available when you utilize a W3C schema rather than a DTD or when you work on
a more restrictive extension of an industry standard. There is a trade‑off in enforced
validity on the input and output end. Greater enforced validity may make authoring
more difficult, or it may make the data model less flexible in accommodating new types
of content, but automating data publication becomes easier.
Legacy content analysis

If you have existing content that you wish to use with an XML application, you should
consider the following factors:
• Volume of content (raw size, file count, location, accessibility)
• Scope of existing content that has been validated against the data model that will be
used for the XML applications
• Means by which content was acquired
• Divergence of the existing XML content to your current data models
In some cases, it may take a substantial amount of effort to transform existing data to a
format that is compatible with the XML schema that are consistent with the data model
results from your requirements analysis. However, it is important that these preparatory
steps be taken before an XML application is implemented in Documentum.
Content management and repository design

Once you have a data model and have analyzed your business requirements, you can use
it to make design decisions about how your content should be managed and how your
repository should be structured. Design decisions should be made in the following areas:
• Content acquisition: import, authoring, and editing processes
• Repository design: object types, users and groups, cabinets and folders, permission
sets, document lifecycles, workflows, XML applications, and jobs added to the base
repository for the creation, review, approval, and archiving of XML content
• Publishing design: object types, users and groups, cabinets and folders, permission
sets, document lifecycles, XML applications, jobs required specifically for published
content
These decisions will in turn determine the decisions that you make about how your XML
application will be configured, as outlined at the beginning of this chapter. Detailed
information about how to create an XML application configuration file is provided in

Appendix A, Reference Information and Examples for Config_6.5.dtd, and a detailed

example of an actual XML application configuration file is presented in the next chapter.

Chapter 3
Creating the XML Application
This chapter contains the following:

• Setting the oldest_client_version property on the Content Server, page 33
• Preparing to create the XML application, page 33
• Creating the XML application, page 41
• Testing and troubleshooting the XML application, page 46
• Distributing the XML application as a DocApp, page 51
Setting the oldest_client_version property on

the Content Server
To ensure the highest performance for your XML applications: On the Content Server,
open the dm_docbase_config server object and set the oldest_client_version property
to the value ʺ5.3ʺ or to ʺ6.0ʺ . or to ʺ6.5.ʺ
Preparing to create the XML application

Before you create an XML application, there are some required and optional tasks that
you should perform, described in the following sections:
• Overview of the components that make up an XML application, page 34
• Checklist of the files and information you need to create an XML application, page 34
• Creating repository object types, page 36
• Adding Documentum attributes to DTDs and schemas, page 37
• Modifying path names for external parameter entity declarations, page 41

Overview of the components that make up an XML

application
A Documentum XML application consists of a set of folders and files that define
the processing rules for a particular kind of XML document. A Documentum XML
application consists of the following folders and files:
• A folder with the name of the XML application, (required), with properties that
are used to detect whether the XML application applies to XML documents being
transferred into and out of the repository and (optionally) to manage download of
the DTD or schema along with the XML document.
• An XML application configuration file (required), which is located in the XML
application folder and has the same name. It defines the rules for processing XML
documents during content transfer into and out of the repository. This configuration
file is validated against config_6.5.dtd, located in the Documentum Default XML
Application folder.
• A folder (optional) named Application Support Documents, containing files such as
a DTD or schema, CSS, FOSI, and stylesheets. The DTD is optionally used to validate
XML documents during content transfer operations. The contents of this folder are
downloaded to local systems when XML documents are downloaded (checkout,
export) or uploaded (import, checkin). In Webtop, these support documents are
downloaded in all the aforementioned cases except when an XML document is
imported.
• A folder (optional) named XML Sample Documents, containing XML instances of the
type that will be processed by the XML application. These sample documents can
help you modify the XML application configuration file in the XML Configuration
File Editor associated with DAB.
• Other optional folders that you create, in which you can store supporting files that
do not want to be downloaded to local systems.
Checklist of the files and information you need to create

an XML application
Table 1, page 35 describes the required and optional information and files that you need
for creating an XML application.

Table 1. Checklist for creating an XML application
Information or File Required or Optional Where to find

XML application name Required Contained in <name>
(see <name>, page 173),
nested under <application>
(see <application>, page
105) in XML application
configuration file.
XML application Required Same name as XML
configuration file application folder. See
Chapter 4, The XML
Application Configuration
File .
DTD file name (system Required if your DTD Specified in <!DOCTYPE>
identifier) is managed by an XML declaration of XML
application. For more documents to be processed
information, see DTD and by the application. See
schema management, page <sys_id>, page 199.
20.
Public identifier Required if public identifier Specified in <!DOCTYPE>
is used in XML documents declaration of XML
and DTD is managed by documents to be processed
XML application by the application. See
<pub_id>, page 193.
DTD member files Required if declared in the Declared in DTD as
DTD and DTD is managed external parameter entities
by XML application. For
more information, see
Modifying path names for
external parameter entity
declarations, page 41.
Schema file name Required if your schema Name of W3C schema, if
is managed by XML used in XML documents.
application. See <schema>, page 195.
Schema members Required if referenced Specified by the <import>
from the schema element in the schema.

Information or File Required or Optional Where to find

Root element names Required to determine All elements that can serve
which XML applications as the root element of the
will apply XML document. See the
description for <element>
in <app_pattern>, page 107.
Supporting files Required for DTD or External parameter entities
schema members if or schema members for a
managed by the XML managed DTD or schema
application; otherwise (required); any other files
optional such as CSS, FOSI, XSL
stylesheets (optional)
XML sample documents Optional XML documents in the
/System/Applications/
docapp_name/xml_app_
name/XML Sample
Documents folder in the
repository. docapp_name is
the name of the DocApp in
which the XML application
resides and xml_app_name
is the name of the XML
application.
Creating repository object types

Before you create the XML application, you should create any repository objects that
are required in your XML application configuration file. Here are some examples of
objects that you may need to create:
• Create any custom object types and custom repository properties required by the
XML application.
• For all document lifecycles specified in the XML application configuration file, make
sure that there is no other document lifecycle of the same name in the same location.
The XML application accesses document lifecycles by name rather than by object ID.
• Make sure that the document lifecycles specified in the XML application
configuration file are the originals or copies. Do not link them (links might not be
installed in target repositories).
• Make sure that all initial states specified in the XML application configuration file
exist in the corresponding document lifecycles.

• Create any additional ACLs that are used in the XML application configuration
file but do not yet exist.
• If you are validating the objects against the data dictionary, you may also need to
define data dictionary information. See Documentum Content Server Fundamentals
Guide for more information.
Adding Documentum attributes to DTDs and schemas

If the XML application configuration file has any rules of type <xml_content_rule> or
<link_rule>, then the Documentum namespace (xmlns:dctm) and the attributes in Table
2, page 37 must be declared in your DTD or schema for each element that is specified as
the target of an <xml_content_rule> or <link_rule>.
For more information on the purpose of these attributes and how they are used, see
Appendix B, Documentum Attributes.
Note: If authors will use the Arbortext Epic integration to check out documents, and
validation is turned off in your XML application configuration file you may not need to
declare the Documentum namespace or these attributes in your DTD.
Table 2. Documentum attributes
Documentum attribute Applies to elements specified in:

dctm:obj_status <xml_content_rule>
dctm:obj_id <xml_content_rule>
dctm:version_label <xml_content_rule>
dctm:link_obj_status <link_rule>
dctm:link_obj_id <link_rule>
dctm:link_version_label <link_rule>
The following two sections provide procedures for creating the required Documentum
namespace and attribute declarations in your DTD or schema.
Adding Documentum attributes to a DTD
The easiest way to add the Documentum namespace declaration and Documentum
attributes to a DTD is to declare two internal parameter entities in your DTD, then add
one entity reference in the ATTLIST declaration for each element that will be chunked,
and the other entity reference for each element that will be linked.

To add Documentum attributes to a DTD

1. Open the DTD file that will be associated with your XML application.
2. Add the following two parameter entity declarations:
<!
=============== Documentum attributes =================
Documentum attributes to be added to each element that
has an <xml_content_rule> or <xml_link_rule> in the XML
application configuration file
=======================================================
>
<!ENTITY % dctmatts
"xmlns:dctm CDATA #FIXED 'http://www.documentum.com'
dctm:obj_id CDATA #IMPLIED
dctm:obj_status CDATA #IMPLIED
dctm:version_label CDATA #IMPLIED"
>
<!ENTITY % dctmlinkatts
dctm:link_obj_id CDATA #IMPLIED
dctm:link_obj_status CDATA #IMPLIED
dctm:link_version_label CDATA #IMPLIED">
Note: Currently, dctm:link_obj_id and dctm:link_obj_status are not functional, but

Documentum advises that you add these attributes for forward compatibility with
future releases.
3. For each element that has a chunking rule in your XML application configuration
file (as determined by the element specified in the first <element_selection_pattern>
nested under <xml_content_rule>), add the following parameter entity reference to
the <!ATTLIST> declaration for that element:
<!ATTLIST element_name
%dctmatts
>
4. For each element that has a link rule in your XML application configuration file (as
determined by the element specified in the first <element_selection_pattern> nested
under <link_rule>), add the following parameter entity reference to the <!ATTLIST>
declaration for that element:
%dctmlinkatts
>
Note: Do not add the link attributes when the <link_rule> element in your XML
application configuration file has the attribute value peer_or_child=ʺpeerʺ.
When a file is downloaded, these attributes are patched into the files with the appropriate
values for that object from the repository. If the values are changed by the author when
editing the file, the new values will populate the associated repository properties for
that chunked element or the external file.

For an example of adding these attributes to the NewsML DTD, see The NewsML DTD,
page 255.
Adding Documentum attributes to schemas
With schemas, you have many options on how to add the Documentum attributes and
also have schema validation.
Option 1
Option 1 allows only attributes of a different namespace. You can declare on your
elements that are chunked elements that any attributes from a different namespace are
allowed. It does not matter if they are not declared.
To do this you use the anyAttribute definition with namespace=ʺ##otherʺ and
processcontents=ʺskipʺ.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >
<xs:element name="chunk">
<xs:complexType>
<xs:anyAttribute namespace="##other" processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
Option 2
Option 2 allows only attributes from the Documentum namespace.

<xs:element name="root">
<xs:complexType>
<xs:anyAttribute namespace="http://www.documentum.com"
processContents="skip"/>
</xs:complexType>
</xs:element>
</xs:schema>
Option 3
Option 3 allows either any attributes from the Documentum namespace or another
namespace (use other) and validates if a definition is available To do this, change the
definition of processContents=ʺlaxʺ.

<xs:complexType>
processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:schema>
To make the Documentum attributes definitions available you can optionally create
this Documentum schema:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:attribute name="obj_id" type="xs:string"/>
<xs:attribute name="obj_status" type="xs:string"/>
<xs:attribute name="version_label" type="xs:string"/>
<xs:attribute name="link_obj_id" type="xs:string"/>
<xs:attribute name="link_obj_status" type="xs:string"/>
<xs:attribute name="link_version_label" type="xs:string"/>
</xs:schema>
and then import into your schema:

<xsd:import namespace="http://www.documentum.com" schemaLocation=
"documentum.xsd"/>
Note: Currently, dctm:link_obj_id and dctm:link_obj_status are not functional, but

Documentum advises that you add the other attributes for forward compatibility with
future releases.
Option 4
Option 4 allows either any attributes from the Documentum namespace or another
namespace (use other) but the definitions must exist and they must be valid. To do this,
change the definition of processContents=ʺstrictʺ and import Documentum schema.
<xs:complexType>
processContents="strict"/>
</xs:complexType>
</xs:element>
</xs:schema>
To make the Documentum attributes definitions available you must create this
Documentum schema:
<xs:attribute name="obj_id" type="xs:string"/>
<xs:attribute name="obj_status" type="xs:string"/>
<xs:attribute name="version_label" type="xs:string"/>
<xs:attribute name="link_obj_id" type="xs:string"/>
<xs:attribute name="link_obj_status" type="xs:string"/>
<xs:attribute name="link_version_label" type="xs:string"/>
</xs:schema>

and then import into your schema:

<xsd:import namespace="http://www.documentum.com" schemaLocation=
"documentum.xsd"/>
Modifying path names for external parameter entity

declarations
This section applies to the case in which the XML application will manage your DTD,
and your DTD contains parameter entity declarations that refer to external files (with
extensions such as .mod or .ent). The DTD and its component files will be stored in
separate folders in the repository, as described in the procedures for creating an XML
application. However, they will be downloaded to the same location on the local system:
Documentum_user_directory\XML_application_name\Application
Support Documents
where Documentum_user_directory is the directory specified on the local system

for operations such as viewing and checkout (by default, C:\Documentum), and
XML_application_name is a folder with the name of the XML application. For this reason,
the URI in the external parameter entity declarations in your DTD must identify the DTD
members only by name, without a path. For example, suppose you have a root DTD
called dtd_master.dtd and a part called second_level_dtd.dtd. The parameter entity in
the root DTD should appear as follows.
<!Entity %second_level SYSTEM "second_level_dtd.dtd">
or
<!Entity %second_level PUBLIC "//Documentum//DTD CellPhoneInlineEntity//EN"
"second_level_dtd.dtd">
Creating the XML application

Once you have assembled and prepared the files that will be stored with the XML
application, you must create the XML application folder structure, set the folder
permissions, and import the files into the appropriate location in the repository. If you
have Documentum Application Builder (DAB), you can enter the information in a dialog
box, and the application will be created for you. DAB creates the XML application in
the Systems cabinet of your repository.
For more information on creating the application using DAB, see the DAB online help.
Optionally, you can create the XML application folder structure manually through a
WDK‑based application, such as Documentum Administrator or Webtop. If you create
the XML application manually, you can create it in any cabinet or folder in the repository.

For instructions on creating an XML application using Webtop, see Creating an XML
application using Webtop, page 42.
Creating an XML application using Webtop

To create an XML application using Webtop, perform the following procedures:
• Create the XML application folder, page 42
• Setting the application folder’s properties and permissions, page 42
• Creating the application support documents folder, page 43
• Creating folders for non‑download supporting documents, page 43
• Importing the XML application configuration file, page 44
• Importing a DTD, page 44
• Importing a schema, page 44
• Importing supporting documents, page 45
Create the XML application folder
You must create a folder that will contain all of the files and folders pertinent to your
XML application. This folder must be the same name as the XML application and must
be a special object type, as detailed in the procedure below.
To create the XML application folder

1. In Webtop ,connect to the repository as a Superuser.
2. Navigate to the Systems cabinet and select the Applications folder.
3. Select File > New > Folder.
4. Type the name of the XML application. The name must match the name of the XML
application configuration file. The name must be unique within the repository.
5. In the Type field, choose XML Application (dm_xml_application).
6. Click New.
Setting the application folder’s properties and permissions

To set the XML application folder’s properties and permissions
1. Select the XML application folder and then select File > Properties.

2. In the Custom tab, set the following:

• Schema (or Namespace): the schema file name
• DTD System Id: the DTD file name
• DTD Public Id: the public identifier
• Root Elements: all elements that can serve as the root in the XML document.
3. In the Security tab, make sure to give at least Version permission to the users who
will check in documents using the XML application.
4. Click Apply, and then OK.
Creating the application support documents folder
You should create an Application Support Documents folder that will hold any
supporting documents that you want to be downloaded to local systems during checkin,
checkout, import, and export. This would include files such as the DTD, schema, modular
components of the DTD or schema, CSS, XSL stylesheets, FOSI, and any other files.
To create the Application Support Documents folder

1. Select the XML application folder, and select File > New > Folder.
2. In the Name field, type Application Support Documents.
3. For the object type, choose dm_folder.
4. Click New.
Creating folders for nondownload supporting documents
You can create any additional folders (of type dm_folder) within the XML application
folder to hold any supporting documents that you do not wish downloaded to local
systems during checkin, checkout, import, and export of XML documents, For example,
you might not want your XSLT stylesheets downloaded to every local system if they are
only used in a specialized publishing context.
Only the Application Support Documents folder and the DTD stored in the XML
application folder are downloaded to local systems during inbound and outbound
operations involving XML applications.

Importing the XML application configuration file
You must import the XML application configuration file into the XML application folder
and assign it the object type XML Configuration, as described in the procedure below.
To import the XML application configuration file

1. Drag the XML application configuration file on your local system into the XML
application folder in the repository.
2. For the object type, select XML Configuration.
3. For the file format, select XML Document.
4. Click Import.
Importing a DTD
The following procedure is necessary if the XML application will be managing your
DTD. For more information, see DTD and schema management, page 20.
The name of the DTD file must match the value of the <sys_id> element in the XML
application configuration file, if specified.
To import a DTD into the XML application folder

1. Drag the DTD on your local system into the Application Support Documents folder
in the repository.
2. For the object type, select dm_document.
3. For the file format, selectDTD File.
4. Click Import.
5. Check to make sure the file name as it appears in the repository has the extension
.dtd. If it does not, right‑click the file, select Properties, and add the .dtd extension
in the Name field.
Importing a schema
The following procedure is only necessary if you want the schema to be downloaded
to users’ local systems.
In the current release, document patching of schemas does not occur, so validation of
XML documents against schemas can only occur if the parser can find the schema on

the local system in the location specified in the schema URI. If the URI is set to point
to the Application Support Documents folder, and all users have exactly the same
Documentum user directory on their systems, then validation will be successful. For
more information, see DTD and schema management, page 20.
The name of the schema file should match the value of the <schema> element in the XML
application configuration file, if specified.
To import a schema
1. Drag the schema file on your local system (and any other module components) into
the Application Support Documents folder in the repository.
2. For object type, select dm_document.
3. For file format, select XML Schema.
4. Click Import.
5. Check to make sure the file name as it appears in the repository has the extension
.xsd. If it does not, right‑click the file, select Properties, and add the .xsd extension
in the Name field.
Importing supporting documents
Use the following procedure if you have any supporting documents that you want to
download to users’ local systems when documents are transferred into and out of the
repository.
To import supporting documents into the XML application

1. Drag the support documents on your local system into the Application Support
Documents folder in the repository.
2. For the object type, select dm_document.
3. Allow the suggested file format, or select Unknown and add the extension to the
name of the object.
It does not matter if the description of the file format does not match the object you
are importing. For example, the file format for the .mod extension may refer to it
as a sound file. As long as the file format you choose has the .mod extension, it
will download with the correct extension to the local file system. A file of format
Unknown will download with no extension, so it is important to add the extension
to the file name when you import it if the file format is Unknown.
4. Click Import.

If you have any supporting documents that you do not wish to be downloaded, import
them to the other folders that you created in Creating folders for non‑download
supporting documents, page 43.
Testing and troubleshooting the XML

application
After creating, validating, and checking in your XML application, you can perform the
following tasks to test your XML application.
Verifying the XML application is set up correctly

Problems with XML applications most frequently occur because file names, folder names,
object types, or file formats were set up incorrectly. You can avoid troubleshooting later
by double‑checking the following information:
• XML application folder
— Is the name of the application folder unique in the repository?
— Look at the folder properties. Is the folder type XML Application
(dm_xml_application)?
— Are the values for the root elements property correct?
— If Documentum is managing your DTD, have you specified a system identifier,
and a public identifier if appropriate as properties on this XML application
folder?
• XML application configuration file:
— Is it located in the XML application folder?
— Does it have the same name as the XML application folder?
— If you look at the file’s properties, is the type listed as XML Configuration?
— Is the file format listed as XML Document?
— View the contents of the XML application configuration file. Does the value of
<application><name> match the name of the XML application configuration file
and the name of the XML application folder?
— Does the element <sys_id> appear in the file? If so, does it match the name of any
DTD and schema files that exist in the XML application folder?

• DTD and schema

— If the XML application will manage your DTD, does your DTD file appear in the
Application Support Documents folder?
— If your DTD has external parameter entities, are the referenced files stored in the
Application Support Documents folder? Have these files been assigned a file
format so they are downloaded to the local system with the proper file extension?
— If you want your schema to be downloaded to a local system, does the schema
file and any components appear in the Application Support Documents folder?
— Check the properties of any DTD or schema files in the XML application folder.
Is the object type dm_document? Is the file format DTD File for the DTD, or
XML Schema for the schema?
— Are any supporting files you want downloaded to local systems in the
Application Support Documents folder?
Testing your XML application

You can test your XML application by importing a test XML document into the
repository. Construct the XML document so that it will test all of the rules.
Tip: Make sure your XML file is well‑formed and valid before you attempt to import it.
After you have imported your XML document into the repository, check the following:
• If you chunked the file, do the chunks appear in the right locations?
• Do the chunks appear as expected when you view the document in a client such
as Virtual Document Manager?
• Are repository properties on individual objects set as expected?
• Does the document check out and check in properly?
• If you assigned ACLs, are those permissions correctly set on the objects in the
repository?
• If the XML application is managing your DTD or schema, does the document open
properly in an XML editor, with no errors that it cannot find the DTD or schema
or any component files?
Troubleshooting import or checkin problems

The following sections provide solutions to some commonly reported problems related
to import or checkin.

Tip: If a document fails to import, and the error message is not helpful, try opening
your XML document in Internet Explorer. Internet Explorer checks for well‑formedness
and validity, it provides very specific error messages, and it is more strict than some of
the authoring tools.
Cannot import Epic document in Webtop
By default, Arbortext Epic does not add a path to its system identifier, resulting in a
DOCTYPE declaration like the following:
<!DOCTYPE book PUBLIC "//Arbortext//DTD DocBook XML V4.0//EN"
"axdocbook.dtd"
Epic knows where to look to find the DTD, but other applications do not. If your XML
application is managing your DTD, Webtop does download this DTD for import, so you
must add the correct path to the DTD on the local system for Webtop import to work
correctly in Webtop. Failing to do so will result in an error message such as the following:
Content transfer: path/filename.dtd (The system cannot find
the file specified)
Parser looks for DTD or schema even when not validating
If the <validation> element is not present in the XML application configuration file,
the parser will check only well‑formedness during inbound and outbound repository
operations, but it will still look for a DTD or schema if it is mentioned in the <!DOCTYPE>
declaration in the XML document.
If the DTD file name is stored in the DTD System ID property of the XML application
folder, then the DTD stored in the application folder will be used. If the DTD System ID
property is not specified, then the DTD must be in the location on the local system that is
specified by the <!DOCTYPE> declaration in the XML document.
Error: "&xxx; is referenced but not declared"
If your DTD defines text entities and those entities are referenced in any of your
documents, you must set up your XML application to manage the DTD. The Xerces
parser will not allow import or checkin of documents that reference a text entity that
it cannot find a declaration for.

Avoiding date/time format errors
When the <metadata> element is used to populate repository properties with date/time
information, use the <date_format> element and make sure your XML data that will be
extracted as date metadata fits this format. Without the <date_format> element present,
or if the data do not match the specified format, the date will be set using the date format
of the locale of the machine on which DFC is processing the XML document. This would
cause a problem, for example, if the XML application were being processed by several
application servers using different locales.
XML application detection algorithm
If you are having problems with the correct XML application being detected for your
XML documents, it may be helpful to understand the algorithm by which application
detection occurs.
When an XML document is imported or checked in to the repository, there is an
algorithm used to determine which XML applications can apply. This algorithm occurs
in the sequence specified here.
1. Has a specific XML application been set through the API?

2. If not, is there a processing instruction in the prolog of the XML document of the
following type:
<?dctm xml_app="application_name"?>
where application_name is the name of the XML application. The following processing
instruction will halt the algorithm:
<?dctm xml_app="ignore"?>
3. If not, information is extracted from the XML document, as shown in Table 3, page
49, and used to construct a query that searches the properties of the repository
object type called XML Application (the object type used for the XML application
folder) for a match.
Table 3. Application detection based on XML document information
Property in XML Application Folder Information in XML Document

DTD System ID DTD file name extracted from system
identifier in <!DOCTYPE> declaration
DTD Public ID Public identifier extracted from
<!DOCTYPE> declaration (if present)

Property in XML Application Folder Information in XML Document

Root elements Root element of XML document
Schema Schema file name, extracted
from xsi:SchemaLocation or
xsi:noNamespaceSchemaLocation
attribute in the root element of the XML
document
If there is a match between all of the information extracted and the corresponding
XML application folder properties, and if the query returns only one XML
application that matches, then this XML application is automatically selected. If
more than one application is detected, then the first one applies, or, in clients that
allow it, the choices appear in a list box.
Note: The Default XML Application has a special status and will always appear in
this list box.
4. If none of the above apply, then the Default XML Application will apply.
If the extension of the document is XML, then the Default XML Application
provided with the Content Server applies. If you have added other extensions to
the format_class attribute of dm_format, then you must provide your own default
application and store it in the /System/Applications folder in the repository.
Troubleshooting export or checkout errors

The following problems may occur during or after export or checkout of XML documents.
Parser cannot find DTD or schema after checkout
If the XML application is managing your DTD and you encounter DTD‑related errors
when you open your XML document in an editing application, there is more than one
possible reason.
If the file name of your DTD is not stored as the DTD System ID property of your XML
application folder in the repository, then the parser will download the DTD but will not
patch the system identifier in the <!DOCTYPE> declaration in the XML document, and
your XML editor will look for the DTD in that location on the local system.
If your DTD contains external parameter entity declarations that include a path name,
this may cause an error, since the DTD and its referenced files are all downloaded to the
Application Support Documents folder on the local system. Modify the DTD in the XML

application so that the external parameter entity declarations contain only the name
of the file, not the path.
If the DTD System ID property of your XML application folder contains the name of
your DTD, but your DTD is not stored either in that folder or the Application Support
Documents folder in the repository, then the system identifier in the XML document will
be patched to point to the Application Support Documents folder that downloads to the
local system, but the DTD file will not be there.
Distributing the XML application as a DocApp

If you create an XML application manually, you can package the application and its
supporting objects, such as object types, workflows, and document lifecycles as a
DocApp, using Documentum Application Builder. This makes it easy to distribute the
application to other repositories in your enterprise.
When you create the DocApp, insert all objects specified in the XML application
configuration file into the DocApp (as well as any other objects required for your
application). This includes the XML application folder and all of its subfolders with their
contents, and any custom object types, ACLs, document lifecycles, and workflows.
Use the DocApp archive installation options to set the paths for the following items:
• XML application folder: set the path to System\Applications and make sure to
include all its subfolders and content. This will install the XML application folder
and its contents into the same location as for your primary repository.
• Document lifecycles and workflows: set the same path that is used for these objects
in your XML application configuration file.
Note: If you use an object ID instead of the name of a folder path (in the <path>
element) or document lifecycle (in the <policy_name> element) in your XML application
configuration file, you will have to change the object ID if you replicate or install the
XML application into another repository.


Chapter 4
The XML Application Configuration File
This chapter provides an overview of XML application configuration file, shows the most common
features of rules and the elements that are used to configure those features, and provides general
information about working with rules.
This chapter contains the following sections:
• Creating an XML application configuration file, page 53
• Anatomy of an XML application configuration file, page 54
For detailed reference information on the elements that can be used in your XML application
configuration file and how they must be structured, see Appendix A, Reference Information and
Examples for Config_6.5.dtd.
For an annotated sample of an entire XML application configuration file based on the NewsML
industry standard, see Appendix D, Sample XML Application Configuration File for NewsML.
Creating an XML application configuration file

Each Documentum XML application must include a single configuration file of the same
name as the XML application, and the object type must be dm_xml_config.
The configuration file is itself an XML document and will be validated against a version
of the DTD provided by Documentum with the Default XML Application. This manual
pertains specifically to the DTD version named config_6.5.dtd. This DTD is stored in
System\Applications\Default XML Application and is installed with Content Server 6.5.
Caution: Never modify the Default XML Application configuration file or the
config_6.5.dtd. Instead, use the Default XML Application as a template to create
your own XML application.
You can create an XML application configuration file either before or after you create
the XML application. There are different advantages to each method. If you create the

configuration file ahead of time and you use Documentum Application Builder (DAB)
to create the XML application, some of the fields on the creation tabs will be populated
for you once you add the configuration file. If you use DAB to create the application
before you have created a configuration file, you are presented with options to create a
configuration file based on the Default XML application, or to copy a configuration file
stored in the repository or on your local system.
You can use the XML Configuration File Editor that is provided with DAB or any
other XML editor. The XML Configuration File Editor provides lists of rules organized
into type and allows you to base rules on element in your XML sample document. If
you use the XML Configuration File Editor, refer to the online help in the File Editor
for assistance.
If you do not use the XML Configuration File Editor, it is a good idea to develop your
XML application configuration file with an XML editor that will validate dynamically
against the appropriate configuration DTD. Since the XML application configuration file
is validated against config.dtd the first time an XML document is imported with a new
XML application, an invalid configuration file will cause the document import to fail.
Anatomy of an XML application configuration

file
The XML application configuration file contains a prolog and a root element, just like
any XML document. The root element contains two main types of configuration settings:
• Application‑level settings
• Rules that the application follows when XML documents are processed
The following sections present more information on the prolog, application‑level
settings, and rules.
The configuration file prolog

Every XML application configuration file requires an XML declaration, a Doctype
declaration, and a processing instruction that instructs the system to exempt this file
from being processed by the Default XML Application, as follows:
<?xml version="1.0"?>
<!DOCTYPE application SYSTEM "config_6.5.dtd">
<?dctm xml_app="Ignore"?>
All prologs should contain this information. If you use an earlier version of the config.dtd
as the system identifier, see the appropriate version of this manual for a description
of the elements that are available to you.

The application‑level settings and rules are contained within the <application> element.
See the following sections for more details.
Applicationlevel settings
The prolog is followed by the root element, <application>. The elements in Table 4, page
55 are the children of the root element that are used for creating the XML application or
that configure certain rule‑independent features of the application.
Table 4. Elements related to the XML application
Purpose Element(s)
Set the name of the XML application name
Provide information used by <app_pattern>
Documentum Application Builder
(DAB) when creating an XML application
Allow work in progress to bypass <allow_work_in_progress>
well‑formedness and validation checks
during inbound and outbound repository
operations, until the document becomes
well formed and valid.
Specify whether to validate XML <validation>
documents during inbound and outbound
operations.
Specify whether to validate against the <dds_validation>
Content server data dictionary
Container for one or more <javaclass> <java_classes>
elements, which allows the use of Java
custom code
Declare variables external to the XML <external_variables>
document
Rules
The <map_rules> element, a child of the <application> root element, is the container for a
series of rules that determine how the XML application processes the XML document.
(See Rule types, page 56.)

What you can do within a rule depends on the rule type. The section Task‑based
classifications of rule elements, page 57 provides a task‑based overview of which
elements you should use when you specify rules.
The section Overview of some rule features, page 59 presents an overview of some
features that may help you specify rules more effectively.
Rule types
There are four different types of rules:

• XML Content Rule, page 56
• Link Rule, page 57
• Non‑XML Content Rule, page 57
• Entity Rule, page 57
XML Content Rule
An XML Content Rule (<xml_content_rule>) is usually the most frequently used rule. It
applies to parsed XML content and can carry out the following actions:
• Specify the element to which the rule will apply
• Specify the location in the repository where the chunked file will be stored
• Specify owner name for the chunk, if other than the default
• Specify the repository object name for the chunked file
• Specify permissions on the chunked file
• Specify object type for the chunk, if other than the default
• Attach the chunked object to a document lifecycle
• Assign values extracted from the XML document to the repository properties,
through the use of variables
• Define variables and assign them values from the element names, element content, or
attribute values in the XML document, for use in the actions listed above.
The main function of an XML Content Rule is usually to chunk XML content in the
document, but it can have other primary purposes, such as assigning metadata to an
XML document that will not be chunked.

Link Rule
A Link Rule (<link_rule>) uses links in the XML document to external files or references
to NDATA entities to locate and handle unparsed entities, such as graphics files. The
Link Rule works like an XML Content Rule in terms of assigning an object location,
metadata values, permissions, and so on. You can also specify whether the linked file
should be treated as a child or a peer of the XML virtual document, and whether this is
a permanent link.
NonXML Content Rule
A Non‑XML Content Rule (<non_xml_content_rule>) tells the server what to do with

non‑XML content contained in the XML document, such as base64‑encoded data. A
Non‑XML Content Rule works like XML Content Rules and Link Rules in terms of
assigning an object location, metadata values, permissions, and so on. In addition you
can specify the file format of the repository object that will contain the decoded data.
Entity Rule
An Entity Rule (<entity_rule>) tells the XML application to preserve all external
parsed (XML) entities as separate components of the XML virtual document when
imported or checked in, and to maintain their status as external entities when the main
XML document is exported or checked out. Any relevant chunking rules defined
by <xml_content_rule> will apply on import or checkin, but the chunked objects will
be reassembled into the external parsed entity on export or checkout. If this rule is
not specified, any external parsed entities will disappear after they are imported, and
the resulting chunks will be included in the main document when it is checked out or
exported. There can only be one Entity Rule per XML application, and this rule must
apply to all external parsed entities.
Taskbased classifications of rule elements

The following subsections provide handy lookup lists of elements that are used in rules,
sorted by task. See the documentation on the individual elements for information and
examples of their use. Note that these lists do not include every element in config_6.5.dtd,
but they do include the major tasks that you can accomplish with particular elements.

Elements that interact with repository objects
The elements in Table 5, page 58 are used in rules to perform repository actions
associated with creating a repository object for a chunk.
Table 5. Elements that interact with repository objects
Purpose Element(s)
Assign a repository location, create folder <location>
or cabinet if necessary
Assign an object name to a chunked object <object_name>
Assign an owner name to a chunked <owner_name>
object
Assign a file format to a non‑XML <format_attr>
chunked object
Assign a value to a repository property, <metadata>
or from a repository property to XML
content
Assign a binding rule to a symbolic <version_label>
version label on import
Assign permissions by specifying a <acl_name>, <acl_domain>, <default_acl>
system ACL name, domain, or default
ACL to a chunked object
Assign a document lifecycle (name, scope, <business_policy>
initial state) to a chunked object
Create a cabinet or folder or extract <xml_content_rule make_object=ʺfalseʺ>
information without chunking an object
Set a permanent link on a relation object. <permanent_link>
Maintain chunked objects separately <make_entity/>
in the repository but integrate them
into a single document on export
or checkout. (Required element in
<xml_content_rule>.)
Elements that finetune the rules
The elements in Table 6, page 59 are used to specify variations in the rules.

Table 6. Elements that finetune the rules
Purpose Element(s)
Specify an element in the XML document <element_selection_pattern>
and any context sensitivity (based on
structural hierarchy, nth occurrence, value
of an attribute)
Refer to elements or attributes with namespaceURI attribute of <element> or
namespaces <attr_name>
Declare and assign values to variables, <variables>
which will be used to assign values to
other elements
Specify value should come from content <content_of_element>
of element in XML document
Specify value should come from an <attribute_value_of_element>
attribute of element in XML document
Specify value should come from tag name <tagname_of_element>
of element in XML document
Specify a default value when none can be <default>
assigned
Overview of some rule features

The following sections present some basic information that applies across rules.
• Triggering a rule with <element_selection_pattern>, page 59
• Rules and rule ordering, page 60
• Using variables to extract information from the XML document, page 60
• Alias support, page 61
• Constructing DRLs, page 61
Triggering a rule with <element_selection_pattern>
The first element of a rule (except for <entity_rule>) is <element_selection_pattern>,

which specifies two types of information about when the rule will apply:
• The name of an element in the XML document

• (Optional) A context for that element, such as structural information or the value
of one of its attributes
If the entire <element_selection_pattern> applies to an element in the XML document, it
triggers the rest of the rule to apply.
Rules and rule ordering
If you want to apply the same action to a number of different elements in the XML
document, you must construct a separate rule for each element. A single element can
be specified in more than one rule, and in more than one type of rule. If possible, rules
referring to the same element in different contexts should be mutually exclusive. If
overlap is necessary, the more specific rule should come first. For example, if you want to
assign certain repository properties to a chunk when an element has a particular attribute
value, and assign different repository properties for that element chunk elsewhere, the
rule for the element with the particular attribute value should come first.
Note: As of this release, an <xml_content_rule> and <link_rule> that apply to the same
element can appear in either order.
Using variables to extract information from the XML document
Similar to other programming languages, in the XML application configuration file a

variable is first defined with the <variable> element , then used with the <var> element.
The parser substitutes a string value of the variable for the entire <var> element,
including the open and close tags.
You can assign the following types of information from the XML document to variables:
• The content of a particular element, using <content_of_element>
• The attribute value of a particular element, using <attribute_value_of_element>
• The name of the element itself, using <tagname_of_element>
You can use these variables to assign values to other elements in the XML application
configuration file that specify location, owner name, object name, object type, parameters
for permissions, document lifecycle parameters, or other repository properties. In most
cases, you can combine one or more variables with static text to provide these values. See
the individual element in this reference guide for examples.
Besides variables, you can use XPath functions with the <expression> command, and you
can call Java class methods through use of the <java_classes> element.

Alias support
You can use aliases in the following elements in the XML application configuration file:
<owner_name>
<acl_name>
<acl_domain>
<path>
Aliases are specified in the following format:
%[alias_set_name.]alias_name
Constructing DRLs
You can use DRLs in rules to specify a repository location in which an object will be
imported (see the <path> element). You can also use DRLs in XML documents to specify
a repository location of a linked file that is specified as the link target of a link rule (see
the <link_rule> and <link_target> elements). The following sections provide information
on how to construct DRLs that you would use for these purposes.
Syntax
A DRL has the following syntax:.
dctm://repository_name/object_specification?arguments
where repository_name is the name of the repository. The other replaceable items in italics
are as described in the following sections.
Object specification
You can specify the object using an object ID, a chronicle ID, or a valid DQL select
statement, as described in the following sections.
ID value
Use the object ID if you want to specify a particular version of an object. Use the chronicle
ID, which is the ID of the root version of the object, if you want to add an argument to
specify a particular version number or version label (such as CURRENT).

You must name the type of ID you are using (object ID or chronicle ID) as an argument in
the DRL (see DRL arguments, page 62).
Predicate
A predicate is a DQL select statement, minus the word ʺselect.ʺ.

Example:
dctm://scribblers3/dm_document where object_name=&apos;toto&apos;
?DMS_OBJECT_SPEC=PREDICATE
Do not create a line break or leave any spaces in the DRL string. If the string contains
characters that are reserved characters in XML, use a text entity reference in place of the
reserved character.
Table 7. Text entity references
XML Reserved Character Entity Reference

& &
< <
> >
’ '
ʺ "
Caution: If the query returns more than one object, the first one in the result
collection is used.
DRL arguments
The arguments in Table 8, page 63 can be used in a DRL and recognized by an XML
application. DRLs can contain certain other arguments that are used to connect to a
repository (such as DMS_USER, DMS_PASSWORD, DMS_DOMAIN, DMS_BRKR);
XML applications ignore these arguments and attempt to locate the specified object
in the current repository.
Note: The argument string should begin with a question mark.

Table 8. DRL arguments applicable to XML applications
Argument Description
DMS_OBJECT_SPEC Has the following values:
• OBJECT_ID (when object specification
is an r_object_id)
• CHRONICLE_ID (when object
specification is an r_object_id)
• PREDICATE (when object specification
is a DQL query)
DMS_VLAB Version label of the object (used with
chronicle ID)
DMS_VNUM Version number of the object (used with
chronicle ID)
Examples of DRLs for use in XML applications
The following sections contain examples of DRLs used for various purposes.
A simple folder DRL
DRLS can use an object ID to point to a specific folder in a repository, such as the
following:
dctm://scribblers3/0b00270f80003618?DMS_OBJECT_SPEC=OBJECT_ID
In this example, the repository is scribblers3, the object specification is an object ID, and
the argument OBJECT_ID specifies that the ID in the object specification is an object ID.
Since folders do not have versions, a folder will always use an object ID, and VNUM and
VLAB should not be used as arguments.
A folder DRL with a query
Suppose that you want to put draft documents into a different folder, which has a custom
object type called draft_folder, with a custom property called project_status, Instead of
pointing to this specific folder by its object ID, you could use a query to return any folder
of type draft_folder when the custom property project_status has a value of ʺDRAFTʺ.
The following example shows a DRL whose object specification contains a DQL query:
dctm://scribblers3/draft_folder where
project_status=&apos;DRAFT&apos;?DMS_OBJECT_SPEC=PREDICATE

In this example, the repository is scribblers3, the object specification type is a DQL query,
and the argument specifies that the type of object specification is a predicate. The '
entities stand in for single quotes in the where clause. The folder selected will be the
first object from the result pool produced by the query.
A document DRL for the CURRENT version
Suppose that you want to link to the version of a document in the repository that is
marked CURRENT.
The following DRL would find the specified ID but then take the version of the object
marked CURRENT.
dctm://scribblers3/0900270f8003ee67?DMS_OBJECT_SPEC=CHRONICLE_ID
&DMS_VLAB=CURRENT
In this example, the repository is scribblers3, the ID provided is the chronicle ID (the ID
of the root version of a particular object), and the version label is specified as CURRENT
with the VLAB argument.
Note: If you use any version label other than CURRENT, that version label must have
already been assigned to at least one version of the object specified by the chronicle ID.
A document DRL for a specific version number
Suppose that you want to specify a particular version number of a document. You can
use either the chronicle ID or the object ID to do this. If you use chronicle ID, you must
also use a VNUM argument, as follows:
dctm://scribblers3/0900270f8003ee67?DMS_OBJECT_SPEC=CHRONICLE_ID
&DMS_VNUM=1.0
In this example, the repository is scribblers3, the ID provided is the i_chronicle_id (the
object ID of the root version of a particular object), and the version number is specified
as 1.0.
Note: Use the chronicle ID rather than the object ID when you want to use DMS_VLAB
or DMS_VNUM.
Instead of chronicle ID plus a VNUM argument, you can use the object ID of that version,
as in the following example:
dctm://scribblers3/0900270f8003ee75?DMS_OBJECT_SPEC=OBJECT_ID

Because object ID identifies a specific version of an object, you should not use the VNUM
or VLAB arguments.


Chapter 5
Queries
One of the purposes of designing XML applications to chunk XML documents and assign attributes
is to dynamically generate and publish documents by using queries to retrieve information from
the repository.
DQL queries search repository metadata or content (using zone searches) and retrieve repository file
names and any properties you specify. XDQL is a Java class that executes DQL queries from Java
applications or XSLT stylesheets. It returns any repository query results as XML.
The most common way to implement XDQL is through an XSLT stylesheet. For example, to produce
the Documentum Developer online newsletter, an XML document is created that serves as a shell for
that particular issue, containing information such as the issue number and titles. The repository is
then queried for specific content and inserted into the shell to create an HTML document.
This chapter presents an overview of DQL and XDQL queries. It contains the following sections:
• Queries with DQL, page 67
• Queries with XDQL, page 71
For a detailed NewsML example of using an XSLT stylesheet to generate a newsletter see Chapter 6,
Transformations.
Queries with DQL

Repository objects in XML format can be searched using the standard repository search
techniques. Searches can be performed both for object metadata (properties) and full text
(providing that full‑text indexing is enabled when a document is imported or checked
in). All of the Documentum clients have search assistance in the user interface (UI),
which allows end users enter property names and values to search for metadata, or text
and operators to conduct full‑text searches, and constructs the query behind the scenes.
More technical information on queries is provided in the following sections.
DQL query statements can also be embedded in XSLT stylesheets, as shown below.

Queries
Basic DQL statements allow you to query attributes, and the optional SEARCH clause
allows you to query content, as described in the following sections.
Whether to query metadata or content depends on your business requirements. For
example, suppose you want to locate all documents for which a certain element has a
particular value, such as a particular model name. Querying metadata is the best way
to obtain this information. Or, perhaps you want to find all documents whose content
references a particular topic. In this case, querying content is best.
Queries for metadata

Querying metadata of an XML document is no different from querying metadata in any
other document in the repository.
For example, the following SELECT statement would be used to find all cell phone
models that have AMPS protocol, use Analog technology, and whose price is greater
than or equal to $10:
select * from cell_phone_catalog_item where transfer_technology
= 'Analog' AND protocol = 'AMPS' AND price >= '10'
You can also retrieve specific values as part of the selection clause. In the following
examples, the exact value of the price property would be returned:
select price from cell_phone_catalog_item where transfer_technology
= 'Analog' AND protocol = 'AMPS' AND price >= '10'
The following sections provide more examples of DQL queries. For detailed information
on how to query metadata, see the SELECT statement documentation in the Documentum
Content Server DQL Reference Manual.
DQL Clause for virtual document queries
When XML documents are chunked, the components are stored as a virtual document.
You can query the document’s entire hierarchy or only some portion of it.
The DESCEND clause in DQL allows you to search in a given virtual document. The
syntax of the IN DOCUMENT clause is:
IN DOCUMENT object_id [VERSION version_label][DESCEND]
[USING ASSEMBLIES][WITH binding condition][NODESORT
BY attribute {,attribute} [ASC|DESC]]]

Queries
Finding paths
DQL contains clauses that will allow you to return the PARENT ID of an object in a
Virtual Document. The server also provides two APIs that allow you to return paths to
an object:
• VdmPath
dmAPIGet(vdmpath,session,component_id[,root_id]
[,shortest_path] {,version_list}
Use this method if performance is more important than flexibility.
• VdmPathDQL
dmAPIGet(vdmpathdql,session,component_id[,root_id]
[,shortest_path][,type][,binding_condition][,nodesort_by]
This gives more flexibility in choosing paths.
Finding links
The object pointed to by a child link is made a component of the virtual document. Peer
links are stored in repository and linked to the XML document with an xml_link, a
subtype of dm_relation:
select * from dm_sysobject where (r_object_id IN (select child_id
from dm_relation where relation_name ='xml_link' AND parent_id =
'0900162e80059910')) and a_is_hidden=false ORDER BY owner_name,
r_object_id
(Return to me all objects that are a peer link to this object.)
Fulltext searches
The server provides full‑text indexing services for documents in the repository. Full‑text
indexes are created for storage areas. For documents in a storage area, their content is
indexed if the format’s can_index property is set to true, and their properties are indexed
if their a_full_text property is set to true. Both content and selected properties of the
object are indexed. Use DQL for full‑text searches. For more information on full‑text
searching, see the Documentum Content Server DQL Reference Manual and the Documentum
Content Server Fundamentals Guide.

Queries
Zone searches
A more restrictive type of full‑text search that is available only for XML objects is a zone
search, which allows you to search for a given value within any specified element. A
zone consists of everything between the starting tag and closing tag for an element.
You use the passthrough format in DQL to do zone searching. Use the following syntax:
SELECT * FROM object_type SEARCH TOPIC
'text_string <IN> element_name'
where object_type is the name of the repository object type, text_string is the text you
are searching for, element_name is the name of the XML element to which the full‑text
search will be limited.
For example, the following query finds all documents that have the value quasivox in the
element <brandname>:
SELECT * FROM dm_document
SEARCH TOPIC 'quasivox <IN> brandname'
Zones can be nested by repeating the <IN> clause: The following example returns all
documents that have the value ʺspeed dialingʺ in the <memoryfeatures> element, only
when the <memoryfeatures> element occurs within a <cellphone‑catalog> element.
SEARCH TOPIC '(speed dialing <IN> memoryfeatures)
<IN> cellphonecatalog'
The next example restricts the search even further. It returns documents that contain
the value speed dialing in the <callfeatures> element if <callfeatures> is found in the
<memoryfeatures> element. In turn, the <memoryfeatures> element must be contained
in a <cellphone‑catalog element>.
SEARCH TOPIC '((speed dialing <IN> callfeatures)
<IN> memoryfeatures) <IN> cellphonecatalog'
You can use the SELECT statement’s optional clauses to apply other restrictions to
the results. For example, the following query returns only documents that meet the
SEARCH clause requirement and are owned by JoanK:
SEARCH TOPIC 'quasivox <IN> brandname'
WHERE owner_name='JoanK'
Note that zone searches do not span across chunks. For example, if you have chunked a
catalog into ʺmodelʺ elements, the following will not return any results:
SELECT * FROM dm_document SEARCH TOPIC 'Jeep <IN> model.name
<IN> model <IN> catalog'
However, the following will return results:

SELECT * FROM dm_document SEARCH TOPIC 'Jeep <IN> model.name
<IN> model'

Queries
Queries with XDQL

XDQL executes DQL queries but can return both metadata and content. XDQL is
exposed as a Java interface called IDfXmlQuery, which defines a set of methods
implemented by the class DfXmlQuery. These methods allow you to run DQL queries.
Query results are returned as XML documents, not collections. The methods can also
give you control over the format of the results.
You can use XDQL in a variety of contexts to perform a variety of tasks. For example,
using XDQL, you can:
• Extract the metadata and content of Documentum objects as XML for export to
another system
• Generate content for Web pages from a servlet or Java Server Page (JSP)
• Build dynamic XML documents using XSLT extensions
You can call IDfXmlQuery from any Java application, servlet or JSP, Enterprise
JavaBean (EJB), Visual Basic, C++, or ASP. In an XSLT stylesheet, you can use the
IDfClientX.getXMLQuery factory method to instantiate an IDfXmlQuery object, such as
in the following example:
<! create and init xdql class and specify dql query >
<xsl:variable name="clientx" select=
"java:com.documentum.com.DfClientX.new()"/>
<xsl:variable name="xdql" select="java:getXmlQuery($clientx)"/>
<!comment above and uncomment the following for DFC 4.x>
<!<xsl:variable name="xdql" select=
"java:com.documentum.xml.xdql.DfXmlQuery.new()"/>>
The IDfXmlQuery interface uses the DFC library to communicate with the repository
for querying and retrieving result collections. The calling instance must establish a
Documentum session (by connecting to a repository) and pass the session ID as a
parameter of the execute() method. The session is used to query the repository and
retrieve defined stylesheets.
For documentation of the IDfXmlQuery interface, see the DFC Javadocs. See the next
chapter for a detailed example of executing an XDQL query through an XSLT stylesheet.
Queries with XQuery
XQuery
XML Query Language (XQuery) is a string syntax that you can use to address any
piece of information in an XML document, make selections based on conditions, and

Queries
even construct new structures based on queried information. This makes XQuery an
extremely useful tool for searching in XML databases.
When a XQuery search is performed via DFC or iAPI, the queries are passed through
Content server to the XML Store, and the results are passed to the client from the XML
store directly without any post processing by the content server.
The Documentum XQuery Interface provides standard access to the XML Store content
through standard XQuery syntax. The query results returns an XML document or a byte
stream that adheres to Documentum security. For more information on XQuery, see
http://www.w3.org/TR/xquery/.
It is possible to perform join between data returned by DQL queries and the data or
meta‑data extracted from the XML Store. The XQuery interface is accessible through DFC
and iAPI. The interface provides an option to specify the store to against which to query.
The supported XQuery syntax supports referencing of Documentum meta‑data in the
query. For Example:
• Search use case: Find all documents that contain a particular XML tag that also
has some Documentum meta‑data value.
• Constrained query use case: Run XQuery over document or set of documents
specified by some Documentum meta‑data (such as project name or folder path).
• Meta‑data Results use case: Construct result document by pulling content from some
set of XML documents and include some of the object meta‑data in the result.
The external function calls in the XQuery is used for referencing Documentum meta‑data.
For example:
QUERY:
local:dql("select count(*)as number_of_objects from dm_document")
OUTPUT:
<root>
<object ID="">
<number_of_objects>1938</number_of_objects>
</object>
</root>
More examples:
Query 1 – search joining xml and relational meta‑data:
let $dqlquery := "SELECT r_object_id, i_contents_id FROM dm_document
WHERE folder(‘/MyProject’, DESCEND)"
for $i in unordered(
local:dql($dqlquery)/root/object),
$j in collection('/')
where $j[xhive:metadata(root(.), 'r_object_id') = $i//i_contents_id]
return
$j/name

Queries
This query returns a collection of content id’s for the matching documents.
Query 2 ‑ XQuery joining xml and relational meta‑data:
return
$j
This query returns a collection of document nodes from certain docs that are in the
folder /MyProject.
Query 3 ‑ XQuery returning documentum meta‑data:
return
$i
This query returns the Documentum meta‑data selected by the DQL query for each
document in a given collection of XML contents.
Xquery Restrictions
The following actions must not be executed using XQuery:
• No updates
• inserts
• deletes
DFC XQuery interface

The XML store solution provides a new DFC interface (IDfXQuery) to query content in
the XML store. This interface enables users to set a query, execute it and get results.
public interface IDfXQuery
/**
* Assigns a XQuery statement to a query.<P>
* Queries are written with the XQuery Language.

Queries
* @param xqueryString the XQuery statement

*/
public void setXQueryString (String xqueryString);
/**
* Specifies a storage area to query against.<P>
* This method can be called multiple times to query against multiple
storage areas.
* If no storage areas are specified, the query is executed against all
XML storage
* areas. Call this method before executing the query.
* @param store_name the name of the storage area
*/
public void addStore (String store_name);
/**
* Executes the XQuery.<P>
* @param sessionId DFC session identifier that has to be
established (connected)
* before "execute" is called.
*/
public void execute (String sessionId) throws DfException;
/**
* Executes the XQuery.<P>
* @param session DFC session identifier that has to be
established (connected)
* before "execute" is called.
*/
public void execute (IDfSession session) throws DfException;
/**
* Fills the given buffer with the next set of XQuery results. This
* method may be called repeatedly until results are exhausted.
* @param buffer The buffer in which XQuery results are written to
* @return the amount of bytes read into the buffer (1 indicates end of results)
* @throws DfException
*/
public int readResults(byte[] buffer) throws DfException;
/**
* Closes the XQuery results stream. Only use this method after
calling readResults.
* @param session DFC session identifier that has to be established (connected)
* @throws DfException
*/
public void close (IDfSession session) throws DfException;
/**
* Writes the XQuery results to a file.<P>
* @param filename The path to the file where the results are written
*/
public void getXMLFile (String filename) throws DfException;
/**
* Writes the XQuery results to an OutputStream object.<P>
* The method will flush the outputstream after the results are written.
* The outputstream is not closed by this method.
* @param outputStream The output stream in which the results are written
*/
public void getXMLOutputStream (OutputStream outputStream) throws DfException;
/**
* Returns the XQuery results as a Java String object.<P>
* @return The result in a Java String

Queries
*/
public String getXMLString () throws DfException;
/**
* Returns the XML query results as a DOM.<P>
* The DOM may not be wellformed depending on the XQuery semantics.
* @return The result as a DOM (class Document)
*/
The interface provides the following different ways to fetch results:

• Write the XQuery results to a file
• Get the results in an OutputStream object
• Get the results as a Java String object
• Get the results as DOM. XQuery syntax is flexible which may result in a DOM result
that is not well‑formed XML. For example, a query can result is a fragment or an
atomic value.
• Get the results incrementally using readResults(). The incremental reading of results
is useful when the full result size is too large and needs a large chunk of memory.
This option returns results in a byte array that is passed as an argument. The exact
number of bytes written in this array, is returned by readResults() as an integer
quantity. Since the size of the byte array is defined before invoking readResults(), it is
not guaranteed that a given sub‑set of results in the buffer represents a well‑formed
XML document. This is true even if the query returns a well‑formed XML document.
Example using readResults()
Following example shows a typical way to incrementally use readResults().
1. Create a new DFC client and get a new IDfXQuery object.

IDfClientX clientx = new DfClientX();
IDfXQuery xquery = clientx.getXQuery();
2. Set the XQuery string on xquery object.

xquery.setXQueryString(
" for $i in doc('/6300019f80000167/0600019f80050d3d')/billing_statements/
customer_entry[total_charges < 600] return $i" );
3. Add all the stores against which the query should be run.
xquery.addStore("xhive_store_01");
xquery.addStore("xhive_store_02");
4. Execute the query

xquery.execute(session);

Queries
5. Fetch results iteratively.

byte[] buffer = new byte[SIZE];
ByteArrayOutputStream bostream = new ByteArrayOutputStream();
6. Read results in a buffer and write the buffer to the output stream.
amount_read = xquery.readResults(buffer);
bostream.write(buffer,0,amount_read);
7. If there are more results, fetch them in a loop and write to the output stream as a
buffer is read.
while (amount_read > 0){
amount_read = xquery.readResults(buffer);
bostream.write(buffer,0,amount_read);
The major advantage of using readResults() is to fix memory operation, even if the result
size is large. The drawback is that individual result chunks in the buffer cannot be
passed to another XML processor.
Invoking DQL query from XQuery: Documentum Extension function

local:dql()
It is possible to invoke a DQL query from XQuery at run‑time. A new extension function
has been added to XML Store that can be invoked through XQuery. This function returns
DQL query results as an XML document.
Here is a simple example:
declare function local:dql($query as xs:string) as documentnode
(element(root)) external;
for $i in local:dql(
“ SELECT r_object_id, i_contents_id FROM dm_document
WHERE folder('/MyProject’, DESCEND)”
) /root
return $i//i_contents_id
Note that the i_content_id is extracted from the output of local:dql() using an XPath
expression. Also, each XQuery expression using this function must declare it as an
external function.
Local:dql() is a Java extension function implementing the interface
XhiveXQueryExtensionFunctionIf.

Queries
iAPI interface
XQueries can also be run through the iAPI interface by using the xquery iAPI command.
This allows the user to run XQueries directly without going through the DFC IDfXQuery
interface. Note that the iAPI xquery command runs against all xml storage areas with
no ability to programmatically specify a specific xml store to search against. However,
if the user is familiar with the Xhive library structure and the xml store object ids, the
xquery can be written to limit the documents searched. It is also limited to returning
results in a file specified in the command – there is no ability to return the results in other
forms available in DFC.
Syntax: dmAPIGet(ʺxquery,session,file_name,query_stringʺ)
Argument Descriptions:
ArgumentDescription
sessionIdentifies an open repository session
file_nameDefines the location of the file where you want to put your xquery results
query_stringThe query to run against xml stores in xquery syntax
Sample usage:
API> xquery,c,C:/xquery_results.xml,for $article in
/chapter[@number=1]//article return{data($article/para)}
Sample usage of limiting search against a particular xml store using xquery collection
function (xml store id is 6300019f800001ad:
API> xquery,c,c:\xquery_content.xml,for $i in collection("/6300019f800001ad")
let $j := $i//chapter[@number = 2] return $j

Queries

Chapter 6
Transformations
This chapter provides information on transforming XML documents for various purposes. It contains
the following sections:
• Overview, page 79
• Transformation support in DFC, page 80
• Summary of using XSLT stylesheets to build documents dynamically, page 82
• The NewsML XSLT stylesheet, page 85
Overview
Transformation is a process that converts an XML document into another XML document,
an HTML document, or a text document. The transformation capabilities supported in
DFC and XSLT stylesheets allow you to accomplish tasks such as the following:
• Transform a document from one format to another
• Create a rendition of a document
• Transform a document from one schema to another
• Combine chunked XML content from the repository with an XML aggregation
template
• Change a document’s content
To perform a transformation, you provide an XML document and an XSLT stylesheet to
the Xalan XSL transformation engine that is packaged by Documentum in dfc.jar. The
output is a document with markup that is specified by the XSLT style sheet.
Both the XML document and the stylesheet can contain XDQL queries, which can be
used to extract chunked XML objects from a repository. For a description of XDQL,
see Queries with XDQL, page 71. For a summary of using XDQL in XSLT stylesheets,
see Summary of using XSLT stylesheets to build documents dynamically, page 82. For
a detailed example using the NewsML case study, see The NewsML XSLT stylesheet,
page 85.

Transformations
Transformations are implemented through the IDfXMLTransformOperation interface

in DFC. You can invoke the transformation from a Java application, COM application,
through document lifecycles, or through methods. For more information on using DFC
to implement transformations, see Transformation support in DFC, page 80.
Transformation support in DFC

The execute method of the IDfXMLTransformOperation interface uses the Xalan
transformation engine and the specified XSLT stylesheet to transform an XML file
or document. It places the output into a new document or attaches it to the original
document as a rendition. It can also output an object of type IDfFile or any java.io.Writer
or java.io.OutputStream stream.
Example 61. Transform to an HTML file

Transform the file C:/NewsMLNewsletter.xml into an HTML file C:/NewsMLNewsletter.
htm, using an XSLT stylesheet from the repository.
void testTransformXml2HtmlUsingStylesheetObject(
IDfClientX clientx, // for operation factory
IDfSession session, // required for transformation
IDfDocument docStylesheet ) // XSL stylesheet in repository
throws DfException, IOException
{
IDfXMLTransformOperation transform =
clientx.getXMLTransformOperation();
transform.setSession( session );
transform.setTransformation( docStylesheet );
FileOutputStream out =
new FileOutputStream( "C:\NewsMLNewsletter.htm" );
transform.setDestination( out );
IDfXMLTransformNode node = (IDfXMLTransformNode)
transform.add( "C:\NewsMLNewsletter.xml" );
if( node == null )
{ // See the DFC documentation on handling manipulation errors.
}
node.setOutputFormat( "html" );
// Execute the operation
if( !transform.execute() )
}
}
Example 62. Transform to an HTML file, import result into repository

Transform the file C:/NewsMLNewsletter.xml into a new HTML document in the
repository, using the XSLT stylesheet C:/NewsMLStylesheet.xsl, and import it into the
repository.
void testTransformationXml2UsingStylesheetFile(

Transformations
IDfId idDestFolder ) // dest folder id

throws DfException
{
IDfXMLTransformOperation opTransform =
opTransform.setSession( session );
opTransform.setTransformation( "C:/NewsMLStylesheet.xsl" );
IDfImportOperation opImport = clientx.getImportOperation();
opImport.setSession( session );
opImport.setDestinationFolderId( idDestFolder );
opTransform.setDestination( opImport );
IDfXMLTransformNode nodeTransform = (IDfXMLTransformNode)
opTransform.add( "C:/ContractInfo.xml" );
if( nodeTransform == null )
}
// Specify the output format
// (NOTE: on the transform node, not the import node).
nodeTransform.setOutputFormat( "html" );
if( !opTransform.execute() )
}
}
Example 63. Transform an XML document into an HTML rendition

Transform an XML document into an HTML rendition, using an XSLT stylesheet from
the repository.
void testTransformationXml2HtmlRendition(
IDfDocument docXml, // root of the XML document
IDfDocument docStylesheet ) // XSL stylesheet in repository
throws DfException
{
IDfXMLTransformOperation opTransform =
opTransform.setSession( session );
opTransform.setTransformation( docStylesheet );
IDfXMLTransformNode nodeTransform =
(IDfXMLTransformNode) opTransform.add( docXml );
if( nodeTransform == null )
}
// To make a rendition, don't call setDestination(), and
// set the output format to be different from the input format.
// Specify the output format
// (NOTE: on the transform node, not the import node)
nodeTransform.setOutputFormat( "html" );
if( !opTransform.execute() )
}
}

Transformations
Special considerations for XML transform operations

When creating XML transformations, you should follow the general steps for
manipulating documents that are described in the Documentum Foundation Classes
Development Guide manual.
You must use the operation’s setSession method to specify a repository session. This
operation requires a session, even if all of the files it operates on are on the file system.
The add method of an IDfXMLTransformOperation object accepts Java types as well as
Documentum types. It allows you to specify the file to transform as an object of any of
the following types:
• IDfDocument
• IDfFile
• String (for example ʺC:/PhoneInfo.xmlʺ)
• InputStream
• Reader
• URL
Summary of using XSLT stylesheets to build

documents dynamically
You can build documents dynamically during a transformation by accessing XDQL
through XSLT Java extensions. The methods in XDQL return an XDQL query result
encoded as a DOM (Document Object Model), which can be converted by the Xalan
node‑set function for further processing with XPath expressions in the stylesheet.
The following logic of executing XDQL queries from within an XSLT stylesheet will
not vary much, so you can use these examples as templates. See the case study in The
NewsML XSLT stylesheet, page 85 for a detailed example of an XSLT stylesheet that
constructs an HTML newsletter from an XML document that serves as an aggregation
template, plus chunked XML objects from the repository.
In order to execute XDQL queries, you must do the following in your XSLT stylesheet.
• Declare the Java and Xalan node‑set namespaces in the <xsl:stylesheet> start tag:
<?xml version="1.0" encoding="UTF8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:java="http://xml.apache.org/xslt/java"
xmlns:xalannodeset="http://xml.apache.org/xalan"
version="1.0">

Transformations
• Declare any parameters being passed to the stylesheet, such as session ID (see
Passing and using parameters in the stylesheet, page 84):
<xsl:param name="DMS_SESSION_ID"/>
• Use a named template that passes XDQL parameters, instantiates the Java class,
and executes the XDQL query:
<xsl:template name="XDQL">
<xsl:param name="dql"/>
<! Create and init xdql class and specify dql query >
<xsl:variable name="clientx" select=
<xsl:variable name="xdql" select="java:getXmlQuery($clientx)"/>
<xsl:variable name="init" select="java:init($xdql)"/>
<xsl:variable name="param" select=
"java:setDql($xdql, $dql)"/>
<xsl:variable name="includeContent" select=
"java:includeContent($xdql,true())"/>
<xsl:variable name="setContentEncoding" select=
"java:setContentEncoding($xdql,'dom')"/>
<xsl:variable name="setContentFormat" select=
"java:setContentFormat($xdql,'xml')"/>
<xsl:variable name="rootNode" select=
"java:setRootNode($xdql, 'xdql')"/>
<xsl:variable name="execute" select="java:execute($xdql,
'DF_READ_QUERY', $DMS_SESSION_ID)"/>
<xsl:copyof select="$myResult"/>
</xsl:template>
• Use two <xsl:variable> elements (nested within the <xsl:template> that will hold the
content) to build a DQL query and call the XDQL template:
<xsl:variable name="myQuery">select * from newsml_component
where role='Main' </xsl:variable>
<xsl:variable name="myResult">
<xsl:calltemplate name="XDQL">
<xsl:withparam name = "dql" select=
"string($myQuery)"/>
</xsl:calltemplate>
</xsl:variable>
Note: A typical error in parameter definition is to not define a string parameter. For
example, the following definition is incorrect:
<xsl:param name="LinkBase"/>
When the template calls the setLinkBase method, Xalan assumes the parameter type
as a tree fragment, rather than a string. The correct definition should be:
<xsl:param name="LinkBase" select="string('http://someURL')"/>

Transformations
• Within the same <xsl:template> element, use the xalan‑nodeset function to convert
result trees into node‑sets to further manipulate the XML content with XPath
expressions:
<xsl:foreach select="xalannodeset:
nodeset($myResult)//object/content/NewsComponent">
<p>
<a name="{@Duid}"/>
<xsl:applytemplates select=".//Description|.//
Genre|.//HeadLine|.//SubHeadLine|.//ContentItem|
.//ByLine|.//CreditLine|.//DateLine|.//
NewsLineText"/>
</p>
</xsl:foreach>
</xsl:template>
Passing and using parameters in the stylesheet

Any of the following parameters can be declared and passed by DFC into the stylesheet.
• To reference the current session: DMS_SESSION_ID (passed from the setSession()
method of IDfXMLTransformOperation)
• To reference the current object id: DMS_INPUT_OBJECT_ID (passed from the add()
method of IDfXMLTransformOperation)
• To reference the object ID of the stylesheet: DMS_STYLESHEET_OBJECT_ID (passed
from the setTransformation() method of IDfXMLTransformOperation)
Besides these parameters, you can use the setXSLTParameter() method of
IDfXMLTransformOperation to pass other parameters into the stylesheet.
The values for these parameters are passed by DFC to the stylesheet. In the case where
DFC does not pass these values (for example, when the input or stylesheet is a file,
rather than an object), then the value of the parameter will be whatever default value is
specified in the stylesheet.
For example, the DMS_SESSION_ID parameter is declared in the following line.
<xsl:param name="DMS_SESSION_ID"/>
This parameter is then used in the line that executes the XDQL query:
In the following example, the parameter DMS_INPUT_OBJECT_ID is declared, and the

default value is defined as the string ’default value’, for cases in which DFC does not pass
these values (when the input is a file rather than an object).
<xsl:param name="DMS_INPUT_OBJECT_ID" select="'default value'"/>

Transformations
Then a variable is defined called ’myQuery’, whose value is a query string that uses the
value of the DMS_INPUT_OBJECT_ID parameter. The variable is then used to set a
parameter on the ’XDQL’ template, called ’dql’.
<xsl:variable name="myQuery">select r_object_id, cp_department_name_long
from cp_webcontent(all) where r_object_id = '<xsl:valueof
select="$DMS_INPUT_OBJECT_ID"/>'</xsl:variable>
<xsl:withparam name="dql" select="string($query1)"/>...
Tip: You can use <xsl:copy‑of> instructions as a debugging tool when you want to check
the values of parameters and other variables at particular points in the stylesheet. This is
helpful in cases when you expect DFC to pass a parameter, but instead the output is the
default value that was defined in the select clause of a parameter declaration (such as
select=ʺ’default value’ʺ).
The NewsML XSLT stylesheet

This section continues the NewsML case study presented throughout this manual by
illustrating how an HTML newsletter could be produced by using an XML input file as
an aggregation template for NewsComponent content chunks, which are dynamically
returned from the repository by means of an XDQL query embedded in an XSLT
stylesheet. The XML input file (XML document to produce NewsML newsletter, page
297) serves as a shell for the newsletter, containing a static title and introduction. The
XSLT stylesheet converts these static portions of the newsletter into HTML, queries the
repository for NewsComponent content chunks from the repository, creates a table of
contents from the NewsComponent headlines, and inserts the article content from the
NewsComponent chunks with HTML markup.
To view the entire stylesheet without annotations, see Appendix E, Source Files for
NewsML Sample.
Line 1 contains the XML declaration.
1 <?xml version="1.0" encoding="UTF8"?>
Line 2 contains the root element of the stylesheet.

2 <xsl:stylesheet
Line 3 contains the namespace declaration for the stylesheet.

3 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
Line 4 declares the Java format namespace, to enable Java calls from the XSL stylesheet.
4 xmlns:java="http://xml.apache.org/xslt/java"
Lines 5‑6: The Xalan transformation engine contains a built‑in extension function called
nodeset(), which allows a result tree fragment to be converted to a node‑set data type,

Transformations
allowing it to be processed further. To use this function, you must declare the Xalan
namespace, which in this example is declared with the prefix xalan‑nodeset.
5 xmlns:xalannodeset=
6 "http://xml.apache.org/xalan"
7 version="1.0">
Line 8 specifies how the result tree will be written to the output file. The method
attribute specifies in this case that the output format will be HTML. The indent attribute
specifies whether or not the output should be indented to reflect hierarchical structure.
In this case, it will not.
8 <xsl:output method="html" indent="no"/>
Line 11 declares the session ID as a parameter, in order to to be able to run queries and
retrieve results from the Content Server.
9 <! the Documentum Session ID is passed in, save it in a
10 variable>
11 <xsl:param name="DMS_SESSION_ID" select="'default value'"/>
Note: The select=ʺ’default value’ʺ clause is optional, since a session ID should always be
declared in the transform operation. For more information, see Transformation support
in DFC, page 80 and Passing and using parameters in the stylesheet, page 84.
Lines 12‑25: This template is an instruction for the <newsletter> element in the static
XML file. The template provides the HTML markup and specifies where to get the
content. Line 16 specifies that the value of the <title> element in the static XML file
should be inserted in the <title> tag inside the <head> section of the HTML markup.
Line 19 specifies that the same title should be inserted in the <h1> tag inside the <head>
section of the HTML markup. Line 21 specifies that the content of the <intro> tag in the
static XML file should be inserted into the HTML <p> tag.
Line 22 specifies that the parser move to the child node <Topics> in the static XML file
and then search the stylesheet for all templates that apply to this element.
12 <xsl:template match="newsletter">
13 <html>
14 <head>
15 <! grab the value of the title element in input xml>
16 <title><xsl:valueof select="title"/></title>
17 </head>
18 <body>
19 <h1><xsl:valueof select="title"/></h1>
20 <! grab the intro >
21 <p><xsl:valueof select="intro"/></p>
22 <xsl:applytemplates select="Topics"/>
23 </body>
24 </html>
25 </xsl:template>
26
Lines 27‑62 provide the instructions on how to obtain and mark up the section of the
HTML page that will contain a title, a table of contents of the topics that will appear, and
the topics themselves. Since this template is rather large, it will be discussed in parts.

Transformations
Line 28 specifies that the content of the <topictitle> element, which is a child of <Topics>
in the static XML file, should be inserted in an <h2> tag in the HTML markup. In this
case, the <topictitle> element contains the text ʺToday’s Headlines.ʺ
27 <xsl:template match="Topics">
28 <h2><xsl:valueof select="topictitle"/></h2>
Lines 30‑37 provide the instructions for how the content chunks will be obtained. Lines
30‑31 run the DQL query and store the result to the variable myQuery. Line 32 declares
the variable myResult, whose value will be provided by the template function that
follows. Because no value is provided, this variable is set by the parser as the current
output location. to which the results of the template function will be copied. Line 33 calls
the template function named XDQL (see lines 118‑138). Lines 34‑35 declare a variable
named dql, store the string result of the DQL query as the value, and pass that variable
as a parameter to the XDQL template function.
29 <! Build a query to get all Main News Components >
30 <xsl:variable name="myQuery">select * from newsml_component
31 where role='Main' </xsl:variable>
32 <xsl:variable name="myResult">
33 <xsl:calltemplate name="XDQL">
34 <xsl:withparam name = "dql" select=
35 "string($myQuery)"/>
36 </xsl:calltemplate>
37 </xsl:variable>
38
Lines 41‑48 set up the HTML tags to display each of the <headline> elements of the
NewsComponent chunks in an <h3> tag in the HTML markup, with a link to the anchor
for the actual topic, which appears lower on the page.
Lines 41‑42 initiate the instruction to process the set of nodes returned for the
NewsComponent chunks in the template function, after conversion from a result tree
to a node‑set data type. Lines 43‑47 put the contents of the <headline> element in the
node‑set into an <h3> tag in the HTML markup, and a link is constructed from the Duid
attribute of the NewsComponent element, which will link to the anchor of the same
name that will be constructed for the topic itself. This process repeats for each object
in the node‑set, extracting the headline and building the link, until the list of topics is
completed in the HTML result tree.
39 <! Build the Table of Contents links >
40
41 <xsl:foreach select="xalannodeset:
42 nodeset($myResult)//object">
43 <h3>
44 <a href="#{./content/NewsComponent/@Duid}">
45 <xsl:valueof select="HeadLine"/>
46 </a>
47 </h3>
48 </xsl:foreach>
49

Transformations
Lines 51‑60 set up the HTML markup to display each of the NewsComponent chunks.
Lines 51‑52 initiate the instruction to process the set of NewsComponent nodes returned
from the XDQL query, after conversion from a result tree to a node‑set data type. Line
53 builds a <p> tag in the result tree, and Line 54 constructs an anchor, the name of
which is the value of the Duid attribute of the current <NewsComponent> element that
is being considered. Line 55 instructs the parser to move through the descendants of
the <NewsComponent> node until any of the named elements is reached (Description,
Genre, HeadLine, and so on), then search the stylesheet for the template that matches
this element.
50 <! Now include Article Content >
51 <xsl:foreach select="xalannodeset:
52 nodeset($myResult)//object/content/NewsComponent">
53 <p>
54 <a name="{@Duid}"/>
55 <xsl:applytemplates select=".//Description|.//
56 Genre|.//HeadLine|.//SubHeadLine|.//ContentItem|
57 .//ByLine|.//CreditLine|.//DateLine|.//
58 NewsLineText"/>
59 </p>
60 </xsl:foreach>
61 </xsl:template>
62
Lines 63‑114 contain the templates that provide instructions for how to mark up
particular descendants of <NewsComponent> in HTML. In each template, the
<xsl:apply‑templates/> element instructs the parser to move to the first child node and
search the stylesheet again for any relevant templates. If no relevant template is found,
the parser has a built‑in template that contains the instruction <xsl:apply‑templates/>,
which causes the parser to continue to the next node. The parser moves in a node‑to‑leaf
fashion. When it reaches the end of a leaf, it backs up to the parent and moves to its
next child.
Line 115 is the close tag for the template that began at Line 27.
63 <xsl:template match="HeadLine">
64 <p><b><font size="5"><xsl:valueof select="HeadLine"/>
65 <xsl:applytemplates/>
66 </font></b></p>
67 </xsl:template>
68
69 <xsl:template match="SubHeadLine">
70 <p><b><font size="3">
71 <xsl:valueof select="SubHeadLine"/>
73 </font></b></p>
74 </xsl:template>
75
76 <xsl:template match="CreditLine">
77 <font color="gray">
78 <font size="2">,
79 <xsl:valueof select="CreditLine"/>

Transformations
81 </font>
82 </font>
83 </xsl:template>
84
85 <xsl:template match="DateLine">
86 <font color="gray" size="2">, <br></br>
87 <xsl:valueof select="DateLine"/>
89 </font>
90 </xsl:template>
91
92 <xsl:template match="NewsLineText">
93 <font color="Blue" size="2"><br></br>
94 <xsl:valueof select="NewsLineText"/>
96 </font>
97 </xsl:template>
98
99 <xsl:template match="ByLine">
100 <font color="gray" size="2">
101 By
102 <xsl:valueof select="ByLine"/>
104 </font>
105 </xsl:template>
106
107 <xsl:template match="ContentItem">
108 <p>
110 </p>
111 </xsl:template>
112
113 <xsl:template match="Comment | Genre">
114 <sup/>
115 </xsl:template>
116
117
Lines 118‑138 define the XDQL template function.

118 <xsl:template name="XDQL">
Line 119: The dql parameter was defined in Lines 34‑35 as the string value of the query
statement.
119 <xsl:param name="dql"/>
Lines 120‑121 creates a new query object and assigns it to the variable xdql, so that
it can be used in the methods to follow.
120 <xsl:variable name="clientx" select=
121 <xsl:variable name="xdql" select="java:getXmlQuery($clientx)"/>
Lines 122‑136 call various methods of the DfXmlQuery class by declaring variables
and assigning values that call the DfXmlQuery methods through the Java namespace.

Transformations
Except for the xdql variable, which is used to represent the query object in the method
parameters, the other variables that are declared are used for no further purpose.
Note: Java methods are called through an XPath function call, which requires an extra
first parameter. For purposes of querying the repository, the first parameter will always
be the variable that represents the query object (in this case, the variable xdql).
Line 122 calls the init() method to set default values and initializes DfXmlQuery class.
122 <xsl:variable name="init" select="java:init($xdql)"/>
Lines 123‑124 call the setDql() method, using as parameters the variables xdql (the new
query object), and dql (the query string). This method sets the DQL expression.
123 <xsl:variable name="param" select=
124 "java:setDql($xdql, $dql)"/>
Lines 125‑126 call the includeContent() method, which will include the content with
the result for the query object.
125 <xsl:variable name="includeContent" select=
126 "java:includeContent($xdql,true())"/>
Lines 127‑128 call the setContentEncoding() method to specify that the returned content
will be encoded as DOM (Document Object Model).
127 <xsl:variable name="setContentEncoding" select=
128 "java:setContentEncoding($xdql,'dom')"/>
Lines 129‑130 call the setContentFormat() method to set the repository format to be
used, in this case XML.
129 <xsl:variable name="setContentFormat" select=
130 "java:setContentFormat($xdql,'xml')"/>
Lines 131‑132 call the setRootNode() method, which sets the root node‑tag for the
returned DOM. In this case, the root node tag is specified as ʺxdqlʺ.
131 <xsl:variable name="rootNode" select=
132 "java:setRootNode($xdql, 'xdql')"/>
Lines 133‑134 call the execute() method, which executes the DQL query and loads
the result DOM to the xdql query object. The mode parameter is specified as
DF_READ_QUERY, and the session parameter is specified as DMS_SESSION_ID, which
was included as a parameter in Line 11.
133 <xsl:variable name="execute" select="java:execute($xdql,
134 'DF_READ_QUERY', $DMS_SESSION_ID)"/>
Line 135 uses the <xsl:copy‑of> instruction to perform a deep copy of the result tree
fragment in myResult to the current output location, which is the variable declared
in Line 32.
135 <xsl:copyof select="$myResult"/>
136 </xsl:template>

Transformations
137 </xsl:stylesheet>

Transformations

Appendix A
Reference Information and Examples
for Config_6.5.dtd
The following sections provide reference information and examples for config_6.5.dtd:
• XML source notation, page 93
• Internal parameter entities, page 94
• Elements declared in config_6.5.dtd, page 96
The XML application configuration file is itself an XML document and must conform to one of the
DTDs provided by Documentum with the Default XML Application (for this release, config_6.5.dtd).
The XML DTDs are stored in /System/Applications/Default XML Application.
XML source notation

In Elements declared in config_6.5.dtd, page 96, each Source section contains the
declaration of an element and any attributes from the config_6.5.dtd file. This
declaration provides important information about how to construct the XML application
configuration file. If you are not familiar with DTD notation, consult a basic XML
reference.
Symbols
Table 9, page 93 provides basic information about symbol notation.
Table 9. Valid symbols in document type definitions (DTDs)
Symbol Description
+ 1 or more occurrences

Reference Information and Examples for Config_6.5.dtd
Symbol Description
? 0 or 1 occurrence
* 0 or more occurrences
A|B A or B (but not both)
Attribute notation
Attributes are declared with the following notation.
attribute_name attribute_type optional_default_value>
There are only two attributes types used for attribute declarations in config_6.5.dtd:
• CDATA: a string
• (A | B | C): an enumerated‑type list of all possible values
These attribute declarations contain one of four default values:
• #REQUIRED: the attribute value must be provided along with the element.
• #IMPLIED: if no value is provided, the application must use its own default.
• #FIXED ʺvalueʺ: the attribute will always take the value in quotation marks.
• ʺvalueʺ: the attribute will take the value in quotation marks if no other value is
provided.
Internal parameter entities

The following parameter entries are used in a number of elements defined in
config_6.5.dtd.
• map_rule_content
• template‑format

map_rule_content
map_rule_content
Purpose Parameter entity that defines a list of elements that can be used as children of
elements whose primary purpose is to map content from an XML document onto
repository objects and metadata.
Source
<!ENTITY % map_rule_content "

(variables?
, location*
, owner_name?
, object_name?
, ((acl_name, acl_domain?) | default_acl)?
, object_type?
, business_policy?
, metadata? )">

templateformat
templateformat
Purpose Specifies that the content of an element can contain any combination of static
text, variables (using the <var> element), or XPath expressions (using the
<expression> element).
Source
<!ENTITY % templateformat "(#PCDATA| var | expression)*">
Elements declared in config_6.5.dtd

The following elements are declared in config_6.5.dtd. They are listed in alphabetical
order.
• <acl_domain>, page 99
• <acl_name>, page 101
• <allow_work_in_progress>, page 103
• <application>, page 105
• <app_pattern>, page 107
• <attribute_exist_test>, page 109 ‑ Reserved for future use.
• <attribute_test>, page 110
• <attribute_value_of_element>, page 111
• <attr_name>, page 113
• <business_policy>, page 115
• <child_of>, page 117
• <content_of_element>, page 118
• <content_of_this_element>, page 120
• <context_rule>, page 121
• <date_format>, page 122
• <dctmattr>, page 124
• <dctmattr_repeating>, page 126
• <dds_validation>, page 129
• <default>, page 131

templateformat
• <default_acl>, page 132

• <descendant_of>, page 134
• <element>, page 136
• <element_selection_pattern>, page 138
• <encode_reserved_XML_chars>, page 143
• <entity_rule>, page 141
• <expression>, page 145
• <external_variable>, page 147
• <external_variables>, page 149
• <format_attr>, page 150
• <java_class>, page 151
• <java_classes>, page 154
• <link_rule>, page 155
• <link_target>, page 161
• <link_template>, page 163
• <location>, page 165
• <make_entity>, page 167
• <map_rules>, page 169
• <metadata>, page 171
• <name>, page 173
• <non_xml_content_rule>, page 174
• <object_name>, page 177
• <object_type>, page 179
• <occurrence>, page 181
• <owner_name>, page 182
• <path>, page 184
• <permanent_link>, page 187
• <policy_name>, page 188
• <policy_scope>, page 189
• <policy_state>, page 191
• <pub_id>, page 193
• <schema>, page 195
• <suppress_output_of_default_attributes>, page 197
• <sys_id>, page 199
• <tagname_of_element>, page 201
• <template>, page 203

templateformat
• <this_element>, page 204

• <two_way_dctmattr>, page 205
• <two_way_dctmattr_repeating>, page 209
• <validation>, page 211
• <value>, page 213
• <var>, page 214
• <variable>, page 216
• <variables>, page 220
• <version_label>, page 221
• <xml_content_rule>, page 224

<acl_domain>
<acl_domain>
Purpose Sets the domain (owner) of an ACL.
Diagram
Children
#PCDATA, var, expression
Parents
entity_rule, link_rule, non_xml_content_rule, xml_content_rule
Usage notes
The <acl_domain> element must co‑occur with the <acl_name> element to specify the
ACL owner when you want to set a public or private ACL, rather than a system ACL.
The value of <acl_domain> must match the name of the owner who created the ACL
specified in <acl_name>. This value of <acl_domain> will populate the acl_domain
repository property for the chunked object. If the <acl_domain> element is not present,
the default for acl_domain is the repository owner (appropriate for a system ACL).
The <acl_domain> element can contain any combination of static text, variables (using
the <var> element), or expressions (using the <expression> element).
You can specify an alias for <acl_domain>. For more information, see the Usage notes
for <owner_name>.
Example of <acl_domain>
<acl_name>somePublicACL</acl_name>

<acl_domain>
<acl_domain>ownerNameOfPublicACL</acl_domain>
Source
<!ELEMENT acl_domain %templateformat;>

<acl_name>
<acl_name>
Purpose Specifies the ACL (permissions) for the object.
Diagram
Children
Parents
Usage notes
ACLs define permissions for an object: which users can access an object and what level
of access the users have. ACLs can be system ACLs (created by the repository owner), or,
combined with the <acl_domain> element, they can be public or private ACLs (created
by an individual user). The <acl_name> element allows you to assign a system ACL
(created by the repository owner) to the chunked object.
Note: If <acl_name> is used without <acl_domain>, then the value must be a system ACL.
The value of <acl_name> should be the name of an existing ACL object. The <acl_name>
element can contain any combination of static text, variables (using the <var> element),
or expressions (using the <expression> element). The value of this element will populate
the repository property acl_name for the object being created. If this element is not
present, the system assigns the default repository security to the object.
You can specify an alias for <acl_name>. For more information, see the Usage notes
for <owner_name>.

<acl_name>
For information on ACLs, see Documentum Content Server Fundamentals Guide.

Note: This element cannot be used with <default_acl>, which assigns one of the
Documentum default ACLs.
Source
<!ELEMENT acl_name %templateformat;>

<allow_work_in_progress>
Purpose Allows the XML document to bypass well‑formedness and validation checks.
Diagram
Children
None
Parents
application
Usage notes
If present, then if parsing fails due to non‑well‑formedness or failure to validate, the

XML document will be imported or checked in as a simple document (no virtual
document structure will be created). The purpose of this feature is to allow early storage
of XML documents that may fail if parsed.
Note:
• All XML documents must be well‑formed up to at least the root element; otherwise,
it is not possible to determine which XML application should apply.
• Once an XML application has successfully applied to a document, the
<allow_work_in_progress> feature becomes inoperative.
• This element cannot be used in conjunction with <dds_validation>.
Documents that are well‑formed and validate against a DTD or W3C schema (if
validation if being used) will be chunked and stored in the usual fashion on import.

A symbolic version label must be supplied using the version_label attribute of this
element. This allows work‑in‑progress documents to be identified in the repository
more easily.
Caution: Version_label can refer to different things. The version_label attribute of

the <allow_work_in_progress> element assigns a symbolic version label, such as
ʺDraftʺ or ʺApprovedʺ. The value of the <version_label> element will assign a
binding rule to an existing symbolic version label.
In the following example, all eligible XML documents will be imported as simple
documents and assigned the version label WORK IN PROGRESS. Once these documents
are checked out and checked in for the first time, the XML application will apply in
the normal fashion.
Example of <allow_work_in_progress>
<allow_work_in_progress version_label="WORK IN PROGRESS"/>
Tip: An alternative way to bypass the parser during checkin is to add the following line
in the XML document after the XML declaration:
Source
<!ELEMENT allow_work_in_progress EMPTY>

<!ATTLIST allow_work_in_progress
version_label CDATA #REQUIRED
>

<application>
<application>
Purpose The root element in the XML application configuration file.
Diagram of <application>
Children
name, app_pattern, allow_work_in_progress, validation, dds_validation,

java_classes, external_variables, suppress_output_of_default_attributes,
encode_reserved_XML_chars, map_rules
Parents
Root element

<application>
Usage notes
This element is the root element in the XML application configuration file. It contains
the following elements:
• <name>: specifies a name for the XML application.
Note: The value of <name> must match the name of the XML application and the
name of the XML application configuration file, and it must be unique within the
repository system.
• <app_pattern>: contains the identifier information that determines whether this XML
application will apply to an XML document.
• <allow_work_in_progress>: if present, allows the XML document to bypass
validation when the document is imported or checked in.
• <validation>: if present, tells the parser to run in validating mode.
• <dds_validation>: if present, specifies validation against the server data dictionary.
• <java_classes>: allows Java classes to be invoked.
• <external_variables>: allows the use of variables that are external to the XML
document.
• <suppress_output_of_default_attributes>: specifies that default attributes that are
not specified in the XML instance should not be written into the XML that is stored
in the repository.
• <encode_reserved_XML_chars>: specifies that the five reserved XML characters
(ampersand, less than, greater than, apostrophe, and quotation mark) are to be
encoded.
• <map_rules>: contains the rules that specify how to process an XML document.
Source
<!ELEMENT application (name, app_pattern, allow_work_in_progress?,

validation?, dds_validation?, java_classes?, external_variables?,
suppress_output_of_default_attributes?, encode_reserved_XML_chars?,
map_rules)>

<app_pattern>
<app_pattern>
Purpose Container element for identifier information that is used for application detection.
Diagram
Children
sys_id, pub_id, schema, element
Parents
application
Usage notes
The <app_pattern> element is required, but all of its children are optional. This element
does not affect how the XML application functions, but information about the system
identifier, public identifier, schema, or root element is used by Documentum Application
Builder (DAB) to populate fields in the user interface when creating an XML application.
The children of <app_pattern> correspond to specific XML application folder properties,
which are used by Documentum for DTD and schema management and to determine
whether the XML application will apply to a particular XML document.

<app_pattern>
• <sys_id>: The system identifier in the DOCTYPE declaration of the XML document,
which specifies the path and name of the DTD. Corresponds to the DTD System Id
property of the XML application folder. For more information, see <sys_id>.
• <pub_id>: The public identifier, if there is one. Corresponds to the DTD Public Id
property of the XML application folder. For more information, see <pub_id>.
• <schema>: Specifies the schema name, if a schema is referenced in the XML
document. Corresponds to the Namespace or Schema property of the XML
application folder.
• <element>: Specifies all of the elements that are eligible to be root elements in an
XML document to which the XML application should apply. Corresponds to the
Root Elements property of the XML application folder.
In the following example, if the elements in <app_pattern> contain values that correspond
to the properties set for the XML application folder, then the XML application will apply
to an XML document only if all of the following are true:
• The system identifier in the <!DOCTYPE> declaration in the XML document is
cellphone.dtd
• The public identifier in the <!DOCTYPE> declaration in the XML document is
‑//Documentum//DTD CellPhoneInlineEntity//EN
• The possible root elements of the XML document are <cellphone‑catalog>, <model>,
or <description>.
Example of <app_pattern>
<app_pattern>
<sys_id>cellphone.dtd</sys_id>
<pub_id>//Documentum//DTD CellPhoneInlineEntity//EN</pub_id>
<element>cellphonecatalog</element>
<element>model</element>
<element>description</element>
</apppattern>
Source
<!ELEMENT app_pattern (sys_id?, pub_id?, schema?, element*)>

<attribute_exist_test>
<attribute_exist_test>
Purpose Reserved for future use.
Diagram
Children
attr_name
Parents
element_selection_pattern
Source
<!ELEMENT attribute_exist_test (attr_name)>

<!ATTLIST attribute_exist_test attr_exists (true | false) "true">

<attribute_test>
<attribute_test>
Purpose Used to test the value of an attribute for a specified element.
Diagram
Children
attr_name, value
Parents
Usage notes
This element allows you to specify that a rule or action should only apply to an element
only when one or more attributes have the values you specify. The element to which
the attribute belongs is specified in the parent <element_selection_pattern>). For more
information, see <attr_name> and <value>.
Example of <attribute_test>
See the example for <element_selection_pattern>.
Source
<!ELEMENT attribute_test (attr_name, value)>

<attribute_value_of_element>
Purpose Gets the attribute value of an element in the XML document to store to a variable.
Diagram
Children
this_element, element_selection_pattern, attr_name
Parents
variable
Usage notes
This element gets an attribute value for a specified element in the XML document. This is
the way that an attribute value in the XML document can be extracted and used for a
purpose such as assigning a folder or path name or populating a repository property.
Suppose you have a <procedure> element that distinguishes installation procedures
from procedures related to use of the product with the role attribute, as in <procedure
role=ʺinstallʺ> and <procedure role=ʺuseʺ>. The following example stores the value of
the role attribute in the <procedure> element in the XML document to a variable called
procedureType.
Example of <attribute_value_of_element>
<xml_content_rule>
<element_selection_pattern>

<element>procedure</element>
</element_selection_pattern>
<variable>
<name>procedureType</name>
<this_element/>
<attr_name>role</attr_name>
</attribute_value_of_element>
<default>Attribute Unspecified</default>
</variable>
...chunking portion of rule...
</xml_content_rule>
Source
<!ELEMENT attribute_value_of_element ((this_element |

element_selection_pattern), attr_name)>

<attr_name>
<attr_name>
Purpose The name of the attribute whose value will be determined.
Diagram
Children
#PCDATA
Parents
attribute_test, attribute_value_of_element, link_target
Usage notes
This element is a reused content model that requires static text as its content. The value
specifies the name of an attribute in the XML document, and the use to which this
information is put depends on the context in which <attr_name> occurs.
The <attr_name> element has one attribute called namespaceURI, which can be used to
further qualify the attribute that is being specified in the XML document.
In the following example, the <attr_name> element is used to identify an attribute called
MyAttribute, prefixed with a namespace called nspref, defined in the document as
xmlns:nspref=ʺhttp://www.nspref.com/ʺ. This could be used, for example, to extract
content from an attribute such as the following:
<somechunk nspref:MyAttribute="ExampleValue">
See also the examples for <element_selection_pattern> and <link_rule> for use of the
<attr_name> element.

<attr_name>
Example of <attr_name>
<attr_name namespaceURI="http://www.nspref.com/">
MyAttribute
</attr_name>
Source
<!ELEMENT attr_name (#PCDATA)>

<!ATTLIST attr_name
namespaceURI CDATA #IMPLIED
>

<business_policy>
<business_policy>
Purpose Associates a business policy (document lifecycle) with an object.
Diagram
Children
policy_name, policy_scope, policy_state
Parents
Usage notes
The <business_policy> element attaches a document lifecycle to the object.

Note: The document lifecycle must exist in the repository into which the XML document
is imported.
The <business_policy> element contains the following three children in the following
order:
• <policy_name>: specifies the name or object ID of the document lifecycle and its
location in the repository.
• <policy_scope> (optional): specifies the scope of the document lifecycle.
• <policy_state>: specifies the initial state of the document lifecycle

<business_policy>
For example, here is the rule in the cellphone example that attaches the objects created
from <model> elements to a document lifecycle:
Example of <business_policy>
<xml_content_rule>
...
<business_policy>
<policy_name>/System/Applications/CellPhoneSampleApp/
Cell_Phone_Lifecycle</policy_name>
<policy_scope>CellPhoneSampleApp</policy_scope>
<policy_state>Review</policy_state>
</business_policy>
...
</xml_content_rule>
Source
<!ELEMENT business_policy (policy_name, policy_scope?,

policy_state)>

<child_of>
<child_of>
Purpose Specifies the name of the parent element.
Diagram
Children
Parents
context_rule
Usage notes
The element named as the value of the <child_of> element must be a parent to the
element that is the focus of <element_selection_pattern>. To be a child, there can be no
intervening nodes between the element and its parent. If there are intervening nodes,
use <descendant_of>.
Example of <child_of>
Source
<!ELEMENT child_of (element_selection_pattern)>

<content_of_element>
Purpose Gets the content of an element in the XML document to store to a variable.
Diagram
Children
this_element, element_selection_pattern
Parents
variable
Usage notes
This element is used when a variable is defined. It gets the content of the element
in the XML document that is specified in its child element, either <this_element> or
<element_selection_pattern>. This is the way that content in the XML document can be
extracted and used for a purpose such as assigning a folder or path name or populating a
repository property.
Example of <content_of_element>
See the example for <variable>.

Source
<!ELEMENT content_of_element
(this_element | element_selection_pattern)>
<!ATTLIST content_of_element subelement_option
(include_content | include_content_and_markup) #IMPLIED>
Note: The include_content_and_markup value for the subelement_option attribute is

not supported for DFC 6.0.

<content_of_this_element>
<content_of_this_element>
Purpose Specifies that the content of the current element will be used as the link target.
Diagram
Children
None
Parents
<link_target>
Usage notes
This element is used in a Link Rule to specify that the name and location of a linked file
(such as a graphic) can be obtained from the element that is the target of the Link Rule.
Example of <content_of_this_element>
See the example for <link_target>.
Source
<!ELEMENT content_of_this_element EMPTY>

<context_rule>
<context_rule>
Purpose Specifies the structural context in which an element must occur for a rule to apply.
Diagram
Children
child_of, descendant_of
Parents
Usage notes
The <context_rule> element specifies that an element in the XML document must be a
child or descendant of another element. This allows you to add context sensitivity to a
target element. See <child_of> and <descendant_of> for more information.
Example of <context_rule>
Source
<!ELEMENT context_rule (child_of | descendant_of)>

<date_format>
<date_format>
Purpose Specifies the date format that will be applied to extracted XML content and
assigned to a repository date property.
Diagram
Children
#PCDATA
Parents
dctmattr, dctmattr_repeating, two_way_dctmattr, two_way_dctmattr_repeating
Usage notes
The <date_format> element specifies a date format that will be applied to any content
extracted from an XML document and used to populate a repository date property.
Without the <date_format> element present, the date will be set using the date format of
the locale of the machine on which DFC is processing the XML document. This would
cause a problem, for example, if the XML application were being processed by several
application servers using different locales.
Note: All XML documents that are processed against the XML application must have
their dates in the format specified in <date_format>. If the date is specified in a different
format, the date will be set using the date format of the locale of the machine on which
DFC is processing the XML document.
Supported date formats are specified in the Java class SimpleDateFormat. For more
information, see http://java.sun.com/j2se/1.3/docs/api/java/text/SimpleDateFormat.html

<date_format>
Example of <date_format>
<metadata>
<dctmattr>
<name>myCustomDateAttr</name>
<template><var name="myDate"/></template>
<date_format>MMddyyyy</date_format>
</dctmattr>
</metadata>
Source
<!ELEMENT date_format (#PCDATA)>

<dctmattr>
<dctmattr>
Purpose Sets the value of a single‑value repository property.
Diagram
Children
name, template, date_format, encode_reserved_XML_chars
Parents
metadata
Usage notes
The <dctmattr> element uses the following two children to assign values to repository
metadata:
• <name>: the name of the repository property
• <template>: the value the will be assigned to the repository property
• Not Implemented: <encode_reserved_XML_chars>: not implemented.
Note: If a rule is used to set a repository property, and the user manually sets that
property through a client application, the user’s value will be overwritten when the
document is checked in. If you wish to change repository properties directly and have
them propagate back to the XML document, use <two_way_dctmattr>.

<dctmattr>
In the following example, the following single‑value repository properties are set:
• catalog_name: set with the static text Cell Phone Catalog.
• model_name: set with the value of the variable modelName
• title: set using a combination of static text and variables
If the values of variables gathered from the XML document are
brandName=ʺDeNovoʺ, modelName=ʺSuperChargerʺ, and price=ʺ95000ʺ, then the
repository property called title will be assigned the following value:
DeNovo(model SuperCharger)$95000
Note: The variables modelName, brandName, and price must be defined higher up
in the <xml_context_rule> with the <variables> element. See <xml_content_rule> and
<two_way_dctmattr> for examples.
Example of <dctmattr>
<metadata>
<dctmattr>
<name>catalog_name</name>
<template>Cell Phone Catalog</template>
</dctmattr>
<dctmattr>
<name>model_name</name>
<template><var name="modelName"/></template>
</dctmattr>
<dctmattr>
<name>title</name>
<template><var name="brandName"/>(model <var name=
"modelName"/>)$<var name="price"/></template>
</dctmattr>
</metadata>
Source
<!ELEMENT dctmattr (name, template, date_format?, encode_reserved_XML_chars?)>

<dctmattr_repeating>
Purpose Sets the values of a multivalue (repeating) repository property.
Diagram
Children
name, template, date_format, encode_reserved_XML_chars
Parents
metadata
Usage notes
See <dctmattr> for general usage information. This element should be used for repeating
properties in the repository.
The rule in the following example has the following characteristics:
• It chunks on the <book> element.
• It declares the variable called firstName and assigns it the value of each <firstname>
element in the XML document. If the <firstname> element has no value, it assigns the
value ʺUnspecifiedʺ for that occurrence.

• It declares the variable called lastName and assigns it the value of each <lastname>
element in the XML document. If the <lastname> element has no value, it assigns the
value ʺUnspecifiedʺ for that occurrence.
• It assigns the repeating repository property with the string ʺfirstname lastnameʺ, for
each value stored in that variable. For example, suppose the XML document had
the following elements:
<author>
<firstname>Joe</firstname>
<lastname>Smith</lastname>
</author>
<author>
<firstname>Mary</firstname>
<lastname>Jones</lastname>
</author>
Then, given the rule in the example, the values of the repeating repository property
authors would be as follows:
authors[0]Joe Smith
authors[1]Mary Jones
In this example, the DTD or W3C schema for the XML document should require both a
<firstname> and <lastname> element for every <author> element. If one of these elements
were missing, the firstName and lastName variables would not contain an equal number
of values, resulting in an incorrect concatenation for the repository property.
Example of <dctmattr_repeating>
<xml_content_rule>
<element>book</element>
<variables>
<variable>
<name>firstName</name>
<element>firstname</element>
</content_of_element>
<default>Unspecified</default>
</variable>
<variable>
<name>lastName</name>
<element>lastname</element>
</variable>
</variables>
<metadata>
<name>authors</name>

<template><var name="firstName"> <var name="lastName"></template>

</dctmattr_repeating>
</metadata>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT dctmattr_repeating (name, template, date_format?)>

<dds_validation>
<dds_validation>
Purpose If present, specifies that each object that is created or checked in will be validated
with the data dictionary on the server.
Diagram
Children
None
Parents
application
Usage notes
Use the <dds_validation> element only if additional validation by the data dictionary is
required beyond the rules enforced by your DTD or schema. The data dictionary is a
repository of information in the repository about object types and properties.
If this element is present, then all objects and repository properties extracted from the
XML document will be validated against the data dictionary when they are imported
or checked in. At the object type level, validation is done for check constraints and
certain flags, such as is_immutable. At the attribute level, validation is done for check
constraints, value assistance, format_pattern, and flags such as read‑only, is_immutable,
and is_required.
Failure to pass data dictionary validation will result in varying behavior depending on
the context of the failure. In some instances, failure to pass data dictionary validation
causes save or checkin operations to fail. In other instances, failure displays a dialog
asking the user to pick a value.
Note:

<dds_validation>
• All objects that compose the document are validated. It is not possible to validate
a subset of the objects.
• Data dictionary validation runs in UTF‑8 mode.
• This element should contain no content.
• There is a performance cost associated with this type of validation. The length of
time required for the import or checkin operation increases with the number of
objects and the amount of information that must be validated. It is a best practice to
use your own DTD to validate attribute values in the XML document, rather than
validating against the Content Server data dictionary.
• You cannot use this element together with <allow_work_in_progress>.
For information about defining data dictionary information, refer to Documentum Content
Server Fundamentals Guide.
Example of <dds_validation>
<dds_validation/>
Source
<!ELEMENT dds_validation EMPTY>

<default>
<default>
Purpose Specifies the value that is assigned to a variable if no value is found in the XML
document.
Diagram
Children
#PCDATA
Parents
external_variable, variable
Usage notes
This element is an optional child of elements that define and assign values to variables.
Example of <default>
Source
<!ELEMENT default (#PCDATA)>

<default_acl>
<default_acl>
Purpose Assigns one of the Documentum default ACLs.
Diagram
Children
None
Parents
Usage notes
This element is always empty but uses its attribute value to assign the ACL of a chunked
object to one of the Documentum default ACLs:
• FOLDER
This is the default ACL associated with the object’s primary folder, in which the
object is first stored when it is created. If the object was placed directly in a cabinet,
the server uses the ACL associated with the cabinet as the folder default.
• TYPE
This is the ACL associated with the object’s type Every object type has an ACL
associated with its type definition. You can use that ACL as a default ACL for any
object of the type.
• USER
This is the ACL associated with the object’s creator Every user object also has an
ACL. It is not used to provide security for the user but only as a potential default
ACL for any object created by the user.

<default_acl>
• NONE
If this element is not present, the default is ʺNONEʺ.
Note: The <default_acl> and <acl_name> elements cannot be used together.
Example of <default_acl>
<default_acl value="FOLDER"/>
Source
<!ELEMENT default_acl EMPTY>

<!ATTLIST default_acl
value (FOLDER | TYPE | USER | NONE) "NONE"
>

<descendant_of>
<descendant_of>
Purpose Specifies the name of an ascendant element.
Diagram
Children
Parents
context_rule
Usage notes
The element named as the value of the <descendant_of> element must be an ascendant
to the element that is the focus of <element_selection_pattern>. The ascendant can be
a parent, grandparent, or any higher ascendant. For a more restrictive context rule,
use <child_of>.
Suppose that you only wanted to chunk procedures when they appeared in an appendix.
The following example shows the portion of an <xml_content_rule> that specifies that
the <procedure> element in the XML document will trigger the rule, but only when it is a
descendant of the <appendix> element.
Example of <descendant_of>
<xml_content_rule>
<context_rule>
<descendant_of>
<element>appendix</element>

<descendant_of>
</descendant_of>
</context_rule>
...
</xml_content_rule>
Source
<!ELEMENT descendant_of (element_selection_pattern)>

<element>
<element>
Purpose Specifies the name of an element in the XML document, for purposes determined
by the context.
Diagram
Children
#PCDATA
Parents
app_pattern, element_selection_pattern
Usage notes
This element is a reused content model that requires static text as a value. It is used as
the generic identifier or tag name of an element. When used in <app_pattern>, it is used
to identify elements that can be considered the root element in a document processed
by the application. When used in <element_selection_pattern>, its use depends on the
context in which <element_selection_pattern> appears.
The value of the attribute associated with <element>, namespaceURI, is the URI part
of a namespace that may be associated with the element. See the example for the
<attr_name> element.
Example of <element>
See <element_selection_pattern>.

<element>
Source
<!ELEMENT element (#PCDATA)>

<!ATTLIST element
namespaceURI CDATA #IMPLIED
>

Purpose Specifies the context for a target element in a rule.
Diagram
Children
element, context_rule, occurrence, attribute_test
Parents
attribute_value_of_element, child_of, content_of_element, descendant_of, link_rule,

non_xml_content_rule, tagname_of_element, xml_content_rule
Usage notes
This is a container element that is used to specify the name of an element occurring in an
optional context. It is used for various purposes, depending on its parent element, as
the following table show.
The <element_selection_pattern> element contains the following children, in the
following order:
• <element>: specifies the element in the XML document that will be selected.

• <context_rule>: if present, specifies that the element will be selected only when it
is a child or descendant of another specified element.
• <occurrence>: if present, specifies that the named element must be the nth occurrence
of this element within this parent.
• <attribute_test>: if present, specifies that the element will be selected only if one or
more attributes of that element have particular values.
There are some restrictions on the elements that can be named in the <element> portion
of <element_selection_pattern>, as shown in Table 10, page 139.
Table 10. Content of <element_selection_pattern>
When <element_selection_pattern> is a The value of <element> in

child of: <element_selection_pattern> should be:
• <xml_content_rule> The element that will trigger the rule.

(Use <this_element> to denote the current
• <link_rule>
element)
• <non_xml_content_rule>
• <content_of_element> A descendant of the element that triggers

the rule. (Use <this_element> to denote
• <attribute_value_of_element>
the current element. Use <child_of> or
• <tagname_of_element> <descendant_of> if the element is a
grandchild or even further removed from
the element that triggers the rule.)
• <child_of> The parent of the current element.
• <descendant_of> An ascendant of the current element.
The following example is written to create a chunk for the introduction chapter of a
book. It specifies that the element that will trigger the rest of the rule must have the
following characteristics:
• <element> specifies that the element in the XML document that will trigger the rule is
the <chapter> element.
• The namespaceURI attribute of <element> specifies that the <chapter> element
belongs to the namespace at URI http://www.documentum.com/book.xsd. For
example, if the namespace was defined with the prefix dctm, then this rule would
apply to <dctm:chapter>.
• <child_of> specifies that the rule will only apply when <chapter> is a child of the
<book> element.
• <attribute_test> specifies that the rule will only apply when <chapter> contains an
attribute called chapter_type with the value ʺintroductionʺ.
Because location is not specified, the chunk will be created in the same location as the
parent chunk.

Example of <element_selection_pattern>
<xml_content_rule>
<element namespaceURI="http://www.documentum.com/book.xsd">chapter
</element>
<context_rule>
<child_of>
</child_of>
</context_rule>
<attribute_test>
<attr_name>chapter_type</attr_name>
<value>introduction</value>
</attribute_test>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT element_selection_pattern (element, context_rule?,

occurrence?, attribute_test*)>

<entity_rule>
<entity_rule>
Purpose Specifies how Documentum processes external parsed entities.
Diagram
Children
location, owner_name, object_name, acl_name, acl_domain, default_acl, object_type,

business_policy
Parents
map_rules

<entity_rule>
Usage notes
Use this element if the XML document to be imported to the repository has external
parsed (XML) entities that need to be preserved when exported or checked out. The
entity will be stored as a component of the XML virtual document in the repository. If
any <xml_content_rule> applies to an element in the entity, the entity will become a
virtual document itself, with its own chunked components. However, <entity_rule>
ensures that when the document is exported or checked out, the entity will be
reassembled into a single entity that is external to the XML container document.
Note: If you want to preserve entities on export or checkout, you cannot have an
<xml_content_rule> for any root element in an entity.
If this element is not present, external parsed entities are chunked following the
regular chunking rules and reassembled into a single document on export or checkout.
Normally, this element is not necessary, since the XML application would normally
eliminate the need to maintain external parsed entities.
In an Entity Rule you can optionally specify one or more locations for the entity, or an
owner name, object name, ACL information, object type, or business policy (document
lifecycle). You cannot specify a version label for an external parsed entity.
Note: An XML application can only contain one Entity Rule, and you cannot selectively
preserve some external parsed entities but not others.
Source
<!ELEMENT entity_rule (location*, owner_name?, object_name?, ((acl_name,

acl_domain?) | default_acl)?, object_type?, business_policy?)>

<encode_reserved_XML_chars>
Purpose Specifies that the five reserved XML characters (ampersand, less than, greater than,
apostrophe, and quotation mark) are to be encoded.
Diagram
Children
EMPTY
Parents
application, dctmattr, dctmattr_repeating, two_way_dctmattr, two_way_dctmattr_

repeating
Usage notes
In DTD versions prior to DFC 5.3, when dm_sysobject metadata is set through an XML
application, the five reserved XML characters (ampersand, less than, greater than,
apostrophe, and quotation mark) are decoded. We do this with the assumption that a
user is viewing the metadata, where seeing & is better than seeing &amp.
However, retrieval of metadata through XDQL queries and subsequent publishing of
the resulting XML may produce data that is not ʺwell‑formed,ʺ since the five reserved
XML characters are not encoded.
Using the encode_ reserved_XML_chars element, you can specify how you want the
special XML characters treated for metadata. This optional element is available in two
places:
• The <application> element level ‑‑ All metadata is affected.

• Not Implemented: The individual element (dctmattr, dctmattr_repeating,

two_way_dctmattr, two_way_dctmattr_repeating) level ‑‑ XML reserved characters
are only be encoded for the metadata of the individual elements that use the
encode_reserved_XML_chars element.
Example of <encode_reserved_XML_chars>
See the examples for <application> and for <dctmattr>, <dctmattr_repeating>,

<two_way_dctmattr>, and <two_way_dctmattr_repeating>.
Source
<!ELEMENT encode_reserved_XML_chars EMPTY>

<expression>
<expression>
Purpose Allows the use of XPath expressions and Java classes inside the XML application
configuration file.
Diagram
Children
#PCDATA, var
Parents
acl_domain, acl_name, link_template, object_name, object_type, owner_name, path,

policy_name, policy_scope, policy_state, template
Usage notes
This element allows the use of XPath syntax and XPath functions to manipulate variables
before they are used to set repository properties.
Both can be used.
Note the following limitations of the <expression> element:
• XPath functions cannot be called if they require a context (node‑set).
• The <expression> element cannot be used with <two_way_dctmattr> and
<two_way_dctmattr_repeating>.
See http://www.w3c.org/TR/xpath#section‑String‑Functions for a list of string functions
in the XPath specification.

<expression>
In the following example, the year is truncated from a date string before the variable is
used. If the variable effDate has the value ʺ2002/04/03ʺ, then the effective_date repository
property will be populated with the value ʺ04/03ʺ.
Note: You must use quotes around the <var> element if the value of <var> is a string.
However, if you were calling a function that took a boolean or integer parameter, the
quotes should not be used, as in the following:
substring("<var name="myName"/>", <var name="pos"/>)
Example of <expression>
<dctmattr>
<name>effective_date</name>
<template><expression>substringafter("<var name="effDate"/>", "/")
</expression></template>
</dctmattr>
Source
<!ELEMENT expression (#PCDATA | var)*>

<external_variable>
<external_variable>
Purpose Declares an external variable.
Diagram
Children
name, default
Parents
external_variables
Usage notes
This element is used for a variable that contains a value that comes from a source other
than the XML document, or a value that is hard‑coded. The value for each variable
named in an <external_variable> element is provided by the client by either of the
following two methods:
IDfImportNode:setExternalVariable(String key, String value)
IDfCheckinNode:setExternalVariable(String key, String value)
The IDfProperties object that is passed to this method will contain name/value pairs, and
the name of this object must correspond to an <external_variable> name.
The <external_variable> element contains two children:
• <name> specifies the name of the external variable.
• <default> specifies a value if the external variable is not present.

<external_variable>
In addition to values supplied by the client, there are default variables for user name,
the user’s home cabinet, the name of the repository, and the session ID. For more
information, see the usage notes for the <var> element.
In the following example, the external variable CITY is declared. To use this variable,
you would use the element <var name=ʺCITYʺ> wherever the <var> element can be used.
The default value would be used if the client did not pass in the variable as a value.
Example of <external_variable>
<name>Location1</name>
<app_pattern>
<element>cars</element>
</app_pattern>
<external_variables>
<external_variable>
<name>CITY</name>
<default>Vancouver</default>
</external_variable>
</external_variables>
...
</application>
The following example shows how a client could provide the values for the external
variables.
Example of how client provides values for external variable

setExternalVariable("CITY", "San Francisco");
importNode.setExternalVariables(p);
Source
<!ELEMENT external_variable (name, default)>

Purpose Container for a list of external variables.
Diagram
Children
external_variable
Parents
application
Usage notes
This element contains a list of <external_variable> elements, each specifying an external

variable.
Example of <external_variables>
See the examples for <external_variable>.
Source
<!ELEMENT external_variables (external_variable+)>

<format_attr>
<format_attr>
Purpose Specifies the format of the object created to store the content specified in a non‑XML
content rule.
Diagram
Children
#PCDATA
Parents
non_xml_content_rule
Usage notes
The <format_attr> element is used only in <non_xml_content_rule>. It specifies the

format in which the decoded data will be stored in Documentum.
Note: The value of <format_attr> should correspond to an existing format object in
the repository.
Example of <format_attr>
See the example for <non_xml_content_rule>.
Source
<!ELEMENT format_attr (#PCDATA)>

<java_class>
<java_class>
Purpose Allows custom Java code to be invoked.
Diagram
Children
None
Parents
java_classes
Usage notes
Each <java_class> element defines a Java class that can be called within a rule. In the
<java_class> definition, you must include the fully qualified package name of the Java
class.
The <java_class> element is always empty, but a value must be supplied for the two
attributes:
• prefix: the reference that is used to call methods (the instance of the class)
• classname: the fully qualified Java class name
To call methods, you use the prefix followed by the name of the method, separated by a
colon. If a method takes a parameter, you can pass it as shown in the first example below.
Note: The Java class must be installed on the system and must be accessible from the
class path.
See the examples below for more information on how Java classes can be used.
Note that the Java classes/methods that are declared in the XML application configuration
file have the following limitations:

<java_class>
• The methods that are called must return a String. For methods that do not return
a String, the value returned will be the String returned by the object’s toString()
method (for example, abc@4938).
• The default constructor of the object will be used. If an object requires information, it
must be passed as a parameter to the method.
• The Java methods should be static (stateless), since it is not guaranteed when the
object will be cleaned up.
• If the Java method throws an exception, the error will be reported as a SAXException
and will be translated into an IDfOperationError.
The details of the syntax are inherited from Xalan:
• http://xml.apache.org/xalan‑j/extensions.html
• http://xml.apache.org/xalan‑j/apidocs/org/apache/xalan/extensions/
ExtensionHandlerJavaClass.html
In the following example, two Java classes are declared, then several examples are
provided of their use in an <expression> element.
Example of <java_class>
<application>
...
<java_class prefix="math" classname="java.lang.Math"/>
<java_class prefix="random" classname="java.util.Random"/>
...
</application>
<template><expression>math:sin(0.7)</expression></template>
<template><expression>math:sin('<var name="somevar"/>')
<template><expression>random:nextInt(random:new(),10)
The following example shows the use of chaining, in which a Java method is called and
passes the output of another method as a parameter.
Example of chaining
<dctmattr>
<name>title</name>
<template><expression>myClass:bar(myClass:baz())
</dctmattr>
If the Java method needs to access the repository, you can pass the external variable
called DF_SESSION as a parameter. The following example demonstrates passing the
session ID.

<java_class>
Example of passing sessionID as a parameter

<dctmattr>
<name>title</name>
<template><expression>myClass:bat("var name="DF_SESSION"/>")
</dctmattr>
The ʺjavaʺ namespace has been predefined, allowing you to access methods in the Java.*
packages. This means that you do not have to declare the classes in the <java_classes>
element. Either class can be referenced by using the prefix (java:) and the fully‑qualified
class name, as shown in the following example.
Use of predefined namespaces for Java classes

<dctmattr>
<name>creation_date</name>
<template><expression>java:java.util.Date.new()
</dctmattr>
Source
<!ELEMENT java_class EMPTY>

<!ATTLIST java_class
prefix NMTOKEN #REQUIRED
classname CDATA #REQUIRED
>

<java_classes>
<java_classes>
Purpose Container for a set of <java_class> elements.
Diagram
Children
java_class
Parents
application
Usage notes
The <java_class> element allows you to invoke custom Java code. Each Java class is
specified with the <java_class> child element. See the <java_class> element for usage
information.
Example of <java_classes>
See the example for <java_class>.
Source
<!ELEMENT java_classes (java_class+)>

<link_rule>
<link_rule>
Purpose Specifies how Documentum recognizes and manages unparsed linked files and
NDATA entities for the XML application.
Diagram

<link_rule>
Children
element_selection_pattern, link_target, variables, location, owner_name, object_name,

acl_name, acl_domain, default_acl, object_type, business_policy, metadata;
version_label, permanent_link
Parents
map_rules
Usage notes
Link Rules specify how to handle unparsed external files that are linked from the XML
document or declared as NDATA entities. These external files can be of any file format.
Graphics files are a typical type of unparsed external file that would be handled by a
Link Rule.
The element that triggers the rule must contain the link, and the <link_target> portion
of the rule must specify whether the link is contained in the element content or as an
attribute value. How the linked file itself is handled on import depends on the form of
the link, as shown in Table 11, page 156.
Table 11. How linked files are handled
Form of link How Linked File Is Handled

Path to a file on the local system that is The XML virtual document adds a node
viewed or checked out from repository that points to the object in its original
repository location. If the linked file on
the local system was checked out from the
repository, it is checked in and deleted
from the local system.
Path to a file on the local system that is not The linked file is imported into the
viewed or checked out from repository repository and becomes a node in the
XML virtual document. The linked file
also remains on the local system after
import.

<link_rule>
Form of link How Linked File Is Handled

DRL The repository object referenced by the
DRL becomes a node in the XML virtual
document. (There is no file on the local
system.)
An entity attribute whose value is the The linked file is imported into the
name of an NDATA entity repository, with a node in the XML virtual
document. The linked file also remains on
the local system. Constraints:
Note:
• If the element content or attribute value does not specify a valid path name or DRL,
then the linked file will not be imported into the repository.
• You cannot use a URL as a link.
• If the link contains an anchor suffix (for example, example.htm#anchorname), the
entire file is imported, but the anchor link is preserved so that when the document is
downloaded this anchor link will continue to work correctly in the XML document.
• The linked file can be in XML format but will remain unparsed. (For parsed external
entities, use <entity_rule>.
These linked files are managed along with the XML document. When an XML document
is imported or checked in, any linked files that need to be imported are automatically
uploaded along with the document. The file format is detected by the repository, as long
as the format is one that is recognized by the Content Server. When an XML document is
checked out with descendants, all of the external files are placed in the same checkout
directory as the document. The links in the XML document are patched to point to the
checkout directory on the local system.
The <link_rule> element contains the following elements:
• <element_selection_pattern> specifies the name of the element that contains the link.
• <link_target> specifies whether the link can be found in the content of the element
or as an attribute value.
• A variety of optional elements allow you to specify the target repository location
for the linked file, the owner name, the object name, permissions, the object type,
a document lifecycle that will be attached to the object, or how the linked file’s
repository properties will be populated. These are specified the same way as for
an <xml_content_rule>.
Note: If you do not specify <object_name> in a link rule, the object created in the
repository will take on the file name specified in the link. (If the link includes a path,
it will be stripped off.)
• <version_label> allows the option to set a binding rule on import using an existing
symbolic version label.

<link_rule>
• <permanent_link> allows the option to set a permanent link in the repository.

Note: <make_entity> and <link_template> cannot be used with <link_rule>.
The link_rule element also has two attributes:
• peer_or_child: If this attribute is not present, the default value is ʺchildʺ, which is the
type of link usually used when the linked file (such as a graphic) is displayed within
the container document. Child links pull the linked document into the repository as
an object and make that object a component of the referencing object (which itself
becomes a virtual document).
If the attribute appears as peer_or_child=ʺpeerʺ, it specifies that one document
contains a link to another document. In this case, a user would have to click the link
in the document to open another file. The system pulls the referenced document into
the repository and creates a relationship of type xml_link between the referenced
document and the containing document. For more information on link relationships,
see the Documentum Object Reference Manual.)
• ndata=ʺtrueʺ: Specifies that the link is a reference to an NDATA entity declaration. If
the ndata attribute is not specified, the default value is ʺfalseʺ.
Link Rules for NDATA entities have the following constraints:
• In the XML document, the entity must contain an NDATA notation declaring the
file format. For example, the following entity declares the entity MyGraphic as
an image in GIF format:
<!ENTITY MyGraphic SYSTEM "MyGraphic.gif" NDATA GIF>
• Notation names in the entity declaration (such as GIF) must match a format defined
in the repository.
• The link to the external document must consist of the name of the NDATA entity in an
attribute that has been defined as type ENTITY. The element in which this attribute
appears must be the named in the <element_selection_pattern> of the Link Rule.
• The <link_rule> element must contain the attribute ndata=ʺtrueʺ.
See below for an example of a Link Rule for an NDATA entity.
More than one type of rule can apply to a single element. For example, an element might
contain both content and a link to an external file contained in an attribute. In this case,
an <xml_content_rule> could be used to chunk the element content, and a <link_rule>
could be used to import the image that is referenced within the attribute. These two
rules can occur in either order.
Examples of <link_rule>
This section contains the following examples

• Link is a local path and link target is an attribute value.

<link_rule>
• Link is the name of an NDATA entity and link target is contained in an entity
attribute.
• Link is a DRL and link target is element content.
The first example of <link_rule> has the following characteristics:
• <element_selection_pattern> specifies that the <graphic> element in the XML
document will trigger this rule, and the link is contained in this element.
• <link_target> specifies that the link is contained in the target element’s href attribute.
Here is an example of how the link to a file on the local system would look in the
XML document:
<graphic href="c:\Images\myImage.jpg"/>
This link could also be a DRL.
• <path> specifies that when the linked file is imported, it will be stored in the
Images folder, which should be a sibling of the folder in which the parent object is
stored. For example, suppose the parent of the <graphic> element is <figure>, and a
chunking rule for <figure> places the chunk in the Documents\Figures folder. The
relative path ..\Images will place any files linked from the <graphic> element into
the Documents\Images folder.
Example of <link_rule> when link target is attribute value
<link_rule>
<element>graphic</element>
<link_target>
<attr_name>href</attr_name>
</link_target>
<location>
<path>../Images</path>
</location>
</link_rule>
In the second example, suppose the following NDATA entity is declared in the XML
document for the MyGraphic.gif file:
<!ENTITY MyGraphic SYSTEM "MyGraphic.gif" NDATA GIF>
The following entity reference occurs in the XML content:
<graphic href="MyGraphic"/>
This assumes that the DTD has defined the href attribute as type ENTITY, such as in
the following declaration:
<!ELEMENT graphic EMPTY>
<!ATTLIST entityref ENTITY #IMPLIED>
The Link Rule would then be identical to that shown in the first example.
In the third example, the content of the <graphic> element in the XML document is used
as the link target. The <graphic> element could contain a path on the local system, but
in the following example it contains a DRL to a repository location, as in the following
example:

<link_rule>
<graphic>
dctm://scribblers3/0900270f8003ee6c?DMS_OBJECT_SPEC=
CHRONICLE_ID&DMS_VLAB=CURRENT
</graphic>
For information on how to construct and interpret DRLs, see Constructing DRLs, page 61.
Example of <link_rule> when link target is element content

<link_rule>
<link_target>
<content_of_this_element/>
</link_target>
...
</link_rule>
Source
<!ELEMENT link_rule (element_selection_pattern, link_target,

(%map_rule_content;), version_label?, permanent_link?)>
<!ATTLIST link_rule
peer_or_child (peer | child) "child"
ndata (true | false) "false"
>

<link_target>
<link_target>
Purpose Specifies whether the link in a Link Rule appears in the target element’s content
or in an attribute value.
Diagram
Children
attr_name, content_of_this_element
Parents
link_rule
Usage notes
This element is used to determine whether the link in a Link Rule can be found in the
target element’s content or in an attribute value. This is specified by the use of one of the
following child elements:
• <attr_name> specifies the name of an attribute in the XML document whose value
will contain the link.
• <content_of_this_element> specifies that the content of the target element of the
Link Rule will contain the link.
See the examples for <link_rule>.

<link_target>
Source
<!ELEMENT link_target (attr_name | content_of_this_element)>

<link_template>
<link_template>
Purpose Specifies that an XML chunk will be managed in the repository using a defined
link structure.
Diagram
Children
Parents
non_xml_content_rule, xml_content_rule
Usage notes
Specifies that a file created using <non_xml_content_rule> is managed in the repository

using a definable link structure, such as xlink or xinclude. It can contain any
combination of static text, variables (using the <var> element), or expressions (using the
Note: Currently <link_template> is only supported for use with <non_xml_content_rule>,
not with <xml_content_rule>.
Example of <link_template>
See the example for <non_xml_content_rule>.

<link_template>
Source
<!ELEMENT link_template %templateformat;>

<location>
<location>
Purpose Specifies the folder or cabinet in the repository in which a chunked object is stored.
Diagram
Children
path, object_type, metadata
Parents
Usage notes
This element contains three children with the following functions:

• <path> specifies a relative or absolute path in which an object is to be created.
• <object_type> specifies a custom folder type if a new folder is created. (The default
type is dm_folder.)
• <metadata> specifies values that will be assigned to specific folder properties.
If the <location> element is not present, then the path will be the same as for the parent
chunk. If it is the root element, the path is the one defined by the user during the import
or checkin operation.
You can link a chunked object to multiple folders by using more than one <location>
element in a single rule. If a rule for a child element also has multiple locations with
relative paths, each path is resolved using each of the different parent locations.

<location>
Example of <location>
See the example for <path>.
Source
<!ELEMENT location (path, object_type?, metadata?)>

<make_entity>
<make_entity>
Purpose Specifies that a chunked object has an inline relationship to its parent, when
downloaded with the parent.
Diagram
Children
None
Parents
xml_content_rule
Usage notes
This element specifies that when an XML document is checked out with its descendants,
the descendant chunks will come down ʺinline,ʺ which means that the descendant
chunks are incorporated into a single XML file, as opposed to single files for each chunk.
This element is currently a required child of <xml_content_rule>, which means that only
inline descendants are supported. You should always add it to a chunking rule.
Note:
• This element should contain no content.
• Whether a chunk is created for the element specified in an XML Content Rule
is determined by the make_object attribute of <xml_content_rule>, not by the
<make_entity> element.
Example of <make_entity>
See the example for <xml_content_rule>.

<make_entity>
Source
<!ELEMENT make_entity EMPTY>

<map_rules>
<map_rules>
Purpose Contains the rules that specify how to process an XML document in Documentum.
Diagram
Children
xml_content_rule, link_rule, non_xml_content_rule, entity_rule
Parents
application
Usage notes
This is a container element for the individual rules that determine how an XML
document is processed in Documentum. There are several types of rules, represented
by the following child elements:
• <xml_content_rule>: stores XML chunks

<map_rules>
• <link_rule>: recognizes links and manages linked files

• <non_xml_content_rule>: processes base64‑encoded data that is embedded in an
XML document
• <entity_rule>: if present, specifies how Documentum processes external parsed
entities. If <entity_rule> is present, then the first three elements may appear again
after <entity_rule>.
The declaration is written such that <entity_rule>, if present, can appear ahead of, in the
middle of, or at the end of any of the other rules.
Each rule contains an <element_selection_pattern>, and the rule is triggered when this
selection pattern is encountered in the incoming XML document. For example, a rule
with an element selection pattern <element>Model </element> is triggered whenever the
<Model> element appears in the XML document.
Note: Only one <entity_rule> element is allowed.
Source
<!ELEMENT map_rules ((xml_content_rule | link_rule |

non_xml_content_rule)*, (entity_rule, (xml_content_rule |
link_rule | non_xml_content_rule)*)?)>

<metadata>
<metadata>
Purpose Contains a list of elements that set single and repeating values of repository
properties.
Diagram
Children
dctmattr, dctmattr_repeating, two_way_dctmattr, two_way_dctmattr_repeating
Parents
link_rule, location, non_xml_content_rule, xml_content_rule
Usage notes
This is a container element. Values are set within the <metadata> element with the
following children:
• <dctmattr>: sets single‑value repository properties
• <dctmattr_repeating>: sets multivalue (repeating) repository properties
• <two_way_dctmattr>:
• <two_way_dctmattr_repeating>:
All repository properties that are named in an XML application configuration file
must be predefined, either as standard attributes or as custom attributes. The easiest

<metadata>
way to create custom object types and attributes in a repository is with Documentum
Application Builder.
Caution: The character entity references &, <, >, ' or &quot are
translated into actual characters in the metadata (&, <, >, ’, ʺ). These characters can
cause problems if the metadata are used in generating XML or HTML output.
Example of <metadata>
See the examples for <dctmattr>, <dctmattr_repeating>, <two_way_dctmattr>, and

<two_way_dctmattr_repeating>.
Source
<!ELEMENT metadata (dctmattr | dctmattr_repeating |

two_way_dctmattr | two_way_dctmattr_repeating)+>

<name>
<name>
Purpose Specifies the name of the XML application, the name of Documentum properties to
populate, or a variable name, depending on the parent element.
Diagram
Children
#PCDATA
Parents
application, dctmattr, dctmattr_repeating, external_variable, two_way_dctmattr,

two_way_dctmattr_repeating, variable
Usage notes
This element has no specific behavior. The content of this element depends on the
context in which it occurs.
Note: The value of <name> is case sensitive when used for variables.
Source
<!ELEMENT name (#PCDATA)>

<non_xml_content_rule>
Purpose Specifies how Documentum recognizes and manages non‑XML content that is
embedded in an XML document.
Diagram
Children
element_selection_pattern, variables, location, owner_name, object_name, acl_name,

acl_domain, default_acl, object_type, business_policy, metadata; format_attr,
link_template

Parents
map_rules
Usage notes
This element is used to extract base64 data from the XML document. The base64
data is decoded and imported as a separate object. For example, a Word document
could be included in the XML document by encoding it in base64. When the
<non_xml_content_rule> triggers, it will create an object for the base64 data and replace
the data with a link in the parent document, defined in the <link_template> element.
Note:
• This element currently supports only base64‑encoded data, and the encoding
attribute does not need to be specified, since ʺbase64ʺ is the default.
• Once the base64‑encoded data is decoded, it is maintained as a separate file with a
link from the XML document.
You can control how this object is handled in the repository in the same way as for
<xml_content_rule>.
• <element_selection_pattern> specifies that the <mybase64ref> element in the XML
document will trigger the rule.
• Since the <location> element is not present, the decoded base64 object will be created
in the same directory as the parent document.
• <format_attr> specifies that crtext is the file format type in which the resulting
decoded data will be stored in Documentum.
• <link_template> is obligatory and specifies that the link will be maintained separately
from its parent. Since angle brackets are part of the content of this element, the
open and close tags must be specified using character entities, rather than as
markup. The <var name=ʺlocationʺ> serves as a placeholder for the file name of the
imported (and decoded) base64 data. For example, if the name of the object created
was someFile.doc, the following content would be inserted into the XML parent
document at the location from which the base64 data was extracted:
<mybase64ref>someFile.doc</mybase64ref>
Note: The location variable that is used as a placeholder in <link_template> does not
need to be declared. If <var name=ʺlocationʺ> is used in any other element besides
<link_template> it will be treated as a regular variable and must be declared before it
can be used.
Example of <non_xml_content_rule>

<element>mybase64</element>
<format_attr>crtext</format_attr>
<link_template>&lt;mybase64ref ref="<var name="location"/>"&gt;
&lt;/mybase64ref&gt;</link_template>
</non_xml_content_rule>
Source
<!ELEMENT non_xml_content_rule (element_selection_pattern,

(%map_rule_content;), format_attr, link_template)>
<!ATTLIST non_xml_content_rule
encoding (base64 | text) #FIXED "base64"
>

<object_name>
<object_name>
Purpose Specifies the name of the object to be used.
Diagram
Children
Parents
Usage notes
The <object_name> element can contain any combination of static text, variables (using
Note: You can use Unicode characters in object names.
If <object_name> is not specified in a rule, a name is created for the chunked object
based on the name of the element being chunked plus a unique series of numbers. The
exception is <link_rule>, which defaults to the name of the linked file.
Example of <object_name>
See the example for <xml_content_rule>.

<object_name>
Source
<!ELEMENT object_name %templateformat;>

<object_type>
<object_type>
Purpose Specifies what object type should be used for the chunk.
Diagram
Children
Parents
entity_rule, link_rule, location, non_xml_content_rule, xml_content_rule
Usage notes
If <object_type> is not specified, dm_document is used. The value of <object_type> can

contain any combination of static text, variables (using the <var> element), or expressions
(using the <expression> element). However, the value must match the name of an
existing Documentum or custom object type in the repository.
Note: If you specify a custom object type, this custom type must have already been
created in the repository.
The object type must be SysObject or a subtype. When <object_type> is used with the
<location> element, the object type can be dm_cabinet, dm_folder, or a custom subtype.
When <object_type> is used to create objects chunked from the XML document (for
example, as a child of <xml_content_rule>), the object type is most often dm_document
or a custom subtype, but it can be any SysObject or SysObject subtype except for
a cabinet or folder.

<object_type>
In the following example, the new object will be created as a document of custom type
sop_doc.
Example of <object_type>
<xml_content_rule>
...
<object_type>sop_doc</object_type>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT object_type %templateformat;>

<occurrence>
<occurrence>
Purpose Tests that an element is the nth occurrence of all elements of the same name.
Diagram
Children
#PCDATA
Parents
Usage notes
This element contains a number value that specifies that it is the nth occurrence of that
element within its direct parent.
Example of <occurrence>
Source
<!ELEMENT occurrence (#PCDATA)>

<owner_name>
<owner_name>
Purpose Specifies the name of the owner of the object.
Diagram
Children
Parents
Usage notes
The <owner_name> element can contain any combination of static text, variables (using
the <var> element), or expressions (using the <expression> element). The value will
populate the repository property called owner_name. If the <owner_name> element is
not present, it defaults to the name of the user who imports the XML document.
Note: If you include an <owner_name> element, all users who have Version or Write
permission on documents processed with the application must also have Change Owner
permission on those documents. Each time a user saves or checks one of the documents,
the system attempts to reset the owner_name. The Save or Checkin operation fails if the
user does not have the appropriate permission to set that attribute.
You can specify an alias for <owner_name> using the following format:
%[alias_set_name.]alias_name
in which square brackets means that the element is optional. This means that you can
set an alias name as in either of the following examples:

<owner_name>
<owner_name>
%engr_aliases.engr_vp
</owner_name>
<owner_name>
%engr_vp
</owner_name>
For more information on aliases, see the Documentum Object Reference Manual.
Suppose that the owner of a document is defined in your XML document in the
following way:
<book owner="John Doe">
The following example extracts this owner name from the owner attribute in the XML
document and assigns it to the ownerName variable.
Example of <owner_name>
<xml_content_rule>
...
<variables>
<variable>
<name>ownerName</name>
<default>Owner Unspecified</default>
</variable>
</variables>
<owner_name><var name="ownerName"/></owner_name>
...
</xml_content_rule>
Source
<!ELEMENT owner_name %templateformat;>

<path>
<path>
Purpose Specifies the path of a folder.
Diagram
Children
Parents
location
Usage notes
The value of <path> can be any combination of static text, variables (using the
<var> element), or expressions (using the <expression> element).
Note: The value of <path> is case‑sensitive for folder creation. For example, if the folder
name is extracted from an XML element, the element content myFolder and MyFolder
would result in the creation of two separate folders, one named myFolder and one
named MyFolder.
Both relative and absolute paths can be specified. A full path takes the following form:
/cabinet/folder1/folder2...
If a relative path is specified, it will be relative to the primary location of the parent
chunk. Relative paths are similar to those in DOS, as in these examples:
• folder1: Specifies a child of the parent chunk location.
• folder1/folder2: Specifies a grandchild of the parent chunk location

<path>
• ../folder1: Specifies that folder1 is parallel to the parent chunk location

If there is no parent chunk (in other words, if the target element is the root chunk), then
the path will be the cabinet or folder selected on the import or checkin operation.
If the folder path does not exist in the repository, it will be created. See <location> for
information on specifying a custom object type or adding properties to the folder that
is created.
You can specify an alias for <path>. For more information on aliases, see the Usage
notes for <owner_name>.
You can also specify the object ID or the DRL of a folder, rather than a path. You will
have to modify the object ID value or DRL if you replicate or install the XML application
into another repository.
The following example uses a combination of static text and a variable to specify a
relative path. If the value of modelName were MX 3799, the relative path would be
Models/ModelName. This path would be concatenated to the path used for the parent
chunk.
Note: The value of the modelName variable must have been previously assigned within
an <xml_content_rule> element.
Example of <path>
<location>
<path>Models/<var name="modelName"/></path>
</location>
You can use a DRL to query for a particular folder. In the following example, the XML
chunk will be imported to a custom folder of type draft_folder, which has the custom
property project_status set to ʺDRAFTʺ. On import or checkin, the DRL for the location
is resolved to a folder that is returned by the query. If the query does not return an
object, the operation will fail.
Example of DRL as a value for <path>

<xml_content_rule>
...
<location>
<path>dctm://scribblers3/draft_folder where
project_status='DRAFT'?DMS_OBJECT_SPEC=PREDICATE</path>
</location>
...
</xml_content_rule>
You could also build the DRL from the XML itself through the use of the <var> element.
In the following example, the DRL is constructed from a combination of static text and a
variable called currStatus, defined earlier in the <xml_content_rule> element.

<path>
Example of DRL constructed with dynamic variable

<xml_content_rule>
...
<variables>
<variable>
<name>currStatus</name>
<element>status</element>
</variable>
</variables>
<location>
<path> dctm://dfcdev_solora/dm_folder where status=
'<var name="currStatus"/>'?DMS_OBJECT_SPEC=PREDICATE</path>
</location>
...
</xml_content_rule>
Source
<!ELEMENT path %templateformat;>

<permanent_link>
<permanent_link>
Purpose If present, sets permanent link to true in relation objects.
Diagram
Children
None
Parents
link_rule
Usage notes
This element is used only with relation objects. It is always empty, and, if present,
sets the permanent link to true. For further information on permanent links, see the
Documentum Object Reference Manual.
Note: This element is only effective when the link type is peer.
Example of <permanent_link>
<permanent_link/>
Source
<!ELEMENT permanent_link EMPTY>

<policy_name>
<policy_name>
Purpose Specifies the name or object ID of an existing business policy (document lifecycle).
Diagram
Children
Parents
business_policy
Usage notes
The value of <policy_name> can be either the name of a document lifecycle (including
the path) and its location in the repository.
Note: If you use an object ID instead of the document lifecycle name, you will have
to change the object ID if you replicate or install the XML application into another
repository.
Example of <policy_name>
See the example for <business_policy>.
Source
<!ELEMENT policy_name %templateformat;>

<policy_scope>
<policy_scope>
Purpose Specifies the scope of the business policy (document lifecycle).
Diagram
Children
Parents
business_policy
Usage notes
If the business policy (specified in the parent element <business_policy>) has one or
more alias sets listed in its alias_set_ids attribute, you can specify one from the list as the
object’s business policy scope or allow the server to choose one by default.
The <policy_scope> element optionally specifies the dm_alias_set property that is
associated with a dm_policy object. When the object is saved to the repository, the server
will use the business policy scope, if needed, to resolve any alias specifications found in
the object’s owner_name, acl_name, and acl_domain properties.
Note: The <policy_scope> element is optional.
The <policy_scope> element can contain any combination of static text, variables (using
Example of <policy_scope>

<policy_scope>
Source
<!ELEMENT policy_scope %templateformat;>

<policy_state>
<policy_state>
Purpose Specifies the initial state of the business policy (document lifecycle).
Diagram
Children
Parents
business_policy
Usage notes
This element specifies the initial state of the document lifecycle. It can contain any
combination of static text, variables (using the <var> element), or expressions (using the
Note: The value of <policy_state> should match the name of a document lifecycle state
defined in the document lifecycle itself. If you use a variable to assign a dynamic value
from the XML document, you should make sure that the name matches one of the
existing states in the document lifecycle.
Example of <policy_state>

<policy_state>
Source
<!ELEMENT policy_state %templateformat;>

<pub_id>
<pub_id>
Purpose Specifies the public identifier, if a public identifier is used as part of the document
type declaration in the XML document.
Diagram
Children
#PCDATA
Parents
app_pattern
Usage notes
This element specifies the public identifier, if used in the document type declaration of
the XML document, and if the XML application manages the DTD. This value should
correspond to the DTD Public Id property of the XML application folder. This element
is optional and currently has no function; see the <app_pattern> element for more
information
Note:
• The name of the DTD file must also be entered as the value of the DTD Public Id
property of the XML application folder in the repository to ensure correct DTD
management.
• Do not use this element if your XML documents contain only system identifiers.
A public identifier has the following format:
//Documentum//DTD CellPhoneInlineEntity//EN
It contains four sections, separated by double forward slashes:

<pub_id>
• A plus or minus sign to indicate whether or not the DTD is approved by a standards
organization
• the name of the owner
• the type of data described by the DTD
• An ISO 639 language identifier
The following example is based on the following document type declaration in an XML
document:
<!DOCTYPE book PUBLIC "//Arbortext//DTD DocBook XML V4.0//EN"
"axdocbook.dtd">
This public identifier is not approved by a standards body, is owned by Arbortext,
describes data validated by a DTD based on DocBook XML 4.0, and is written in English.
The final set of quotation marks contains the system identifier, which should be entered
as the value of <sys_id>.
Example of <pub_id>
<pub_id>//Arbortext//DTD DocBook XML V4.0//EN</pub_id>
Source
<!ELEMENT pub_id (#PCDATA)>

<schema>
<schema>
Purpose Specifies the name of the schema file, if managed by the XML application.
Diagram
Children
#PCDATA
Parents
app_pattern
Usage notes
If the XML application will manage a schema, the value of <schema> is the schema file
name. Do not include path information with the schema name. If you have a modular
schema, enter only the name of the root.
The XML application will apply only to XML documents whose root element contains the
schema name in the attribute xsi:SchemaLocation or xsi:noNamespaceSchemaLocation.
Note:
• Schemas are currently not managed by the XML application in the same way that
DTDs are. The schema on the local file system that is specified in the URI address in
the XML document will always be used by the parser during inbound and outbound
repository operations. However, it is good practice to store the schema in the XML
application folder and assign the schema name to the Schema property of the XML
application folder.
• To use a schema to validate documents when they are imported or checked in, the
<validation/> element must be present. For more information, see <validation>.

<schema>
The example below shows the use of the <schema> element when an XML document
contains the following document type declaration:
<book xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xsi:noNamespaceSchemaLocation=
"C:\xml_schema\test_schema.xsd">
...
</book>
Example of <schema>
<schema>test_schema.xsd</schema>
Source
<!ELEMENT schema (#PCDATA)>

<suppress_output_of_default_attributes>
Purpose Specifies that default attributes that are not specified in the XML instance should
not be written into the XML that is stored in the repository.
Diagram
Children
EMPTY
Parents
application
Usage notes
In DTDs (and probably schemas), you can define default attributes for elements. This
means that when a parser reads the element, it acknowledges attributes that may not
actually be present in the XML file. You may use default attributes to trigger XML
configuration rules or variables. The side effect of using these default attributes is that
the attributes are written into the content.
For example:
<root>blah</root>
The ATTLIST for root is:

ATTLIST root attr1 (foo | bar) "foo"
By default, the element has an attribute called attr1. When the parser calls startElement(),
the attr1 attribute is visible, even though it is not present in the parsed content. When
the content is serialized, the parser writes out exactly what was fed into it and includes

the attribute that wasn’t originally present. In many cases, including the attributes in
the XML output is unacceptable.
You can optionally instruct DFC not to serialize the default attributes using the
suppress_output_of_default_attributes element.
Example of <suppress_output_of_default_attributes>
See the example for <application>.
Source
<!ELEMENT suppress_output_of_default_attributes EMPTY>

<sys_id>
<sys_id>
Purpose Specifies the name of a DTD file that is managed by the XML application.
Diagram
Children
#PCDATA
Parents
app_pattern
Usage notes
This element specifies the name of the DTD that appears in the document type
declaration of the XML document (if the XML application manages the DTD). This value
should correspond to the DTD System Id property of the XML application folder. This
element is optional and currently has no function; see the <app_pattern> element for
more information.
Note: If the XML document contains a public identifier, the system identifier is the DTD
name specified in the final set of quotation marks in the <!DOCTYPE ... PUBLIC ...>
declaration. (See the example for <pub_id>.)
Do not include path information with the DTD file name. If your DTD has external
parameter entities, enter only the name of the root DTD.
The example below shows the use of the <sys_id> element when an XML document
contains the following document type declaration:
<!DOCTYPE NewsML SYSTEM "NewsML.dtd">
If this value is specified as the value of the DTD System Id property on the XML
application folder, then when the user exports or checks out this file from the repository,

<sys_id>
a path will be added to the file name to point to the location where the DTD file was
downloaded on the local system.
Example of <sys_id>
<sys_id>NewsML.dtd</sys_id>
Source
<!ELEMENT sys_id (#PCDATA)>

<tagname_of_element>
Purpose Gets the tag name of an element in the XML document to store to a variable.
Diagram
Children
this_element, element_selection_pattern
Parents
variable
Usage notes
This element gets the tag name of the element in the XML document that is specified
in its child element <element_selection_pattern>. This is the way that the name of an
element in the XML document can be extracted and used for a purpose such as assigning
a folder or path name or populating a repository property.
In the following example, ʺprocedureʺ will be stored to the variable tagName. If there is
no <procedure> element, ʺElement Unspecifiedʺ will be stored to the variable tagName.
Example of <tagname_of_element>
<variable>
<name>tagName</name>
</tagname_of_element>

<default>Element Unspecified</default>
</variable>
Source
<!ELEMENT tagname_of_element (this_element | element_selection_pattern)>

<template>
<template>
Purpose Provides the value for a repository property.
Diagram
Children
Parents
dctmattr, dctmattr_repeating
Usage notes
The <template> element uses any combination of static text, variables (using the
<var> element), or expressions (using the <expression> element) to produce a value
for a repository property.
Note: The <template> element ignores white space and removes any nonprintable
characters (such as carriage returns) from the string.
Example of <template>
See the examples for <dctmattr> and <dctmattr_repeating>.
Source
<!ELEMENT template %templateformat;>

<this_element>
<this_element>
Purpose Indicates that you want to use the element in the current context (the element that
triggered the mapping rule).
Diagram
Children
None
Parents
attribute_value_of_element, content_of_element, tagname_of_element
Usage notes
The elements <content_of_element>, <tagname_of_element>, and <attribute_value_of_

element> all get information from a specified element and assign it to a variable. If
<this_element> is used to name the element, it uses the current element (the one that is
triggering the rule).
Note: This element should contain no content.
Example of <this_element>
See the examples for <link_rule> and <attribute_value_of_element>.
Source
<!ELEMENT this_element EMPTY>

<two_way_dctmattr>
<two_way_dctmattr>
Purpose Allows XML element content or attribute values to move from the XML document
to single‑value repository properties during import or checkin, and from repository
to the XML document during export or checkout.
Diagram
Children
name, var, date_format, encode_reserved_XML_chars
Parents
metadata
Usage notes
This element allows a dynamic interchange of attributes between the XML document
and the repository. It ensures that the values of repository properties and specified
elements or element attributes are synchronized every time the document moves into
or out of the repository.
Note:
• This element should only be used for repository properties defined as single‑value
attributes.

<two_way_dctmattr>
• The variable used in a <two_way_dctmattr> element must be defined within the

same rule.
• The element or attribute must exist in your XML document. It will not be created
by the XML application.
• If a repository property is changed to a value that is not valid in your DTD or W3C
schema, it could cause validity errors when the document is checked out and opened
in an XML editor, since validity is not tested when the XML attribute is populated
with a repository property. One way to avoid this is to define custom repository
properties that allow only the same values as your DTD or W3C schema.
If extraction is from an element, all of the text in the element will be replaced by the
value of the repository property, and any descendants of that element will appear after
the text. See the second example below.
If the value of the repository property changes, the XML element or attribute value will
be updated in the XML document on the local system when the object is checked out or
exported, but the XML element or attribute value will not be updated in the repository
until that document is checked in again. This means that full‑text indexing will not
contain the new values in the XML document until the document (or component) is
checked out and checked in again. XML content or attribute values will be updated
whenever an export operation occurs, such as when opened within other applications,
and when the content of an XML document is included in an XDQL query.
The <two_way_dctmattr> element uses the following two children to assign values
to repository metadata:
• <name>: the name of the repository property.
• <var>: a variable containing the value of the attribute. The value of the variable
named in <var> must be defined in the same rule using a <variable> element.
Note: In contrast to <dctmattr>, which can be populated with a combination of
static text and one or more variables, <two_way_dctmattr> allows only a single
<var> element, meaning that it must be populated from a single element or attribute
in the XML document.
• <encode_reserved_XML_chars>: not implemented.
In the first example below, the content rule has the following characteristics:
• <element_selection_pattern> specifies that the <book> element in the XML document
will be chunked.
• A variable called sopNumber is defined as the value of the sopnum attribute of the
<book> element. For example, if the XML document contains <book sopnum=ʺ19ʺ>,
then the value ʺ19ʺ will be assigned to sopNumber.
• The object type for the chunk will be custom type SOP.

<two_way_dctmattr>
• <metadata> specifies that the value of sopNumber is assigned to the repository

property called sop_number, and the use of <two_way_dctmattr> means that
when this chunk is exported or checked out, the value of the repository property
sop_number will be assigned back to <book sopnum=ʺ ʺ>
Example of <two_way_dctmattr> with attribute extraction
<xml_content_rule>
<variables>
<variable>
<name>sopNumber</name>
<this_element/>
<attr_name>sopnum</attr_name>
</variable>
</variables>
<object_type>SOP</object_type>
<metadata>
<two_way_dctmattr>
<name>sop_number</name>
<var name="sopNumber"/>
</two_way_dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
In the next example, the rule extracts the content of the <first_level> element and assigns
it to a repository property called first_level_repository_property. For example, suppose you
import the following document:
<root>
<firstlevel>
some text
<secondlevel>Secondlevel</secondlevel>
some more text/firstlevel>
</root>
The repository property called first_level_repository_property will be assigned the value
ʺsome text some more textʺ. Suppose you change the value of this property to ʺUpdated
textʺ in the repository. The next time the document is checked out, the XML document
will look as follows:
<root>
<firstlevel>
Updated text
<secondlevel>Secondlevel</secondlevel>
</firstlevel>
</root>
Note that the replacement text is placed before any child elements.

<two_way_dctmattr>
Example of <two_way_dctmattr> with element extraction

<xml_content_rule>
<element>firstlevel</element>
<variables>
<variable>
<name>FirstLevelContent</name>
<this_element/>
</variable>
</variables>
<metadata>
<two_way_dctmattr>
<name>first_level_repository_property</name>
<var name="FirstLevelContent"/>
</two_way_dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT two_way_dctmattr (name, var, date_format?)>

<two_way_dctmattr_repeating>
Purpose Allows XML element content or attribute values to move from the XML document
to multivalue (repeating) repository properties during import or checkin, and from
repository to the XML document during export or checkout.
Diagram
Children
name, var, date_format, encode_reserved_XML_chars
Parents
metadata
Usage notes
See <two_way_dctmattr> for usage notes. Usage is the same, except the
<two_way_dctmattr_repeating> element is used to populate multivalue (repeating)
repository properties.
• <element_selection_pattern> specifies that any <book> element in the XML document
will be chunked.
• A variable called bookAuthor is declared.

• <content_of_element> assigns the value of each <author> element to the authorName

variable. For example, if the XML document contains:
<author>Smith</author>
<author>Jones</author>
then the values of the repeating repository property would be the following:
authors[0]Smith
authors[1]Jones
.
• The value of authorName is assigned to the repository property called authors, and
the use of <two_way_dctmattr_repeating> means that when this chunk is exported
or checked out, each of the values of the repository property authors will replace the
content of each <author> element successively.
Note: This feature does not add or delete elements from the XML file to match the
number of values set for that repeating property in the repository. When there is a
mismatch, data can be lost or some values may not to be updated.
Example of <two_way_dctmattr_repeating>
<xml_content_rule>
<variables>
<variable>
<name>bookAuthor</name>
<element>author</element>
</variable>
</variables>
<metadata>
<name>authors</name>
<var name="bookAuthor"/>
</two_way_dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT two_way_dctmattr_repeating (name, var, date_format?)>

<validation>
<validation>
Purpose Causes the parser to run in validating mode.
Diagram
Children
None
Parents
application
Usage notes
If the <validation> element is present, the parser will validate the document against
a DTD or W3C schema that is stored in the XML application folder during import
and checkin operations. If this element is not present, the parser will check for well
formedness only.
Note:
• The <validation> element should contain no content.
• Even if the <validation> element is not present, the parser will look for a DTD during
inbound and outbound repository operations if it is mentioned in the <!DOCTYPE>
declaration in the XML document. If the DTD file name is stored in the DTD System
ID property of the XML application folder, then the DTD in the application folder
will be used. If the DTD System ID property is not specified, then the DTD must be
in the location in the local system that is specified by the <!DOCTYPE> declaration
in the XML document.
For DTD validation, if the value of the DTD System ID property of the XML application
folder is set to the DTD file name, then the DTD that is stored in the application folder is

<validation>
used for validation. If the DTD System ID property is not specified, the parser will look
for the DTD in the location on the local file system that is specified by the <!DOCTYPE>
declaration in the XML document. (See the usage notes for the <sys_id> element.)
Example of <validation>
<validation/>
Source
<!ELEMENT validation EMPTY>

<value>
<value>
Purpose Contains the value of the attribute specified in <attr_name>.
Diagram
Children
#PCDATA
Parents
attribute_test
Usage notes
This element is used as a second child of <attribute_test> to specify the value of the
attribute to be tested.
Example of <value>
Source
<!ELEMENT value (#PCDATA)>

<var>
<var>
Purpose Specifies a reference or pointer to the contents of a variable.
Diagram
Children
None
Parents
acl_domain, acl_name, expression, link_template, object_name, object_type,

owner_name, path, policy_name, policy_scope, policy_state, template,
two_way_dctmattr, two_way_dctmattr_repeating
Usage notes
The <var> element is always empty, but the name attribute is required and its value is a
variable name. The value of the variable will be substituted for the <var> element.
Note: The variable named in the <var> element must have been defined using the
<variable> element. For more information see <variables> and <variable>.
Most elements that allow <var> as a child specify that it can contain any combination
of static text, variables (using the <var> element), or expressions (using the
<expression> element). These elements all contain the %template‑format parameter
entity There are two element that allow only the <var> element as children and no static
text: <two_way_dctmattr> and <two_way_dctmattr_repeating>.
In addition to values supplied by the client, there is a set of default variables that are
always defined:
• DF_USER_NAME: the user name from the IDfSession that is being used by the
operation (e.g. ʺJoe Smithʺ).

<var>
• DF_HOME_CABINET: the name of the user’s home cabinet.

• DF_DOCBASE: the name of the current repository.
• DF_SESSION: the string representation of the current IDfSession. This variable
can be passed to a method using <java_classes>. The method could then get an
IDfSession by calling IDfClient.findSession().
Example of <var>
<var name="DF_HOME_CABINET"/>
See also the examples for <xml_content_rule>, <dctmattr>, <dctmattr_repeating>,

<two_way_dctmattr>, and <two_way_dctmattr_repeating>.
Source
<!ELEMENT var EMPTY>

<!ATTLIST var
name CDATA #REQUIRED
>

<variable>
<variable>
Purpose Defines a variable and its value, such as attribute value and element content.
Diagram
Children
name, content_of_element, attribute_value_of_element, tagname_of_element, default
Parents
variables
Usage notes
Each <variable> element contains three obligatory children:

• <name>: specifies the name of the variable to be defined.
• One and only one of the following elements: <content_of_element>,
<attribute_value_of_element>, or <tagname_of_element>, which specifies where the
value of the variable will be obtained in the XML document.
• <default>: provides a value in the event that the XML document does not provide
the value.

<variable>
Variables are locally scoped to the element on which the rule is based. For example, if
you declare a variable in a content rule for the root element of the XML document, then
the variable is available to all rules for the document. If you declare a variable for a
content rule for an element within the document, then the variable is available only
when processing content within that chunk.
Caution:
• If you use a variable in a rule that occurs outside of the chunk boundary, that
variable will be in scope only as long as you always edit that chunk in the
context of the element in which the variable was defined. See the example in
this section.
• If you check in a chunk that has an out‑of‑scope variable, the chunk will check
in but the repository properties that rely on the out‑of‑scope variable will not
be modified.
• You cannot import a chunk with an out‑of‑scope variable. This includes the
case when you are checking in a chunk that contains a new child element.
If that new child element is subject to a chunking rule it will go through an
import process, so if it has an out‑of‑scope variable, the process will fail.
Once a variable is defined with the <variable> element, the value of the variable can be
assigned to other elements by using the <var> element.
In the following example, the <xml_content_rule> exists only for the purpose of defining
a variable, not for chunking, as indicated by the attribute make_object=ʺfalseʺ. The rule
extracts the content of the element <model.name> and stores it in a variable named
modelName. This variable can be used in any other rule that applies to a descendant of
the <description> element in the XML document. Once the close tag for the <description>
element is parsed in the XML document, the variable is no longer available.
Example of <variable>
<xml_content_rule make_object="false">
<variables>
<variable>
<name>modelName</name>
<element>model.name</element>
<default>Model Unspecified</default>
</variable>
</variables>
</xml_content_rule>

<variable>
The following example is more detailed and shows how a variable can be defined in a
rule for one element and used in a rule for another element that has a mutual ascendant.
Suppose you have the following XML document:
<book>
<bookinfo>
<author>...</author>
</bookinfo>
<chapter>
<title>...</title>
</chapter>
</book>
You want to chunk on the <chapter> elements and assign the primary author of the book
to the owner_name property for the object when it is created in the repository. Since the
<author> element is a descendant of the <book> element but not the <chapter> element,
the content rule for <book> must define a variable for primary author, which will then be
used in the rule for <chapter>. Since <chapter> is a descendant of <book>, it is within the
local scope of variables defined for the <book> element. This is demonstrated with the
two content rules in the following example. The rule can be broken down as follows:
• In the content rule for <book>, the primaryAuthor variable is declared and its value
defined as the first occurrence of the <author> element as a child of <bookinfo>. The
<bookinfo> element should be a child of the <book> element.
• In the content rule for <chapter>, the chapTitle variable is defined as the <title>
element, which should be a child of <chapter>.
• In the chunking portion of the rule, the primaryAuthor variable is used as the value
for <owner_name>, which then assigns this value to the owner_name repository
property.
• The name of the object to be created is assigned the static prefix ʺchap_ʺ plus the
chapTitle variable.
The caveat is that if you ever edited the chapter chunk in isolation, import would fail
because there would be no <book> element from which to obtain the variable. The
<chapter> chunk would always need to be edited as part of a document in which it was
nested under the <book> element.
Example of <variable> defined in one rule and used in another

<xml_content_rule>
<variables>
<variable>
<name>primaryAuthor</name>
<element>author</element>
<context_rule>

<variable>
<child_of>bookinfo</child_of>
</context_rule>
<occurrence>1</occurrence>
</variable>
</variables>
...chunking portion of rule...
</xml_content_rule>
<xml_content_rule>
<element>chapter</element>
<variables>
<variable>
<name>chapTitle</name>
<element>title</element>
</variable>
</variables>
<owner_name><var name="primaryAuthor"/></owner_name>
<object_name>chap_<var name="chapTitle"/></object_name>
</xml_content_rule>
Example of <variable> with the <content_of_element> subelement_option attribute
If you want to collect the content of an element in a variable, including the content of any
child elements, use the following model:
<variable>
<name>bookTitle</name>
<content_of_element subelement_option="include_content">
<content_of_element subelement_option="include_content">
</content_of_element >
</variable>
The include_content_and_markup value for the subelement_option is not supported

for DFC 6.0.
Source
<!ELEMENT variable (name, (content_of_element |

attribute_value_of_element | tagname_of_element),
default?)>

<variables>
<variables>
Purpose Contains all of the variable definitions and values in a mapping rule.
Diagram
Children
variable
Parents
link_rule, non_xml_content_rule, xml_content_rule
Usage notes
This is a container element that contains the list of variable definitions and values. These
values can be extracted from the XML document and used in other elements in the XML
application configuration file, for example in elements that assign values to repository
properties. Each variable is defined in a separate <variable> element. See <variable> for
usage notes on how to define variables.
Example of <variables>
For additional information and examples, see <variable>, <var>, <template>, and
<xml_content_rule>.
Source
<!ELEMENT variables (variable+)>

<version_label>
<version_label>
Purpose Assigns an early binding value to a chunk.
Diagram
Children
#PCDATA
Parents
link_rule, xml_content_rule
Usage notes
This element is used to assign binding rules (early binding) for chunked objects using
an existing symbolic version label when the chunked or linked object is imported. This
symbolic version label must be defined within the <metadata> element or assigned by
the user on import.
The binding rule will apply to all chunked objects to which an <xml_content_rule>
applies, or all files to which a <link_rule> applies. To set a binding rule for an individual
component, or to change the binding rule when checking in a document, the author can
add or edit the dctm:version_label attribute (for an element to which <xml_content_rule>
applies) or the dctm:link_version_label attribute (for an element to which <link_rule>
applies) in the XML document itself.
Note:
• If a dctm:version_label or dctm:link_version_label attribute is added to a new XML
document, it will override the <version_label> element in <xml_content_rule> or
<link_rule> when the XML document is imported.

<version_label>
• The <version_label> element in the XML application configuration file only

sets a binding rule (early binding) when an XML document is first imported.
To set a binding rule when the document is checked in, edit the appropriate
dctm:version_label or dctm:link_version_label attribute in the XML document.
• The symbolic version label must exist in the version tree, or the server will throw
an error. For <version_label>, if the symbolic version label is not set within the
<metadata> element, users will have to provide it during import.
• If the value of <version_label> is ʺCURRENTʺ, late binding will be set, which appears
in clients as ʺNone ‑ Default to Current.ʺ
In most cases, the symbolic version label is assigned within the <metadata> element in
the same rule as <version_label>, as follows:
<xml_content_rule>
<metadata>
<name>r_version_label</name>
<template>symbolic_version_label</template>
<metadata>
<version_label>symbolic_version_label</version_label>
<make_entity/>
</xml_content_rule>
where symbolic_version_label is the value you assign as the symbolic version label. Within
the <dctmattr_repeating> element, <name> identifies the repository dm_sysobject
property r_version_label, and <value> assigns a value to it. Specifying the same value
in <version_label> then sets the binding rule by using this value as the version_label
attribute of the dmr_containment object.
For more information about early binding, see Documentum Content Server Fundamentals
Guide.
In the following example, <xml_content_rule> is constructed so that the version label
DRAFT is assigned as a symbolic version label of the <model> chunk when it is imported.
The <version_label> element then sets the binding rule to DRAFT.
Example of <version_label>
<xml_content_rule>
<metadata>
<name>r_version_label</name>
<template> DRAFT </template>
<metadata>
<version_label>DRAFT</version_label>

<version_label>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT version_label (#PCDATA)>

<xml_content_rule>
<xml_content_rule>
Purpose Specifies how to store and create XML content as objects in Documentum.
Diagram
Children
element_selection_pattern, variables, location, owner_name, object_name, acl_name,

acl_domain, default_acl, object_type, business_policy, metadata; version_label,
make_entity, link_template

<xml_content_rule>
Parents
map_rules
Usage notes
You must provide an <xml_content_rule> for any element that will be a root element in
your document. (This does not apply to external parsed entities for which you specify
an <entity_rule>.)
The element contains four main parts:
• <element_selection_pattern>
Specifies the element in the XML document that triggers the rule. You can also
specify that the element appear in a specific context or with a specific attribute value.
• Elements (such as <variables>, <location>, <owner_name>, and so on) that specify the
XML content to be extracted and used during processing, followed by how to create
the object and what properties to set.
• <version_label>
If present, specifies a binding rule for an existing version label.
• <make_entity/> or <link_template>
Controls how the repository manages the structural aspects of chunked objects.
Currently, only the <make_entity/> element is supported and is therefore required.
You can have more than one <xml_content_rule> element for the same XML document
element, as long as the content of <element_selection_pattern> is different. If a chunk
satisfies more than one <element_selection_pattern> element, the <xml_content_rule>
that appears first in the XML application configuration file will be used.
The <xml_content_rule> element also has these attributes:
• editable_virtual_doc
This attribute is no longer used. This attribute is set to ʺfalseʺ but does not affect the
XML application.

<xml_content_rule>
• allow_restructuring
This specifies whether users can restructure XML virtual documents from within
Virtual Document Manager (VDM) or through a Documentum Foundation Classes
(DFC) virtual document interface.
This attribute supersedes the editable_virtual_doc attribute, which is now obsolete.
When allow_restructuring is set to true, users can add, remove, reorder or reposition
descendants in virtual documents without downloading the documents to their
local machines. To support restructuring, the document is silently checked out, but
content is not downloaded to the clients local file system. The content is downloaded
from the repository to the application server machine until restructuring is complete.
For large XML documents or environments where there is high network latency,
modifying the virtual document structure through a content editor can be time
consuming.
Once a virtual document has been locked for structural change, its content can not
be modified. Similarly, if a user has checked out the content for an XML virtual
document, the user can not make structural changes.
Users can restructure only those objects that are created through an xml_content_rule.
As an example, let us say you have an XML application where you have an
xml_content_rule for <book>, <chapter> and <section>, and where you have specified
allow_restructuring=ʺtrueʺ for all three rules. Also, you have a link_rule for <image>,
which can occur at any level. Once the book is imported, a user can: restructure
<chapter> and <section> chunks within a parent virtual document using VDM; insert
other existing <chapter> and <section> objects, provided that the objects use the same
or a comparable XML applications; and delete <chapter> and <section> objects. If a
<chapter> object has a virtual document child that is not an XML chunk, users can
not restructure, move, add, or delete the linked objects.
OLE compound documents are not affected by the allow_restructuring attribute.
The structure of OLE compound documents can only be changed by checking out
a document’s content.
• export
This specifies that a chunked XML document stored as a virtual document in the
repository will be exported or checked out as a single XML document. The only
value allowed for this attribute is ʺinlineʺ, which is also the default.
• make_object
This specifies that the purpose of the rule is not to create an object but to perform
other operations, such as defining variables for later use. See the example in
<variable>. The default is ʺtrueʺ, so if this attribute is not present, an object will be
created.

<xml_content_rule>
• The <description> element in the XML document triggers the rule.

• The content of the <title> element (a child of the <Description> element) in the XML
document is used to assign a value to the variable Desctitle. If there is no <title>
element, then ʺTitle Unspecifiedʺ is assigned to the Desctitle variable.
• The path name is specified, using a combination of static text and the Desctitle
variable. For example, if the value of Desctitle is ʺSOP 19ʺ, then the path will be
Descriptions/SOP 19.
• The name of the object name to be created is specified as the value of the Desctitle
variable. Following the above example, the chunk will be created with the name
SOP 19.
• The repository property named title is populated with the value of the Desctitle
variable.
• The presence of the <make_entity/> element specifies that the chunk will be managed
as an entity in the repository.
• Because <object_type> was not specified, the object type of the chunk to be created
will be dm_document.
• Because <owner_name> was not assigned, the owner_name property for this chunk
will be the user who imports the XML document.
• There are no ACLs (permissions) or business policy (document lifecycle) defined
for this object.
See the individual elements for more information on their use.
Example of <xml_content_rule>
<xml_content_rule>
<variables>
<variable>
<name>Desctitle</name>
<default>Title Unspecified</default>
</variable>
</variables>
<location>
<path>Descriptions/<var name="Desctitle"/></path>
</location>
<object_name><var name="Desctitle"/></object_name>
<metadata>
<dctmattr>
<name>title</name>
<template><var name="Desctitle"/></template>
</dctmattr>
</metadata>

<xml_content_rule>
<make_entity/>
</xml_content_rule>
Source
<!ELEMENT xml_content_rule (element_selection_pattern,

(%map_rule_content;), version_label?,
(make_entity | link_template))>
<!ATTLIST xml_content_rule
editable_virtual_doc (false) "false"
allow_restructuring (true | false) "false"
export (inline) "inline"
make_object (true | false) "true"
>

Appendix B
Documentum Attributes
When XML documents or individual chunks are checked out, Documentum adds these attributes to
each element for which they are declared in the DTD. The attributes have two purposes:
• XML editors with Documentum integrations use the attributes to make text read‑only and
indicate changes when text is edited.
• If any of these attributes appear in an XML document, Documentum uses them to process these
objects or assign repository properties to these objects on import and checkin.
The Documentum attributes will override any XML application configuration file settings for a
particular chunk (other than the root chunk). For example, if the XML document contains the
tag <ContentItem dctm:version_label=ʺApprovedʺ> and the XML application configuration file
contains <version_label>Draft</version_label> for the same element, the repository property for that
<ContentItem> chunk will have a binding rule set to the value ʺApprovedʺ.
Documentum attributes in the root chunk are ignored during checkin, for the following reasons.
• The object ID of the root chunk is already known, so dctm:obj_id is not necessary for the root.
• The root chunk will always be checked in during a checkin operation, regardless of the value of
dctm:obj_status.
• A virtual document root cannot take a binding rule because it has no dmr_containment, so the
dctm:version_label is ignored for the root chunk.
Table 12, page 229 provides more information about the role that the Documentum attributes play.
For more information about Documentum attributes, see Adding Documentum attributes to DTDs
and schemas, page 37.
Table 12. Documentum attributes for XML documents
Attribute Value Identifies

xmlns:dctm http://www.documentum.com DCTM Namespace URI
declaration


dctm:obj_status Default The modification status of the
repository object.
This attribute is set to ʺdefaultʺ

if object is checked out. If
the object status is Default on
checkin, the object is checked in
and versioned.
Read‑only The attribute is set to
ʺRead‑onlyʺ if the repository
object is not checked out. The
XML editor integrations with
Documentum will make the
contents read‑only.
Changed The attribute is set to ʺChangedʺ
by an editing application. If the
status is ʺChangedʺ when the
object is checked in, the object
is checked in and versioned.
Unchanged If the attribute value is set to
ʺUnchangedʺ when the object
is checked in, the checkout is
cancelled for that object.
Note: The root object will
always be checked in, even if its
status is marked ʺUnchangedʺ.
Unchanged_Inline May be used by an integrated
editor to allow user to
download a document with
read‑only chunks, then
selectively check out a chunk.
dctm:obj_status value will
change from ʺRead‑Onlyʺ to
ʺUnchanged_Inlineʺ.
Changed_Inline If user modifies a chunk labeled
ʺUnchanged_Inlineʺ, status will
change to ʺChanged_Inlineʺ.
dctm:obj_id Value of r_object_id Object ID of the object in the
repository


dctm:version_label, Value of the version_label Specifies a binding rule for a
dctm:link_version_label attribute of the file that has been assigned a
dmr_containment object. symbolic version label.
For the virtual document
Note:
root, which has no
dmr_containment, the value • If the value of
will be set to CURRENT. dctm:version_label is
ʺCURRENTʺ, late binding
will be set, which appears in
clients as ʺNone ‑ Default to
Current.ʺ
• If this attribute value is
manually changed in the
XML document, its value
must refer to an existing
symbolic version label that
has already been assigned
to some version of the
document, or an error will
be returned.
dctm:link_obj_status Currently nonfunctional
dctm:link_obj_id Currently nonfunctional


Appendix C
Resources at the Documentum
Developer Site
The Documentum Developer site has a number of resources related to XML, along with case studies
and sample code that you can download. See the following locations:
• Sample code: http://developer.emc.com/developer/samplecode.htm
• Tips: http://developer.emc.com/developer/tippage.htm
• XML resource page: http://developer.emc.com/developer/roadmap/xml_resource.htm

Resources at the Documentum Developer Site

Appendix D
Sample XML Application Configuration
File for NewsML
This sample demonstrates how the content requirements led to the creation of the XML application
configuration file and how the separate components in the file work to configure the XML application.
This sample is based on a case study created for the Document Developer Web site. You can read
the case and download the sample DocApp at http://developer.emc.com/developer/xmlProject/
NewsML/NewsMLSeriesOverview.htm.
The NewsML DTD, XML application configuration file, and other parts of the XML application are
contained in Appendix E, Source Files for NewsML Sample.
The case study uses NewsML, an XML encoding standard for the news industry. A typical news
article might be structured in the following lines:
<NewsML>
<! Includes information about the news service and priority>
<NewsItem>
<! Includes identifiers, information relevant to
managing the item>
<NewsComponent>
<! Includes headline, byline, dateline, etc.>
<DataContent>
...
Paragraph of content here.
</DataContent>
<DataContent>
...
</DataContent>
<DataContent>
...
</DataContent>
</NewsComponent>
</NewsItem>
</NewsML>
The elements that appear in this example are the following:

Sample XML Application Configuration File for NewsML
• <NewsML>: A NewsML document, the root element, which must contain one or more
<NewsItem> elements.
• <NewsItem>: A managed set of information representing a point of view, at a given time, on
some event or events. It may contain a <NewsComponent> element, one or more <Update>
elements, or a <TopicSet> element.
• <NewsComponent>: A container for news objects, used to identify the role of news objects
in relation to one another, and to ascribe metadata to them. (The NewsComponent would
contain the headline of a standard news article.) It contains one or more of one of the following:
<NewsItem>, <NewsComponent>, or <ContentItem>.
• <ContentItem>: A news object that carries or identifies content intended for presentation to
humans. (Corresponds to chunks of content within the article.)
The business process requirements for the news industry are defined as follows:
• Content created once, repurposed for different needs
• Content stored once, reused as needed
• Simple contextual search for relevant content
• Controlled timeliness and relevance of content
• Structured authoring environment
• Multi‑format publishing and multichannel delivery
• Rapid delivery of appropriate content
• Personalization and dynamic assembly of content.
• Efficient management of document lifecycle and workflow of a content item
In this case study, a subset of these requirements are implemented as follows:
• The objective is to chunk at a level that all <NewsComponent>, <HeadLine>, <SubHeadline>,
<ByLine>, and <ContentItem> elements can be aggregated to display in a single page.
• To facilitate display, search, and transformations of content, custom object types will be created
in the repository, custom properties are defined for these chunks, and the values of these
properties will be extracted from the XML document by content rules in the XML application
configuration file.
• An XSL stylesheet will query the repository using XDQL and display a front page from content
chunks and an article page that includes mixed media types. (See Chapter 6, Transformations for
a detailed description of the XSL stylesheet for the NewsML case study.)
Table 13, page 236 shows the four elements that will be chunked, and the custom object types that will
be created for them in the repository.
Table 13. NewsML elements to be chunked
NewsML Element Repository Custom Object Type

<NewsML> newsml
<NewsItem> newsml_item

NewsML Element Repository Custom Object Type

<NewsComponent> newsml_component
<ContentItem> newsml_content
Breakdown of the NewsML application

configuration file
The following sections break down the entire XML application configuration file into
segments in order to describe the details of what is being configured. The entire file
without line numbers can be found in Appendix E, Source Files for NewsML Sample.
.
Naming the application

The name of the application is provided in the following lines.
6 <application>
7 <name>NewsML</name>
Note: This name must match the name of the XML application configuration file and the
name of the XML application folder you will create in the repository.
Specifying which XML application applies to documents

Properties set on the XML application folder determine which XML applications are
relevant to a particular XML document. Current, the <app_pattern> element is required
in the XML application configuration file, but it does not function in application
detection. (See the <app_pattern> element and XML application detection algorithm,
page 49.) However, you can use this element to hold information that is specified in
properties of the XML application folder. For example, in the NewsML example, the
following lines specify that the Root Elements property of the XML application folder
contains the value NewsML.
8 <app_pattern>
9 <element>NewsML</element>
10 </app_pattern>

Chunking rule for <NewsML>

The following segment contains the first content rule, nested under the
<map_rules> element. Although the <xml_content_rule> element can be used for other
purposes, it is most typically used for chunking objects, as in this case.
Lines 20‑22: <element_selection_pattern> identifies the <NewsML> element as the
trigger for this rule.
Lines 23‑25: The <location> element specifies a relative path for the repository location
of the chunk. Since this is the root element, it will be the parent chunk in the virtual
document, so this relative path will be added to the cabinet or folder path selected on the
import operation. (See the <location> and <path> elements.)
Since no object name is specified, one will be assigned. (See the <object_name> element
in the reference section for a description of how this name is assigned.)
Line 26: The <object_type> element specifies that this chunk will be created as an object
of custom type newsml_document.
Note: This custom object type must already exist in the repository.
Line 27: The <make_entity> element specifies that a chunked object will be managed as
an entity in the repository. This element is required in a chunking rule of this type.
12 <map_rules>
13 <! CONTENT RULEs >
14 <! CONTENT Chunking Rule for the root news element:
15 NewsML FOLLOWS HERE >
16 <! used mainly to declare a few common variables used
17 in the rest of the config file...>
18 <! ******************************************* >
19 <xml_content_rule>
20 <element_selection_pattern>
21 <element>NewsML</element>
22 </element_selection_pattern>
23 <location>
24 <path>NewsInformation/</path>
25 </location>
26 <object_type>newsml_document</object_type>
27 <make_entity/>
28 </xml_content_rule>
Chunking rule for <NewsItem>

The following content rule is considerably longer because it defines variables and then
uses them to assign properties to the object created in the repository. The rule breaks
down as follows.

Line 31: In <xml_content_rule>, the allow_restructuring attribute specifies whether users

can restructure XML virtual documents from within VDM. This attribute supersedes the
editable_virtual_doc attribute, which is obsolete.
Lines 32‑34 identify the <NewsItem> element in the XML document as the trigger for
the rule.
Lines 35‑109: The <variables> element begins the list of variables that are defined for
this rule, as shown in Table 14, page 239.
Table 14. Variables declared for <NewsItem>
Line numbers Variable Name Variable Value Default Value

36‑44 NewsItemId Content ʺMiscNewsItemsʺ
extracted from
<NewsItemId>
element in XML
document
45‑52 PublicIdentifier Content ‑‑
extracted from
<PublicIdentifier>
element
53‑60 DateId Content extracted ‑‑
from <DateId>
element
61‑68 ProviderId Content extracted ‑‑
from <ProviderId>
element
69‑78 Urgency Value of ʺUnspecified
FormalName Urgencyʺ
attribute of
<Urgency> element
in XML document
79‑88 Status Value of ʺUnspecified
FormalName Statusʺ
attribute of <Status>
element


89‑98 NewsItemType Value of ʺUnspecified Typeʺ
FormalName
attribute of
<NewsItemType>
element
99‑108 Duid Value of Duid at‑ ʺUnknownDUIDʺ
tribute of <News‑
Component> ele‑
ment
Lines 110‑113 specifies the relative location (the NewsItems folder) for the chunk to be
created. Since this chunk will not be a parent chunk, the path is relative to the path of its
parent (namely the NewsML chunk for the root element of the XML document).
Lines 114‑116 specifies that the name of the object to be created for this chunk is the
value of the NewsItemId variable defined previously, which in turn is the content of the
<NewsItemId> element in the XML document.
Line 117 specifies that the type of object to be created is the newsml_item custom type.
Lines 120‑145 contain the part of the rule that determines what properties are assigned
to the object after it is created, as shown in Table 15, page 240. For each variable, either
<content_of_element> is used to specify that the value will come from the content of
the element specified in the XML document, or <attribute_value_of_element> is used
to specify that the value will come from an attribute value for a particular element in
the XML document.
Table 15. Property values assigned to NewsItem chunk
Line numbers Repository Property Name Property Value

121‑124 publicidentifier Value of the PublicIden‑
tifier variable (defined as
content of <PublicIdenti‑
fier> element)
125‑128 urgency Value of the Urgency
variable
129‑132 status Value of the Status variable
133‑136 newsitem_type Value of the NewsItemType
variable
137‑140 provider_id Value of the ProviderId
variable
141‑144 date_id Value of the DateId variable

Line 146: The <make_entity/> element functions in the same way as in the previous
chunking rule.
31 <xml_content_rule export="inline" editable_virtual_doc="false"
allow_restructuring="false">
33 <element>NewsItem</element>
35 <variables>
36 <variable>
37 <name>NewsItemId</name>
38 <content_of_element>
40 <element>NewsItemId</element>
42 </content_of_element>
43 <default>MiscNewsItems</default>
44 </variable>
45 <variable>
46 <name>PublicIdentifier</name>
49 <element>PublicIdentifier</element>
52 </variable>
53 <variable>
54 <name>DateId</name>
57 <element>DateId</element>
60 </variable>
61 <variable>
62 <name>ProviderId</name>
65 <element>ProviderId</element>
68 </variable>
69 <variable>
70 <name>Urgency</name>
71 <attribute_value_of_element>
73 <element>Urgency</element>
75 <attr_name>FormalName</attr_name>
76 </attribute_value_of_element>
77 <default>Unspecified Urgency</default>
78 </variable>
79 <variable>
80 <name>Status</name>
83 <element>Status</element>

87 <default>Unspecified Status</default>
88 </variable>
89 <variable>
90 <name>NewsItemType</name>
93 <element>NewsItemType</element>
97 <default>Unspecified Type</default>
98 </variable>
99 <variable>
100 <name>Duid</name>
103 <element>NewsComponent</element>
105 <attr_name>Duid</attr_name>
107 <default>UnknownDUID</default>
108 </variable>
109 </variables>
110 <location>
111 <! user should customize this path >
112 <path>NewsItems/</path>
113 </location>
114 <object_name>
115 <var name="NewsItemId"/>
116 </object_name>
117 <object_type>newsml_item</object_type>
118 <! ############### SOME ATTRIBUTES ON THE
119 newsml_item Object ################# >
120 <metadata>
121 <dctmattr>
122 <name>publicidentifier</name>
123 <template><var name="PublicIdentifier"/></template>
124 </dctmattr>
125 <dctmattr>
126 <name>urgency</name>
127 <template><var name="Urgency"/></template>
128 </dctmattr>
129 <dctmattr>
130 <name>status</name>
131 <template><var name="Status"/></template>
132 </dctmattr>
133 <dctmattr>
134 <name>newsitem_type</name>
135 <template><var name="NewsItemType"/></template>
136 </dctmattr>
137 <dctmattr>
138 <name>provider_id</name>
139 <template><var name="ProviderId"/></template>
140 </dctmattr>

141 <dctmattr>
142 <name>date_id</name>
143 <template><var name="DateId"/></template>
144 </dctmattr>
145 </metadata>
146 <make_entity/>
Chunking rule for <NewsComponent>

The following content rule is very similar to the chunking rule for <NewsItem>. It
defines a slightly different relative path in the <location> element, and it assigns variable
values to both single‑value and multivalue (repeating) repository properties. To facilitate
display, search, and transformations of content, custom object types will be created
in the repository, custom properties are defined for these chunks, and the values of
these properties will be extracted from the XML document by content rules in the XML
application configuration file.
Lines 152‑154 identify the <NewsComponent> element in the XML document as the
trigger for the rule.
Lines 155‑321 define the variables that will applied in this rule, as shown in Table 16,
page 243.
Table 16. Variables declared for <NewsComponent>

156‑163 Duid Value of Duid at‑ ʺUntitled
tribute of this ele‑ NewsComponentʺ
ment (<NewsCom‑
ponent>) in XML
document
164‑172 Confidence Value of Confi‑ ‑‑
dence attribute of
<DescriptiveMeta‑
data> element
173‑182 Genre Value of ʺMiscellaneous‑
FormalName Genreʺ
attribute of <Genre>
element
183‑191 ByLine Content extracted ʺUnknown ByLineʺ
from <ByLine>
element


192‑199 HeadLine Content extracted ‑‑
from <HeadLine>
element
200‑207 SubHeadLine Content ‑‑
extracted from
<SubHeadLine>
element
208‑216 DateLine Content extracted ‑‑
from <DateLine>
element
217‑225 CreditLine Content extracted ʺCredits Unknownʺ
from <CreditLine>
element
226‑234 SlugLine Content extracted ʺSluggerʺ
from <SlugLine>
element
235‑244 Role Value of ʺNo Role Specifiedʺ
FormalName
attribute of <Role>
element
245‑253 BasisForChoice Content ʺBasis Not
extracted from Specifiedʺ
<BasisForChoice>
element
254‑262 Provider Content extracted ʺProvider Not
from <Provider> Specifiedʺ
element
263‑272 Creator Value of ʺCreator Not
FormalName Specifiedʺ
attribute of <Party>
element
273‑282 Language Value of ʺLanguage
FormalName Unspecifiedʺ
attribute of
<Language>
element


283‑292 Topic Value of Topic ʺTopic Unspecifiedʺ
attribute of
<TopicOccurrence>
element
293‑301 OfInterestTo Value of ‑‑
FormalName
attribute of
<OfInterestTo>
element
302‑310 Source Value of ‑‑
FormalName
attribute of
<Source> element
311‑320 EquivList Value of EquivList ‑‑
attribute of <News‑
Component> ele‑
ment
Lines 322‑325 specify the relative location for the chunk to be created:
../NewsComponents/
This path is relative to the path of the parent chunk. Since the <NewsComponent>
element is iterative (it can be nested under <NewsItem> as well as under
<NewsComponent>), this NewsComponent folder will always be stored in a folder that
is a sibling of the parent chunk.
Lines 326‑328 specify that the name of the object to be created for this chunk is the value
of the Duid variable.
Line 329 specifies that the newsml_component custom object type will be created.
Lines 332‑398 contain the part of the rule that determines what properties are
assigned to the object after it is created, as shown in Table 17, page 245. Starting
with line 382, the repository properties are multivalue (repeating) and so require the
<dctmattr_repeating> element.
Table 17. Property values assigned to NewsComponent chunk

333‑336 byline Value of the ByLine
variable
337‑340 creditline Value of the CreditLine
variable


341‑344 dateline Value of the DateLine
variable
345‑348 headline Value of the HeadLine
variable
349‑352 subheadline Value of the SubHeadLine
variable
353‑356 slugline Value of the SlugLine
variable
357‑360 role Value of the Role variable
361‑364 basis_for_choice Value of the BasisFor‑
Choice variable
365‑368 provider Value of the Provider
variable
369‑372 creator Value of the Creator
variable
373‑376 genre Value of the Genre variable
377‑380 equivalents Value of the EquivList
variable
382‑385 topics (repeating) Value of the Topic variable
386‑389 languages (repeating) Value of the Language
variable
390‑393 source (repeating) Value of the Source variable
394‑397 of_interest_to (repeating) Value of the OfInterestTo
variable
Line 399: The <make_entity> element functions as for the other chunking rules.
155 <variables>
156 <variable>
159 <this_element/>
162 <default>Untitled NewsComponent</default>
163 </variable>
164 <variable>
165 <name>Confidence</name>

168 <element>DescriptiveMetadata</element>
170 <attr_name>Confidence</attr_name>
172 </variable>
173 <variable>
174 <name>Genre</name>
177 <element>Genre</element>
181 <default>MiscellaneousGenre</default>
182 </variable>
183 <variable>
184 <name>ByLine</name>
187 <element>ByLine</element>
190 <default>Unknown ByLine</default>
191 </variable>
192 <variable>
193 <name>HeadLine</name>
196 <element>HeadLine</element>
199 </variable>
200 <variable>
201 <name>SubHeadLine</name>
204 <element>SubHeadLine</element>
207 </variable>
208 <variable>
209 <name>DateLine</name>
212 <element>DateLine</element>
215 <default>Date Line Not Given</default>
216 </variable>
217 <variable>
218 <name>CreditLine</name>
221 <element>CreditLine</element>

224 <default>Credits Unknown</default>
225 </variable>
226 <variable>
227 <name>SlugLine</name>
230 <element>SlugLine</element>
233 <default>Slugger</default>
234 </variable>
235 <variable>
236 <name>Role</name>
239 <element>Role</element>
243 <default>No Role Specified</default>
244 </variable>
245 <variable>
246 <name>BasisForChoice</name>
249 <element>BasisForChoice</element>
252 <default>Basis Not Specified</default>
253 </variable>
254 <variable>
255 <name>Provider</name>
258 <element>Provider</element>
261 <default>Provider Not Specified</default>
262 </variable>
263 <variable>
264 <name>Creator</name>
267 <element>Party</element>
271 <default>Creator Not Specified</default>
272 </variable>
273 <variable>
274 <name>Language</name>
277 <element>Language</element>

281 <default>Language Unspecified</default>
282 </variable>
283 <variable>
284 <name>Topic</name>
287 <element>TopicOccurrence</element>
289 <attr_name>Topic</attr_name>
291 <default>Topic Unspecified</default>
292 </variable>
293 <variable>
294 <name>OfInterestTo</name>
297 <element>OfInterestTo</element>
301 </variable>
302 <variable>
303 <name>Source</name>
306 <element>Source</element>
310 </variable>
311 <variable>
312 <name>EquivList</name>
313 <! yes/no value only >
318 <attr_name>EquivList</attr_name>
320 </variable>
321 </variables>
322 <location>
323 <! user should customize this path >
324 <path>../NewsComponents/</path>
325 </location>
326 <object_name>
327 <var name="Duid"/>
328 </object_name>
329 <object_type>newsml_component</object_type>
330 <! NewsComponent element, newsml_component objecttype,
331 METADATA settings ******** >
332 <metadata>
333 <dctmattr>
334 <name>byline</name>
335 <template><var name="ByLine"/></template>
336 </dctmattr>

337 <dctmattr>
338 <name>creditline</name>
339 <template><var name="CreditLine"/></template>
340 </dctmattr>
341 <dctmattr>
342 <name>dateline</name>
343 <template><var name="DateLine"/></template>
344 </dctmattr>
345 <dctmattr>
346 <name>headline</name>
347 <template><var name="HeadLine"/></template>
348 </dctmattr>
349 <dctmattr>
350 <name>subheadline</name>
351 <template><var name="SubHeadLine"/></template>
352 </dctmattr>
353 <dctmattr>
354 <name>slugline</name>
355 <template><var name="SlugLine"/></template>
356 </dctmattr>
357 <dctmattr>
358 <name>role</name>
359 <template><var name="Role"/></template>
360 </dctmattr>
361 <dctmattr>
362 <name>basis_for_choice</name>
363 <template><var name="BasisForChoice"/></template>
364 </dctmattr>
365 <dctmattr>
366 <name>provider</name>
367 <template><var name="Provider"/></template>
368 </dctmattr>
369 <dctmattr>
370 <name>creator</name>
371 <template><var name="Creator"/></template>
372 </dctmattr>
373 <dctmattr>
374 <name>genre</name>
375 <template><var name="Genre"/></template>
376 </dctmattr>
377 <dctmattr>
378 <name>equivalents_list</name>
379 <template><var name="EquivList"/></template>
380 </dctmattr>
381 <! some attributes repeating/multivalued >
382 <dctmattr_repeating>
383 <name>topics</name>
384 <template><var name="Topic"/></template>
385 </dctmattr_repeating>
387 <name>languages</name>
388 <template><var name="Language"/></template>
391 <name>source</name>
392 <template><var name="Source"/></template>

395 <name>of_interest_to</name>
396 <template><var name="OfInterestTo"/></template>
398 </metadata>
399 <make_entity/>
XML content rule for <ContentItem>

This content rule chunks the element <ContentItem> in the XML document. There is
nothing new in this rule that was not discussed for the previous three chunking rules,
so it will not be discussed further here.
406 <element>ContentItem</element>
408 <variables>
409 <variable>
410 <name>MediaType</name>
413 <element>MediaType</element>
417 </variable>
418 <variable>
419 <name>Comment</name>
422 <element>Comment</element>
425 </variable>
426 <variable>
429 <this_element/>
432 <default>Untitled ContentItem</default>
433 </variable>
434 </variables>
435 <location>
436 <path>../ContentItems/</path>
437 </location>
438 <object_name><var name="Duid"/></object_name>
439 <object_type>newsml_content</object_type>
440 <! METADATA for newsml_content object >
441 <metadata>
442 <dctmattr>

443 <name>mediatype</name>
444 <template><var name="MediaType"/></template>
445 </dctmattr>
446 </metadata>
447 <make_entity/>
Link rule
The <link_rule> element specifies how Documentum recognizes and manages external
unparsed files and NDATA entities for the XML application.
The <link_rule> element tells the repository what to do with files such as graphics that
are linked to the XML document. You can accomplish the same repository actions that
<xml_content_rule> does. You can also specify whether the linked file should be part
of the virtual XML document or a regular linked file in the repository, and whether
this is a permanent link.
In the NewsML DTD, several elements, such as <ContentItem>, can contain an attribute
called Href instead of data content. This attribute contains a pointer to another element
containing the content, either in the same document or elsewhere. This Href attribute
provides a mechanism to link from one element to another for content.
The NewsML XML application configuration file contains a link rule, which will import
into the repository any linked file that is specified in an Href attribute of <ContentItem>.
This particular rule also specifies that the repository objects for these linked files are
displayed in the XML virtual document as children of the <ContentItem> chunk that
contains the link.
For example, one of the XML documents provided with the NewsML sample download
contains the following line:
<ContentItem Href="../examples/civilrt.xml">
The link target rule described here will grab the file named civilrt.xml in the ../examples/
directory on the local system and import it into the repository as a child of this particular
ContentItem chunk.
Line 452: peer_or_child=ʺchildʺ specifies that the document will be displayed in the
repository as a child of the component that contains it. Since this is the default value,
explicitly assigning a value to this attribute is optional here. The ndata=ʺfalseʺ attribute
specifies that this link points to an unparsed external file and is not a reference to an
NDATA entity.
Lines 453‑455 specify that the <ContentItem> element triggers this link rule.
Lines 456‑458 specify that the link target is the value of the Href attribute.
Lines 459‑461 specify a relative path for this chunked object in the repository.

Line 462 specifies that the object type created for this chunk will be newsml_content.
452 <link_rule peer_or_child="child" ndata="false">
454 <element>ContentItem</element>
456 <link_target>
457 <attr_name>Href</attr_name>
458 </link_target>
459 <location>
460 <path>../ContentItems/References/</path>
461 </location>
462 <object_type>newsml_content</object_type>
463 </link_rule>
464 </map_rules>
465 </application>


Appendix E
Source Files for NewsML Sample
These files can be downloaded in a zip file that extracts to a DocApp at the Documentum Developer
site , at http://developer.emc.com/developer/xmlproject/newsml/newsmlseriesoverview.htm.
However, see the notes at the beginning of each section on how the samples shown here have been
updated for the current release.
The NewsML DTD

This section contains the DTD for the NewsML example.
===========================================
NewsML Document Type Definition Version 1.0
===========================================
International Press Telecommunications Council
6 October 2000
Copyright (c) IPTC, 2000
All rights reserved
NewsML is a trademark of IPTC
======================================
DO NOT REMOVE THESE LICENCE CONDITIONS
======================================
LICENCE OF THE IPTC NewsML TRADEMARK TO NONMEMBERS OF THE IPTC
Use of the IPTC trademark shall be licensed by the IPTC

("the Licensor") to a NonMember ("the Licensee") in consideration
of the following obligations undertaken by the Licensee under the
terms of this contract.
1. The Licensee recognises the Licensor as the sole owner of the

intellectual property protected by the trademark.
2. The Licensee recognises that the Licensor has the right to grant
licenses of the intellectual property protected by the trademark and
has agreed to grant such a licence to the Licensee in the terms set
out in this contract.
3. The Licensee shall not during the subsistence of this contract or

at any future time register to use in its own name as proprietor any
of the intellectual property protected by the trademark.
4. The Licensee shall not claim any right title or interest in the
intellectual property or any part of it save as is granted by this
contract.
5. The Licensee shall immediately call to the attention of the

Licensor the use of any part of the intellectual property by any
third party or any activity of any third party which might in the
opinion of the Licensee amount to infringement of the rights
protected by the trademark.
6. The Licensee shall not assign the benefit of this contract or

grant any sublicence without the prior written consent of the
Licensor.
7. Use of the IPTC trademark is licensed only to those Licensees

who comply with the requirements of the official published description
of NewsML.
8. The Licensee promises to respect the integrity and quality

standard of the trademark and shall refrain from all acts and
omissions which threaten the integrity of the trademark as a mark
of quality.
9. The Licensee shall communicate immediately to the IPTC any

instances of actual or suspected misuse or noncompliance with the
official published description of NewsML which come to the attention
of the Licensee.
10. The Licensee shall, at the request of the IPTC Management

Committee acting unanimously, accede to any reasonable request of
the IPTC to inspect the address of the Licensee to verify compliance
and each Licensee shall afford to the IPTC such assistance as is
requested by the IPTC in response to the latter's reasonable
enquiries in instances of suspected noncompliance with the official
published description of NewsML requirements.
The Licensee shall from time to time provide the IPTC with the full
address of its place of business and that place will be deemed the
Licensee's address.
The IPTC reserves the right to terminate the use of the trademark by
the Licensee at any time without notice or without the need to give
]reasons to the Licensee for such termination.
This contract shall be governed and construed in accordance with the

laws of England and Wales whose courts shall be courts of competent
jurisdiction.
>
<!
================
NOTE ON SPELLING
================
NewsML element and attribute names use USEnglish spellings. With
this exception, this DTD and its accompanying specification use

British English spellings.

>
<!
=============================
PARAMETER ENTITY DECLARATIONS
=============================
>
<!
=================================================================
Attribute sets
=================================================================
>
<!
================================== assignment ====================
AssignedBy
==========
An identifier for the party assigning a piece of metadata. This can
be a string that designates the party informally (for example, a
person's name), or a pointer in the form a fragment identifier
consisting of a # character followed by the Duid of a Topic
corresponding to the party.
Importance
==========
An indication of the importance the party assigning a piece of
metadata attaches to it. The value of the Importance attribute is a
formal name for a level of importance. Its meaning and permitted
values are determined by a controlled vocabulary.
Confidence
==========
An indication of the confidence with which a piece of metadata has
been assigned. The value of the Confidence attribute is a formal name
for a degree of confidence. Its meaning and permitted values are
determined by a controlled vocabulary.
HowPresent
==========
An indication of the way in which a piece of metadata applies. The
value of the HowPresent attribute is a formal name for the way the
metadata applies. Its meaning and permitted values are determined by
a controlled vocabulary.
DateAndTime
===========
The date and (optionally) time at which a piece of metadata was
assigned.
Uses the format CCYYMMDDTHHMMSS{+or}HHMM (century, year, month, day,

time separator, hours, minutes, seconds, timezone separator, hours,
minutes). If only the Date is needed, then the substring from T
onwards may be omitted.
This is the Basic Format defined by ISO 8601. CCYY is a 4digit year
number.
MM is a 2digit month number. DD is a 2digit day number. T is the
letter 'T'.

HH is a 2digit hour number (using a 24hour clock). MM is a 2 digit

minute number. (Note that midnight may be represented as 240000 on
the date of the day that is ending, or as 000000 on the date of the day
that is beginning.)
{+or} is the '+' character or the '' character, and the following
HHMM are hours and minutes of offset from Universal Coordinated Time
(UTC) as defined by ISO 8601. If the time is being expressed in UTC,
then the timezone offset may be '+0000' or '0000'. If the time is
behind UTC, the timezone separator is ''. If the time is ahead of
UTC the timezone separator is '+'.
Example: 10:27 p.m. in New York on 31 December 2000 would be

expressed as "20001231T2227000500" as New York is five hours behind
UTC in winter. At the same moment in London, the date and time would
be expressed as "20010101T032700+0000" or as "20010101T0327000000"
because in London it is now 3:27 a.m. on 1 January 2001. At the same
moment in Paris,the date and time would be expressed as
"20010101T042700+0100", because Paris is one hour ahead of UTC
in winter and it is now 4:27 a.m. on 1 January 2001.
===============================================================
>
<!ENTITY % assignment " AssignedBy CDATA #IMPLIED
Importance CDATA #IMPLIED
Confidence CDATA #IMPLIED
HowPresent CDATA #IMPLIED
DateAndTime CDATA #IMPLIED">
<!
================================= formalname ==================
FormalName
==========
A string of characters whose meaning is determined by a controlled
vocabulary.
Vocabulary
==========
The Vocabulary attribute, if present, provides a pointer to a
TopicSet which is the controlled vocabulary that can be used to
resolve the meaning of the FormalName. The value of the Vocabulary
attribute is an http URL or a NewsML URN, or the # character followed
by the value of the Duid attribute of the a TopicSet in the current
document.
If there is no Vocabulary attribute, then the controlled vocabulary

to be used is located by the following algorithm: Proceed to the
parent of the current element.
If it has a Catalog element as its immediate child, see whether
that Catalog contains a Resource element whose DefaultVocabularyFor
child contains an XPath pattern that is matched by the current
element. If so, then the controlled vocabulary is the resource
identified by that Resource element.
If the parent does not meet the above condition, proceed to its
parent and check the same condition.
Continue until a vocabulary is found, or no further parent elements
are available because the root element has been reached and it too

fails to meet the condition.
If there is no Vocabulary attribute and the above algorithm fails to

identify a resource that serves as the controlled vocabulary, there
is an error, which the NewsML system may signal to the user.
The NewsML system may also signal an error if a vocabulary is

successfully identified, but it contains no item that matches the
value of the FormalName whose meaning is sought.
Scheme
======
The Scheme attribute, if present, serves to distinguish which of
possibly multiple naming schemes in the controlled vocabulary is the
one that governs this FormalName. For a match to be obtained within
the controlled vocabulary, the rule is that the FormalName and the
Scheme must both match. If there is no Scheme attribute on the
current element, the match will be to an item in the vocabulary that
has the current formal name and no scheme. If there is a Scheme
attribute on the current element, then both the formal name and the
scheme in the controlled vocabulary must match.
================================================================
>
<!ENTITY % formalname " FormalName CDATA #REQUIRED
Vocabulary CDATA #IMPLIED
Scheme CDATA #IMPLIED">
<!
=================================== localid =====================
Duid
====
Duid is a "Documentunique Identifier". It must satisfy the rules
for XML ID attributes: it must only contain name characters, and it
must start with a namestart character (not a digit). Its value must
be unique within any NewsML document.
Every NewsML element type has Duid as an optional attribute. Combined

with the Identifier element, providing a value for the Duid of any
element in a NewsML document makes the element globally identifiable.
The Identifier element gives global identification to the document,
and the Duid provides local identification for the element within the
document.
Euid
====
Euid is an "Elementunique Identifier". Its value must be unique
among elements of the same elementtype and having the same parent
element.
Use of Euid attribute makes it possible to identify any NewsML

element within the context of its local branch of the NewsML document
tree. This makes it possible to copy, or include by reference,
subtrees into new combinations in ways that would break the
uniqueness of Duids (thereby forcing new Duids to be allocated), but
still being able to retain the identity of each element. If Euids are
maintained at every level, it is possible to identify, for example
"The ContentItem whose Euid is abc within the NewsComponent whose

Euid is def". Such identification patterns would be preserved even

after "pruning and grafting" of subtrees.
=================================================================
>
<!ENTITY % localid " Duid ID #IMPLIED
Euid CDATA #IMPLIED">
<!
=================================================================
Content Models
==================================================================
>
<!
===================================== data =======================
Where data is included, it may be directly in the form of a
DataContent element, or in the form of DataContent wrapped in an
Encoding element, or by reference through an Href attribute, in
which case neither a DataContent nor an Encoding element will be
present.
==================================================================
>
<!ENTITY % data " (Encoding
| DataContent )?">
<!
==================================== party ========================
Person, organisation or company playing a specific role in the
news workflow. The role being played is determined by the parent
element. More information about it can be provided in the optional
Comment subelements.
===================================================================
>
<!ENTITY % party " (Comment*
, Party+ )">
<!
=============== Documentum attributes =================
Documentum attributes to be added to each element that
has an <xml_content_rule> or <xml_link_rule> in the XML
application configuration file
=======================================================
>
<!ENTITY % dctmatts
dctm:version_label CDATA #IMPLIED"
>
<!ENTITY % dctmlinkatts
dctm:link_obj_id CDATA #IMPLIED
dctm:link_obj_status CDATA #IMPLIED
dctm:link_version_label CDATA #IMPLIED">
<!
=========================
ELEMENT TYPE DECLARATIONS
=========================

>
<!
============================ AdministrativeMetadata ===============
Information about the provenance of a NewsComponent.
====================================================================
>
<!ELEMENT AdministrativeMetadata (Catalog?, FileName?,
SystemIdentifier?, Provider?, Creator?, Source*, Contributor*,
Property*)>
<!ATTLIST AdministrativeMetadata
%localid;
>
<!
================================ AssociatedWith ====================

A reference to a NewsItem with which this one is associated (for
example, a series of articles, or a collection of photos, of which
it is a part). The NewsItem attribute identifies the relevant
NewsItem. Its value can be an http URL or a NewsML URN as described
in the comment to PublicIdentifier. The Comment can be used to
indicate the nature of the association.
====================================================================
>
<!ELEMENT AssociatedWith (Comment*)>
<!ATTLIST AssociatedWith
%localid;
NewsItem CDATA #IMPLIED
>
<!
================================ BasisForChoice ====================
The content of this element is an XPath statement or elementtype
name identifying information within each NewsComponent or ContentItem
that can be used as a basis for choice between equivalent
NewsComponents or ContentItems.
If the XPath pattern begins with a . character, this represents the
'root' of the XPath and corresponds to the NewsComponent or ContentItem
itself. By applying the XPath pattern to each NewsComponent or
ContentItem in turn within the set of equivalents, the system can
extrac the data on the basis of which a choice between the items can
be made. If multiple matches to the XPath pattern are present within
the subtree that begins at the 'root', only the first match found in
document order is significant. The optional Rank attribute allows
providers to place a numerical order on the importance they think
should be attached to the different bases for choice. Smaller numbers
represent higher importance.
====================================================================
>
<!ELEMENT BasisForChoice (#PCDATA)>
<!ATTLIST BasisForChoice
%localid;
Rank CDATA #IMPLIED
>
<!
==================================== ByLine ========================

A naturallanguage statement of the author/creator information.

====================================================================
>
<!ELEMENT ByLine (#PCDATA | Origin)*>
<!ATTLIST ByLine
%localid;
xml:lang CDATA #IMPLIED
>
<!
=================================== Catalog ========================
A container for Resource and TopicUse elements. Resource elements map
URNs to URLs and indicate default vocabularies which apply to the
formal names of certain elements within the subtree that begins with
the immediate parent of the Catalog element. TopicUse elements
indicate where in the NewsML document certain Topics are used. The
optional Href attribute provides a pointer to a Catalog element
elsewhere in this or another document. Its value consists of a #
character followed by the value of the Duid attribute of the
referenced Catalog element and preceded, if the referenced Catalog
is not in the current document, by an http URL or a NewsML URN
identifying the document or NewsItem in which the Catalog appears.
If the Href attribute is present on a Catalog element, then that
element should be empty. If it contains subelements, the NewsML
system may signal an error.
====================================================================
>
<!ELEMENT Catalog (Resource*, TopicUse*)>
<!ATTLIST Catalog
%localid;
Href CDATA #IMPLIED
>
<!
=============================== Characteristics ====================
Information about the physical characteristics of a ContentItem.
====================================================================
>
<!ELEMENT Characteristics (SizeInBytes?, Property*)>
<!ATTLIST Characteristics
%localid;
>
<!
=================================== Comment ========================
A naturallanguage description of, or statement about, the current
element. The optional TranslationOf attribute is a pointer to another
Comment element, of which this one is a direct translation.
====================================================================
>
<!ELEMENT Comment (#PCDATA)>
<!ATTLIST Comment
%localid;
TranslationOf IDREF #IMPLIED
>
<!
================================= ContentItem ======================
A news object that carries or identifies content intended for
presentation to humans.
====================================================================

>
<!ELEMENT ContentItem (Comment*, Catalog?, MediaType?, Format?,
MimeType?, Notation?, Characteristics?, %data;)>
<!ATTLIST ContentItem
%localid;
%dctmatts;
%dctmlinkatts;
Href CDATA #IMPLIED
>
<!
================================= Contributor ======================
An individual and/or company or organisation that modified or
enhanced a news object after its creation.
====================================================================
>
<!ELEMENT Contributor (%party;)>
<!ATTLIST Contributor
%localid;
>
<!
================================== Copyright =======================
The copyright that pertains to a news object.
====================================================================
>
<!ELEMENT Copyright (Comment*, CopyrightHolder, CopyrightDate)>
<!ATTLIST Copyright
%localid;
%assignment;
>
<!
================================ CopyrightDate =====================
A naturallanguage statement of the copyright date.
====================================================================
>
<!ELEMENT CopyrightDate (#PCDATA | Origin)*>
<!ATTLIST CopyrightDate
%localid;
>
<!
=============================== CopyrightHolder ====================
A naturallanguage statement indicating who owns the copyright.
====================================================================
>
<!ELEMENT CopyrightHolder (#PCDATA | Origin)*>
<!ATTLIST CopyrightHolder
%localid;
>
<!
================================ CopyrightLine =====================
A naturallanguage statement of the copyright information.
====================================================================
>
<!ELEMENT CopyrightLine (#PCDATA | Origin)*>
<!ATTLIST CopyrightLine

%localid;
>
<!
=================================== Creator ========================
An individual and/or company or organisation that created a news
object.
====================================================================
>
<!ELEMENT Creator (%party;)>
<!ATTLIST Creator
%localid;
>
<!
================================== CreditLine ======================
A naturallanguage statement of credit information.
====================================================================
>
<!ELEMENT CreditLine (#PCDATA | Origin)*>
<!ATTLIST CreditLine
%localid;
>
<!
================================= DataContent ======================
The data that carries the content of a ContentItem.
====================================================================
>
<!ELEMENT DataContent ANY>
<!ATTLIST DataContent
%localid;
>
<!
================================= DateAndTime ======================
A formal representation of a date and, optionally, time, expressed in
ISO 8601 Basic Format, as described in the comment to the DateAndTime
attribute within the assignment ENTITY declaration above.
====================================================================
>
<!ELEMENT DateAndTime (#PCDATA)>
<!ATTLIST DateAndTime
%localid;
>
<!
==================================== DateId ========================
A date identifier of a NewsItem in short ISO 8601 Basic Format
(CCYYMMDD), as described in the comment to the DateAndTime attribute
within the assignment ENTITY declaration above. The DateId is part of
the formal identification of the NewsItem, and must remain the same
through successive revisions of the same NewsItem.
====================================================================
>
<!ELEMENT DateId (#PCDATA)>
<!
================================== DateLabel =======================
A string representation of a date or date and time, used by human
users to help identify a NewsItem.

====================================================================
>
<!ELEMENT DateLabel (#PCDATA)>
<!ATTLIST DateLabel
%localid;
>
<!
=================================== DateLine =======================
A naturallanguage statement of the date and/or place of creation.
====================================================================
>
<!ELEMENT DateLine (#PCDATA | Origin)*>
<!ATTLIST DateLine
%localid;
>
<!
============================ DefaultVocabularyFor ==================
An indication that the parent Resource provides the default
vocabulary that determines the meanings and permitted values of the
data occurring in a particular part of a NewsML document subtree.
The Context attribute is an XPath pattern identifying the data to
which the default vocabulary applies. If the XPath pattern is one
that matches elements, then it is the value of the FormalName
attribute of that element that is designated. If the XPath pattern
is one that matches attributes, then it is the value of that
attribute itself that is designated. The optional Scheme attribute
identifies the relevant naming scheme if the Resource contains more
than one naming scheme. If the Resource is a NewsML TopicSet, then
the meaning of the data identified by the Context is provided by the
Topic whose FormalName subelement matches that data. If the Resource
is not a NewsML TopicSet, then the way in which it is interpreted in
order to provide a meaning for the data is not defined by NewsML but
by the authority that governs whatever format the Resource uses.
Example:
<NewsComponent>
<Catalog>
<Resource Duid="resource1">
<Urn>urn:newsml:iptc.org:20001006:Confidence:1</Urn>
<Url>www.iptc.org/NewsML/topicsets/iptcconfidence.xml</Url>
<DefaultVocabularyFor Context="@Confidence"/>
</Resource>
<Urn>urn:newsml:iptc.org:20001006:Confidence:1</Urn>
<Url>www.iptc.org/NewsML/topicsets/iptcconfidence.xml</Url>
<DefaultVocabularyFor Context="@Confidence"/>
</Resource>
<Urn>urn:newsml:iptc.org:20001006:HowPresent:1</Urn>
<Url>www.iptc.org/NewsML/topicsets/iptchowpresent.xml</Url>
<DefaultVocabularyFor Context="@HowPresent"/>
</Resource>
</Catalog>
<TopicSet FormalName="Person">
<Topic Duid="topic1">
<TopicType FormalName="Person">

<Description Variant="Name">Bill Clinton</Description>

<Description Variant="Position">President of the USA</Description>
</Topic>
</TopicSet>
</DescriptiveMetadata>
<TopicOccurrence
AssignedBy="Desk Editor"
Confidence="High"
HowPresent="Primary"
Topic="#topic1"/>
</DescriptiveMetadata>
...
</NewsComponent>
====================================================================
>
<!ELEMENT DefaultVocabularyFor EMPTY>
<!ATTLIST DefaultVocabularyFor
%localid;
Context CDATA #REQUIRED
Scheme CDATA #IMPLIED
>
<!
==================================== Delete ========================
An instruction to delete an element within a NewsItem. The NewsItem
is the previous revision of the current one, and the element to be
deleted is the one whose Duid value is equal to the value of the
Delete element's DuidRef attribute.
====================================================================
>
<!ELEMENT Delete EMPTY>
<!ATTLIST Delete
%localid;
DuidRef CDATA #REQUIRED
>
<!
================================= DerivedFrom ======================
A reference to an NewsItem from which this one is derived. The
NewsItem attribute identifies the relevant NewsItem. Its value can
be an http URL or a NewsML URN as described in the comment to
PublicIdentifier.
====================================================================
>
<!ELEMENT DerivedFrom (Comment*)>
<!ATTLIST DerivedFrom
%localid;
>
<!
================================= Description ======================
A description that identifies a Topic, thereby indicating the meaning
of a formal name associated with that Topic. The xml:lang attribute
indicates what language the description is in. The optional Variant
attribute allows multiple descriptions to be given in the same
language, and meaningfully distinguished from one another.
====================================================================
>

<!ELEMENT Description (#PCDATA)>

<!ATTLIST Description
%localid;
Variant CDATA #IMPLIED
>
<!
============================= DescriptiveMetadata ==================
Information describing the content of a NewsComponent.
====================================================================
>
<!ELEMENT DescriptiveMetadata (Catalog?, Language*, Genre?,
SubjectCode*, OfInterestTo*, TopicOccurrence*, Property*)>
<!ATTLIST DescriptiveMetadata
%localid;
%assignment;
>
<!
=================================== Encoding =======================
The encoding of the data comprising the content of a ContentItem.
====================================================================
>
<!ELEMENT Encoding %data;>
<!ATTLIST Encoding
%localid;
Notation CDATA #REQUIRED
>
<!
=================================== EndDate ========================
A naturallanguage statement of the date at which specified usage
rights come to an end.
====================================================================
>
<!ELEMENT EndDate (#PCDATA | Origin)*>
<!ATTLIST EndDate
%localid;
%assignment;
>
<!
=================================== FileName =======================
The suggested or actual storage file name for a NewsItem.
====================================================================
>
<!ELEMENT FileName (#PCDATA)>
<!ATTLIST FileName
%localid;
>
<!
================================= FirstCreated =====================
The date and, optionally, time at which a NewsItem was first created,
expressed in ISO 8601 Basic Format, as described in the comment to
the DateAndTime attribute within the assignment ENTITY declaration
above.
====================================================================
>
<!ELEMENT FirstCreated (#PCDATA)>

<!ATTLIST FirstCreated
%localid;
>
<!
================================= FormalName =======================
A string of characters whose meaning is determined by a naming scheme
within a controlled vocabulary. The controlled vocabulary may (but is
not required to) take the form of a NewsML TopicSet. The optional
Scheme attribute determines which naming scheme applies, when several
exist within the same controlled vocabulary.
====================================================================
>
<!ELEMENT FormalName (#PCDATA)>
<!ATTLIST FormalName
%localid;
>
<!
==================================== Format ========================
An indication of the format of a ContentItem. The value of the
FormalName attribute is a formal name for the Format. Its meaning and
permitted values are determined by a controlled vocabulary as
described in the comment to the formalname ENTITY declaration above.
====================================================================
>
<!ELEMENT Format EMPTY>
<!ATTLIST Format
%localid;
%formalname;
>
<!
================================= FutureStatus =====================
An indication of the status a NewsItem will have at a specified
future date. The value of the FormalName attribute is a formal name
for the FutureStatus. Its meaning is determined by a controlled
vocabulary as described in the comment to the formalname ENTITY
declaration above.
====================================================================
>
<!ELEMENT FutureStatus EMPTY>
<!ATTLIST FutureStatus
%localid;
%formalname;
>
<!
==================================== Genre =========================
An indication of the Genre of a NewsComponent. The value of the
FormalName attribute is a formal name for the Genre. Its meaning and
====================================================================
>
<!ELEMENT Genre EMPTY>
<!ATTLIST Genre
%localid;
%formalname;
%assignment;

>
<!
================================== Geography =======================
A naturallanguage statement of the geographical area or areas to
which specified usage rights apply.
====================================================================
>
<!ELEMENT Geography (#PCDATA | Origin)*>
<!ATTLIST Geography
%localid;
%assignment;
>
<!
=================================== HeadLine =======================
A displayable headline.
====================================================================
>
<!ELEMENT HeadLine (#PCDATA | Origin)*>
<!ATTLIST HeadLine
%localid;
>
<!
================================ Identification ====================
Identification information for the NewsItem.
====================================================================
>
<!ELEMENT Identification (NewsIdentifier, NameLabel?, DateLabel?,
Label*)>
<!ATTLIST Identification
%localid;
>
<!
================================= InsertAfter ======================
An instruction to insert content after a designated element within a
NewsItem. The content to be inserted is the content of the InsertAfter
element. The NewsItem into which it is to be inserted is the previous
revision of the current one, and the element after which it is to be
inserted is the one whose Duid value is equal to the value of the
InsertAfter element's DuidRef attribute.
====================================================================
>
<!ELEMENT InsertAfter ANY>
<!ATTLIST InsertAfter
%localid;
>
<!
================================= InsertBefore =====================
An instruction to insert content before a designated element within a
NewsItem. The content to be inserted is the content of the
InsertBefore element. The NewsItem into which it is to be inserted is
the previous revision of the current one, and the element before
which it is to be inserted is the one whose Duid value is equal to
the value of the InsertBefore element's DuidRef attribute.
====================================================================

>
<!ELEMENT InsertBefore ANY>
<!ATTLIST InsertBefore
%localid;
>
<!
================================= Instruction ======================
An instruction from a news provider to the recipient of a NewsItem. A
special case of Instruction is an indication of the effect the current
revision of a NewsItem has on the status of any previous revisions of
the NewsItem that may still be on the recipient's system. In this
case, it will contain one or more RevisionStatus elements. Otherwise,
the value of the FormalName attribute is a formal name for the
Instruction, and its meaning is determined by a controlled vocabulary
as described in the comment to the formalname ENTITY declaration above.
====================================================================
>
<!ELEMENT Instruction (RevisionStatus*)>
<!ATTLIST Instruction
%localid;
%formalname;
>
<!
================================= KeywordLine ======================
A displayable set of keywords relevant to a news object. This can be
used by a NewsML system to assist manual or automated searches.
====================================================================
>
<!ELEMENT KeywordLine (#PCDATA | Origin)*>
<!ATTLIST KeywordLine
%localid;
>
<!
==================================== Label =========================
A humanreadable label for a NewsItem.
====================================================================
>
<!ELEMENT Label (LabelType, LabelText)>
<!ATTLIST Label
%localid;
>
<!
=================================== LabelText ======================
The text that constitutes a Label of a given LabelType.
====================================================================
>
<!ELEMENT LabelText (#PCDATA)>
<!ATTLIST LabelText
%localid;
>
<!
================================= LabelType ========================
A userdefined type of label. The value of the FormalName attribute
is a formal name for the LabelType. Its meaning and permitted values
are determined by a controlled vocabulary as described in the comment

to the formalname ENTITY declaration above.

====================================================================
>
<!ELEMENT LabelType EMPTY>
<!ATTLIST LabelType
%localid;
%formalname;
>
<!
=================================== Language =======================
An indication of the, or a, language used in a content item. The
value of the FormalName attribute is a formal name for the Language.
Its meaning and permitted values are determined by a controlled
declaration above.
====================================================================
>
<!ELEMENT Language EMPTY>
<!ATTLIST Language
%localid;
%formalname;
%assignment;
>
<!
================================= Limitations ======================
A naturallanguage statement of the terms and conditions that apply
to the specified usage rights.
====================================================================
>
<!ELEMENT Limitations (#PCDATA | Origin)*>
<!ATTLIST Limitations
%localid;
%assignment;
>
<!
================================== MediaType =======================
An indication of the media type of a ContentItem. The value of the
FormalName attribute is a formal name for the MediaType. Its meaning
and permitted values are determined by a controlled vocabulary as
====================================================================
>
<!ELEMENT MediaType EMPTY>
<!ATTLIST MediaType
%localid;
%formalname;
>
<!
=================================== Metadata =======================
An container for a userdefined type of metadata.
====================================================================
>
<!ELEMENT Metadata (Catalog?, MetadataType, Property+)>
<!ATTLIST Metadata
%localid;
>

<!
=============================== MetadataType =======================
An indication of the type of metadata that is represented by the
Property elements within this Metadata element. The value of the
FormalName attribute is a formal name for the MetadataType. Its
meaning and permitted values are determined by a controlled
declaration above.
====================================================================
>
<!ELEMENT MetadataType EMPTY>
<!ATTLIST MetadataType
%localid;
%formalname;
>
<!
=================================== MimeType =======================
An indication of the MIMEtype of a ContentItem. The value of the
FormalName attribute is a formal name for the MimeType. Its meaning
====================================================================
>
<!ELEMENT MimeType EMPTY>
<!ATTLIST MimeType
%localid;
%formalname;
>
<!
================================== NameLabel =======================
A string used by human users as a name to help identify a NewsItem.
Its form is determined by the provider. It might be identical to the
textual content of the SlugLine element, for example, but even if
this is so, the system should not process the NameLabel as a slugline.
Nothing can be assumed about the nature of the string within NameLabel
beyond the fact that it can help to identify the NewsItem to humans.
====================================================================
>
<!ELEMENT NameLabel (#PCDATA)>
<!ATTLIST NameLabel
%localid;
>
<!
================================ NewsComponent =====================
A container for news objects, used to identify the role of news
objects in relation to one another, and to ascribe metadata to them.
The Essential attribute indicates whether the provider considers that
this NewsComponent is essential to the meaning of the NewsComponent
within which it is contained. The EquivalentsList attribute indicates
whether or not the NewsItems or NewsItemRefs, NewsComponents or
ContentItems contained within this one are equivalent to one another
in content and/or meaning
====================================================================
>
<!ELEMENT NewsComponent (Comment*, Catalog?, TopicSet*, Role?,
BasisForChoice*, NewsLines?, AdministrativeMetadata?,
RightsMetadata?, DescriptiveMetadata?, Metadata*, ((NewsItem |

NewsItemRef)+ | NewsComponent+ | ContentItem+)?)>

<!ATTLIST NewsComponent
%localid;
%dctmatts;
Essential (yes | no) "no"
EquivalentsList (yes | no) "no"
>
<!
================================= NewsEnvelope =====================
Information about the transmission of one or more NewsItems as a
NewsML document.
====================================================================
>
<!ELEMENT NewsEnvelope (TransmissionId?, SentFrom?, SentTo?,
DateAndTime, NewsService*, NewsProduct*, Priority?)>
<!ATTLIST NewsEnvelope
%localid;
>
<!
================================ NewsIdentifier ====================
A globally unique identifier for a NewsItem.
====================================================================
>
<!ELEMENT NewsIdentifier (ProviderId, DateId, NewsItemId, RevisionId,
PublicIdentifier)>
<!
=================================== NewsItem =======================
A managed set of information representing a point of view, at a given
time, on some event or events. Its Identification and NewsManagement
provide manageability. It may contain either a NewsComponent, or one
or more Updates that modify aspects of a previous Revision of the same
NewsItem, or a TopicSet.
====================================================================
>
<!ELEMENT NewsItem (Comment*, Catalog?, Identification, NewsManagement,
(NewsComponent | Update+ | TopicSet)?)>
<!ATTLIST NewsItem
%localid;
%dctmatts;
>
<!
================================== NewsItemId ======================
An identifier for the NewsItem. The combination of NewsItemId and
DateId must be unique among NewsItems that emanate from the same
provider. Within these constraints, the NewsItemId can take any form
the provider wishes. It may take the form of a name for the NewsItem
that will be meaningful to humans, but this is not a requirement. The
provider may optionally relate the values of NewsItemId to a
controlled vocabulary, which is invoked by the Vocabulary attribute.
The value ofthe Vocabulary attribute may be an http URL, a NewsML
URN, or the # character followed by the value of the Duid attribute
of a TopicSet in the current document. The Scheme attribute, if
present, serves to distinguish which of possibly multiple naming
schemes in the controlled vocabulary is the one that governs the
NewsItemId.

====================================================================
>
<!ELEMENT NewsItemId (#PCDATA)>
<!ATTLIST NewsItemId
>
<!
================================= NewsItemRef ======================
A pointer to a NewsItem that is deemed to replace the NewsItemRef
element. The NewsItem attribute is a pointer to the relevant
NewsItem. Its value can be an http URL, or a NewsML URN as described
in the comment to PublicIdentifier, or a fragment identifier
consisting of a # character followed by the Duid of a NewsItem in
the current document.
====================================================================
>
<!ELEMENT NewsItemRef (Comment*)>
<!ATTLIST NewsItemRef
%localid;
>
<!
================================= NewsItemType =====================
An indication of the type of a NewsItem. The value of the FormalName
attribute is a formal name for the NewsItemType. Its meaning and
====================================================================
>
<!ELEMENT NewsItemType EMPTY>
<!ATTLIST NewsItemType
%localid;
%formalname;
>
<!
=================================== NewsLine =======================
A newsline of a type not included in the NewsML specification.
====================================================================
>
<!ELEMENT NewsLine (NewsLineType, NewsLineText+)>
<!ATTLIST NewsLine
%localid;
>
<!
=================================== NewsLineText ===================
The text of a NewsLine of userdefined type.
====================================================================
>
<!ELEMENT NewsLineText (#PCDATA | Origin)*>
<!ATTLIST NewsLineText
%localid;
>
<!
================================ NewsLineType ======================
An indication of a userdefined NewsLine type. The value of the

FormalName attribute is a formal name for the NewsLineType. Its

declaration above.
====================================================================
>
<!ELEMENT NewsLineType EMPTY>
<!ATTLIST NewsLineType
%localid;
%formalname;
>
<!
================================== NewsLines =======================
A container for all the NewsLines that a NewsComponent has.
====================================================================
>
<!ELEMENT NewsLines ((HeadLine, SubHeadLine?)*, ByLine*, DateLine*,
CreditLine*, CopyrightLine*, RightsLine*, SeriesLine*, SlugLine*,
KeywordLine*, NewsLine*)>
<!ATTLIST NewsLines
%localid;
>
<!
================================ NewsManagement ====================
Information relevant to the management of a NewsItem.
====================================================================
>
<!ELEMENT NewsManagement (NewsItemType, FirstCreated,
ThisRevisionCreated, Status, StatusWillChange?, Urgency?,
RevisionHistory?, DerivedFrom*, AssociatedWith*, Instruction*,
Property*)>
<!ATTLIST NewsManagement
%localid;
>
<!
==================================== NewsML ========================
A NewsML document, which must contain a NewsEnvelope and one or more
NewsItems, and may include a Catalog element and a TopicSet element.
====================================================================
>
<!ELEMENT NewsML (Catalog?, TopicSet*, (NewsEnvelope, NewsItem+))>
<!ATTLIST NewsML
%localid;
%dctmatts;
>
<!
================================= NewsProduct ======================
An identifier for a product to which all the NewsItems in a NewsML
document belong. The value of the FormalName attribute is a formal
name for the NewsProduct. Its meaning and permitted values are
determined by a controlled vocabulary as described in the comment to
the formalname ENTITY declaration above.
====================================================================
>
<!ELEMENT NewsProduct EMPTY>
<!ATTLIST NewsProduct
%localid;

%formalname;
>
<!
================================= NewsService ======================
An identifier for a service to which all the NewsItems in a NewsML
document belong. The value of the FormalName attribute is a formal
name for the NewsService. Its meaning and permitted values are
====================================================================
>
<!ELEMENT NewsService EMPTY>
<!ATTLIST NewsService
%localid;
%formalname;
>
<!
=================================== Notation =======================
An indication of the notation of a ContentItem. The value of the
FormalName attribute is a formal name for the Notation. Its meaning
====================================================================
>
<!ELEMENT Notation EMPTY>
<!ATTLIST Notation
%localid;
%formalname;
>
<!
================================= OfInterestTo =====================
An indication of the target audience of a NewsItem. The value of the
FormalName attribute is a formal name for the target audience. Its
declaration above.
====================================================================
>
<!ELEMENT OfInterestTo (Relevance?)>
<!ATTLIST OfInterestTo
%localid;
%formalname;
%assignment;
>
<!
==================================== Origin ========================
A wrapper for all or part of the text of a piece of text, which
provides a pointer to an item of data corresponding formally to what
is being described here in natural language. The Href attribute
identifies the relevant data, and may be an http URL or a NewsML URN
as described in the comment to PublicIdentifier, optionally including
a fragment identifier. Alternatively, it can be a simple fragment
identifier consisting of a # character followed by the value of the
Duid of an element in the current document.
====================================================================
>
<!ELEMENT Origin (#PCDATA | Origin)*>

<!ATTLIST Origin
%localid;
%assignment;
Href CDATA #IMPLIED
>
<!
=================================== Party ==========================
An indication of the person, company or organisation that has a
particular relationship to this NewsItem in the news workflow. The
value of the FormalName attribute is a formal name for the Party.
Its meaning and permitted values are determined by a controlled
declaration above. The optional Topic attribute may be used as
a direct pointer to that Topic. The pointer may take the form of an
http URL or a NewsML URN, or a # character followed by the value of
the Duid attribute of a Topic element in the current document.
====================================================================
>
<!ELEMENT Party EMPTY>
<!ATTLIST Party
%localid;
%formalname;
Topic CDATA #IMPLIED
>
<!
=================================== Priority =======================
An indication of the priority notation of a NewsItem. The value of
the FormalName attribute is a formal name for the Priority. Its
declaration above.
====================================================================
>
<!ELEMENT Priority EMPTY>
<!ATTLIST Priority
%localid;
%formalname;
>
<!
=================================== Property =======================
A property of a NewsItem, NewsComponent, ContentItem or Topic. The
property has a name and either a simple Value or a complex value
consisting of a set of further properties.
Value
=====
A string representation of the value of a Property.
ValueRef
========
A pointer to the value of the Property. This might be a Topic in a
TopicSet, or any other piece of data. If both Value and ValueRef are
provided, then ValueRef identifies the actual value of the property,
with Value simply providing a string representation or mnemonic for
it.
Example:

<Catalog>
<Urn>urn:newsml:reuters.com:20001001:Physical Characteristics:3</Urn>
<Url>www.reuters.com/vocabs/physical.xml</Url>
<Url>www.iptc.com/vocabularies/memberdefined/reuters/physical.xml
</Url>
<DefaultVocabularyFor Scheme="short" Context=
"Metadata/Property[@FormalName='Width']"/>
</Resource>
</Catalog>
...
<Property FormalName="Width" Vocabulary="#resource1">
<Property FormalName="Unit" ValueRef=
"urn:newsml:iptc.org:20001006:units:1#cm"/>
<Property FormalName="Quantity" Value="7.5"/>
</Property>
AllowedValues
=============
The AllowedValues attribute, if present, is a pointer to a controlled
vocabulary that delimits the set of allowed values for the property.
This may be an http URL, or a NewsML URN, or a fragment identifier
consisting of a # charactger followed by the Duid of an element in
the current document. The pointer must reference either a Resource
element that designates an external controlled vocabulary, or a
TopicSet element, that is itself the controlled vocabulary.
====================================================================
>
<!ELEMENT Property (Property*)>
<!ATTLIST Property
%localid;
%formalname;
%assignment;
Value CDATA #IMPLIED
ValueRef CDATA #IMPLIED
AllowedValues CDATA #IMPLIED
>
<!
=================================== Provider =======================
An individual and/or company or organisation that released a news
object for publication.
====================================================================
>
<!ELEMENT Provider (%party;)>
<!ATTLIST Provider
%localid;
>
<!
================================== ProviderId ======================
An identifier for the news provider that produced the NewsItem. The
provider's ID is specified in the element content. This should be an
Internet domain name that is owned by the provider at the date
identified by the DateId subelement of the NewsIdentifier.
Example:
<NewsIdentifier>
<ProviderId>iptc.org</ProviderId>

<DateId>20001001</DateId>
<NewsItemId>NewsML version 1.0</NewsItemId>
<RevisionId>1</RevisionId
</NewsIdentifier>
Because the domain name "iptc.org" was owned on 1 October 2000 by the
International Press Telecommunications Council (IPTC) and noone else,
it is certain that IPTC is the provider in this case.
====================================================================
>
<!ELEMENT ProviderId (#PCDATA)>
<!ATTLIST ProviderId
>
<!
=============================== PublicIdentifier ===================
A public identifier (in the sense defined by the XML 1,0
Specification) for a NewsItem. This is the NewsML URN, and must be
constructed as follows:
urn:newsml:{ProviderId}:{DateId}:{NewsItemId}:{RevisionId}
{RevisionId@Update}
where {x} means "the content of the x subelement of the

NewsIdentifier" and {x@y} means "the value of the y attribute of the
x subelement of the NewsIdentifier", with the exception that if the
Update attribute of the RevisionId element has its default value of
N, it is omitted from the URN.
Note that the set of characters that can be included within a URN is
limited. The allowed characters are specified by the Internet
Engineering Task Force (IETF) in its Request For Comments (RFC)
number 2141. This document is available at
http://www.ietf.org/rfc/rfc2141.txt. Any character that is not
within the permitted URN character set must be represented as a %
character followed by the sequence of one to six bytes of its UTF8
encoding, represented in their hexadecimal form. Thus, for example,
the space character in a URN would appear as %20, and the % character
itself would appear as %25. This mechanism does not cater for all
Unicode or UTF16 characters. Therefore, it is important not to
include characters in a NewsItemId that cannot be encoded in UTF8.
Note that the existence of this URN enables the NewsItem to be

referenced unambiguously by pointers from other XML elements or
resources. Within such pointers, if the RevisionId, its preceding :
character and its following Update qualifier are omitted, then the
pointer designates the most recent revision at the time it is resolved.
====================================================================
>
<!ELEMENT PublicIdentifier (#PCDATA)>
<!
================================== Relevance =======================
An indication of the relevance of a NewsItem to a given target
audience. The value of the FormalName attribute is a formal name for
the Relevance. Its meaning and permitted values are determined by a
controlled vocabulary as described in the comment to the formalname
ENTITY declaration above.

====================================================================
>
<!ELEMENT Relevance EMPTY>
<!ATTLIST Relevance
%localid;
%formalname;
%assignment;
>
<!
=================================== Replace ========================
An instruction to replace a designated element within a NewsItem.
The element that is to replace the designated element is the content
of the Replace element. The NewsItem within which the replacement
takes place is the previous revision of the current one, and the
element to be replaced is the one whose Duid value is equal to the
value of the Replace element's DuidRef attribute.
====================================================================
>
<!ELEMENT Replace ANY>
<!ATTLIST Replace
%localid;
>
<!
================================== Resource ========================
An indication where a given resource can be found, and whether it is
to be used as the default vocabulary for certain formal names within
the current subtree of a NewsML document. The Urn attribute provides
a NewsML URN for the resource.
THe Url attribute(s) provide(s) a location or locations where the
resource may be found. The DefaultVocabularyFor element contains an
XPath pattern. The identified resource acts as default vocabulary for
any element within the subtree whose root is the parent of the
current Catalog, that matches this XPath pattern.
====================================================================
>
<!ELEMENT Resource (Urn?, Url*, DefaultVocabularyFor*)>
<!ATTLIST Resource
%localid;
>
<!
=============================== RevisionHistory ====================
A pointer to a file containing the revision history of the NewsItem.
====================================================================
>
<!ELEMENT RevisionHistory EMPTY>
<!ATTLIST RevisionHistory
%localid;
Href CDATA #REQUIRED
>
<!
================================== RevisionId ======================
A positive integer indicating which Revision of a given NewsItem this
is. Any positive integer may be used, but it must always be the case
that of two instances of a NewsItem that have the same ProviderId,
DateId and NewsItemId, the one whose RevisionId has the larger value
must be the more recent revision.

A RevisionId of 0 is not permitted. The PreviousRevision attribute

must be present, and its value must be equal to the content of the
RevisionId element of the NewsItem's previous revision, if there is
one, and 0 if the NewsItem has no previous revision. If the NewsItem
contains an Update element or elements, then the Update attribute
must be set to U. If the NewsItem consists only of a replacement set
of NewsManagement data, then the Update attribute must be set to A.
If neither of these is the case, then the Update attribute must be
set to N.
====================================================================
>
<!ELEMENT RevisionId (#PCDATA)>
<!ATTLIST RevisionId
PreviousRevision CDATA #REQUIRED
Update CDATA #REQUIRED
>
<!
================================ RevisionStatus ====================
Indicates the status that previous revisions now has as a result of
the release of the current revision. The optional Revision attribute
is an integer, equal to the RevisionId of the revision in question.
If it is not present, then the status applies to ALL previous
revisions, without exception.
====================================================================
>
<!ELEMENT RevisionStatus (Status)>
<!ATTLIST RevisionStatus
%localid;
Revision CDATA #IMPLIED
>
<!
================================= RightsHolder =====================
A string of text indicating who has the usage rights, optionally
enriched with pointers to further information about the relevant
people, companies or organisations.
====================================================================
>
<!ELEMENT RightsHolder (#PCDATA | Origin)*>
<!ATTLIST RightsHolder
%localid;
%assignment;
>
<!
================================== RightsLine ======================
A displayable version of rights information. Note that this is
distinct from copyright information. Copyright information is about
who owns a news object; rights information is about who is allowed to
use it, in what way and under what circumstances.
====================================================================
>
<!ELEMENT RightsLine (#PCDATA | Origin)*>
<!ATTLIST RightsLine
%localid;
>
<!

================================ RightsMetadata ====================

Information about the rights pertaining to a NewsComponent.
====================================================================
>
<!ELEMENT RightsMetadata (Catalog?, Copyright*, UsageRights*,
Property*)>
<!ATTLIST RightsMetadata
%localid;
%assignment;
>
<!
===================================== Role =========================
An identifier of the role played by a NewsComponent within a
NewsComponent that contains it. The outermost NewsComponent within
a NewsItem need not specify a Role attribute value. The value of
the FormalName attribute is a formal name for the Role. Its meaning
====================================================================
>
<!ELEMENT Role EMPTY>
<!ATTLIST Role
%localid;
%formalname;
>
<!
=================================== SentFrom =======================
An individual and/or company or organisation from whom the NewsML
document is being sent.
====================================================================
>
<!ELEMENT SentFrom (%party;)>
<!ATTLIST SentFrom
%localid;
>
<!
==================================== SentTo ========================
An individual and/or company or organisation to whom the NewsML
document is being sent.
====================================================================
>
<!ELEMENT SentTo (%party;)>
<!ATTLIST SentTo
%localid;
>
<!
================================== SeriesLine ======================
A displayable version of information about a news object's place in
a series.
====================================================================
>
<!ELEMENT SeriesLine (#PCDATA | Origin)*>
<!ATTLIST SeriesLine
%localid;
>
<!

================================== SizeInBytes =====================

The exact size in bytes of a ContentItem's inline or referenced data
object.
====================================================================
>
<!ELEMENT SizeInBytes (#PCDATA)>
<!ATTLIST SizeInBytes
%localid;
>
<!
=================================== SlugLine =======================
A string of text, possibly embellished by hyperlinks and/or
formatting, used to display a NewsItem's slug line. (Note that the
meaning of the term "slug line", and the uses to which it is put,
are a matter for individual providers to define within their own
workflow and business practice.)
====================================================================
>
<!ELEMENT SlugLine (#PCDATA | Origin)*>
<!ATTLIST SlugLine
%localid;
>
<!
==================================== Source ========================
An individual and/or company or organisation that provided source
material for a news object. The optional NewsItem attribute must be
present in the case of a syndicated NewsItem. It provides the URN of
the NewsItem that is being syndicated. Note that a sequence of Source
elements can be used to indicate the sequence of syndicators through
which a NewsItem has passed.
====================================================================
>
<!ELEMENT Source (%party;)>
<!ATTLIST Source
%localid;
>
<!
================================== StartDate =======================
A naturallanguage statement of the date at which specified usage
rights come into effect.
====================================================================
>
<!ELEMENT StartDate (#PCDATA | Origin)*>
<!ATTLIST StartDate
%localid;
%assignment;
>
<!
==================================== Status ========================
An indication of the Status of a NewsItem. The value of the
FormalName attribute is a formal name for the Status. Its meaning
====================================================================

>
<!ELEMENT Status EMPTY>
<!ATTLIST Status
%localid;
%formalname;
>
<!
=============================== StatusWillChange ===================
Advance notification of a status change that will automatically occur
at the specified date and time. For example, an item with a Status
of "embargoed" might have a StatusWillChange element stating that
the status will become "usable" at a specified time. This is
equivalent to announcing in advance the time at which the embargo
will end and the item will be released.
====================================================================
>
<!ELEMENT StatusWillChange (FutureStatus, DateAndTime)>
<!ATTLIST StatusWillChange
%localid;
>
<!
================================= SubHeadLine ======================
A displayable subsidiary headline.
====================================================================
>
<!ELEMENT SubHeadLine (#PCDATA | Origin)*>
<!ATTLIST SubHeadLine
%localid;
>
<!
=================================== Subject ========================
An indication of the Subject of a NewsItem. The value of the
FormalName attribute is a formal name for the Subject. Its meaning
====================================================================
>
<!ELEMENT Subject EMPTY>
<!ATTLIST Subject
%localid;
%formalname;
%assignment;
>
<!
================================= SubjectCode ======================
A container for the IPTC Subject Codes that indicate the subject of
a NewsItem, as defined in the IPTC Information Interchange Model.
It consists of one more Subject, SubjectMatter and SubjectDetail
elements, optionally amplified by one or more SubjectQualifier
elements.
====================================================================
>
<!ELEMENT SubjectCode ((Subject | SubjectMatter | SubjectDetail),
SubjectQualifier*)*>
<!ATTLIST SubjectCode
%localid;

%assignment;
>
<!
================================ SubjectDetail =====================
An indication of the SubjectDetail of a NewsItem. The value of the
FormalName attribute is a formal name for the SubjectDetail. Its
declaration above.
====================================================================
>
<!ELEMENT SubjectDetail EMPTY>
<!ATTLIST SubjectDetail
%localid;
%formalname;
%assignment;
>
<!
================================ SubjectMatter =====================
An indication of the SubjectMatter of a NewsItem. The value of the
FormalName attribute is a formal name for the SubjectMatter. Its
declaration above.
====================================================================
>
<!ELEMENT SubjectMatter EMPTY>
<!ATTLIST SubjectMatter
%localid;
%formalname;
%assignment;
>
<!
=============================== SubjectQualifier ===================
An indication of the SubjectQualifier of a NewsItem. The value of the
FormalName attribute is a formal name for the SubjectQualifier. Its
meaning and permitted values are determined by a controlled vocabulary
as described in the comment to the formalname ENTITY declaration above.
====================================================================
>
<!ELEMENT SubjectQualifier EMPTY>
<!ATTLIST SubjectQualifier
%localid;
%formalname;
%assignment;
>
<!
=============================== SystemIdentifier ===================
A system identifier (in the sense defined by the XML 1,0
Specification) for a NewsItem.
====================================================================
>
<!ELEMENT SystemIdentifier (#PCDATA)>
<!ATTLIST SystemIdentifier
%localid;
>
<!

============================= ThisRevisionCreated ==================

The date and, optionally, time at which the current revision of a
NewsItem was created, expressed in ISO 8601 Basic Format, as
described in the comment to the DateAndTime attribute within the
assignment ENTITY declaration above.
====================================================================
>
<!ELEMENT ThisRevisionCreated (#PCDATA)>
<!ATTLIST ThisRevisionCreated
%localid;
>
<!
==================================== Topic =========================
This element provides information about a thing (Topic) named by a
formal name or occurring in a NewsComponent. A Topic must have one
or more TopicType subelements, which state what type of Topic it is.
The optional Details attribute provides a pointer, in the form of a
URL or URN, to additional information about the Topic.
====================================================================
>
<!ELEMENT Topic (Comment*, Catalog?, TopicType+, FormalName*,
Description*, Property*)>
<!ATTLIST Topic
%localid;
Details CDATA #IMPLIED
>
<!
=============================== TopicOccurrence ====================
An indication that a particular topic occurs within the content of a
NewsComponent. The optional HowPresent attribute indicates the nature
of that topic's occurrence. The value of the Topic attribute must
consist of a # character followed by the value of the Duid attribute
of a Topic in the current document.
====================================================================
>
<!ELEMENT TopicOccurrence EMPTY>
<!ATTLIST TopicOccurrence
%localid;
%assignment;
Topic CDATA #IMPLIED
>
<!
================================== TopicSet ========================
A container for Topics. The value of the FormalName attribute is a
formal name for the TopicSet. Its meaning and permitted values are
====================================================================
>
<!ELEMENT TopicSet (Comment*, Catalog?, TopicSetRef*, Topic*)>
<!ATTLIST TopicSet
%localid;
%formalname;
>
<!
================================= TopicSetRef ======================
A pointer to a TopicSet that is to be merged with the current one.

The TopicSet attribute is a pointer to the relevant TopicSet. Its

value can be an http URL, or a NewsML URN as described in the comment
to PublicIdentifier, or a fragment identifier consisting of a #
character followed by the Duid of a TopicSet in the current document.
The presence of a TopicSetRef child in a TopicSet has the effect
that all the Topics in the referenced TopicSet are included by
reference within the current TopicSet. When this merging results in
there exising two FormalName grandchildren of the same TopicSet that
have the same content and the same Scheme attribute value, then the
Topics whose children are in fact the same topic, and are deemed to
be merged. The merging of Topics need not be performed physically by
the system, but the meaning of the data is exactly the same as if the
merging were actually performed. Merging two Topcis consists of
creating a single Topic that contains all the children of both, and
eliminating duplicates.
====================================================================
>
<!ELEMENT TopicSetRef (Comment*)>
<!ATTLIST TopicSetRef
%localid;
TopicSet CDATA #IMPLIED
>
<!
================================== TopicType =======================
An indication of the type of a Topic. The value of the FormalName
attribute is a formal name for the TopicType. Its meaning and
====================================================================
>
<!ELEMENT TopicType EMPTY>
<!ATTLIST TopicType
%localid;
%formalname;
>
<!
================================== TopicUse ========================
An indication of where a particular Topic is used in a NewsML
document. The value of the Topic attribute must consist of a #
character followed by the value of the Duid of a Topic in the
current document. The value of the Context attribute is an XPath
pattern indicating the context where the referenced topic is used
within the subtree to which the current Catalog applies. If the
Context attribute is not present, the TopicUse element simply states
that this topic is present somewhere in the subtree.
====================================================================
>
<!ELEMENT TopicUse EMPTY>
<!ATTLIST TopicUse
Topic CDATA #REQUIRED
Context CDATA #IMPLIED
>
<!
================================ TransmissionId ====================
An identifier for the NewsML document transmission. This should be
unique among all distinct transmissions from the same publisher. If
a transmission is repeated (perhaps because the sender is not

confident that it was successfully received) then the same

TransmissionId content may be used, but a Repeat attribute should
be provided to distinguish the second transmission from the first.
The form that the value of the Repeat attribute takes is determined
by the provider. Likewise, the format for the TransmissionId itself
is for the provider to decide. It could for example consist of a
channel identifier followed by a sequence number.
====================================================================
>
<!ELEMENT TransmissionId (#PCDATA)>
<!ATTLIST TransmissionId
%localid;
Repeat CDATA #IMPLIED
>
<!
==================================== Update ========================
A modification to an existing NewsItem. This can be an insertion,
replacement or deletion. Note that the Update element cannot be used
to modify the NewsManagement or Identification element, or any of
their descendants. Modifications to these parts of the NewsItem can
be made by issuing the NewsItem under the current revision number,
with only the Identification and NewsManagement elements present.
These will replace the previous Identification and NewsManagement
elements in their totality.
====================================================================
>
<!ELEMENT Update (InsertBefore | InsertAfter | Replace | Delete)*>
<!ATTLIST Update
%localid;
>
<!
=================================== Urgency ========================
An indication of the urgency of a NewsItem. The value of the
FormalName attribute is a formal name for the Urgency. Its meaning
====================================================================
>
<!ELEMENT Urgency EMPTY>
<!ATTLIST Urgency
%localid;
%formalname;
>
<!
===================================== Url ==========================
A URL that can be used to locate a Resource.
====================================================================
>
<!ELEMENT Url (#PCDATA)>
<!ATTLIST Url
%localid;
>
<!
===================================== Urn ==========================
A URN that provides a global identifier for a resource. This will
typically (but not necessarily) be a NewsML URN as described in the
comment to PublicIdentifier.

=====================================================================
>
<!ELEMENT Urn (#PCDATA)>
<!ATTLIST Urn
%localid;
>
<!
================================= UsageRights ======================
Information about the usage rights pertaining to a NewsComponent.
====================================================================
>
<!ELEMENT UsageRights (UsageType?, Geography?, RightsHolder?,
Limitations?, StartDate?, EndDate?)>
<!ATTLIST UsageRights
%localid;
%assignment;
>
<!
================================== UsageType =======================
A naturallanguage indication of the type of usage to which the
rights apply.
====================================================================
>
<!ELEMENT UsageType (#PCDATA | Origin)*>
<!ATTLIST UsageType
%localid;
%assignment;
>
XML application configuration file for NewsML

This section contains the entire XML application configuration file that is used with the
NewsML example.
<! edited with XML Spy v4.3 U (http://www.xmlspy.com) by K Chalasani
(Documentum) >
<!DOCTYPE application SYSTEM "config.dtd">
<application>
<name>NewsML</name>
<app_pattern>
<element>NewsML</element>
</app_pattern>
<! MAP RULES FOLLOW HERE >
<map_rules>
<! CONTENT RULEs >
<! CONTENT Chunking Rule for the root news element:
NewsML FOLLOWS HERE >
<! used mainly to declare a few common variables used
in the rest of the config file...>
<! ******************************************* >
<xml_content_rule>

<element>NewsML</element>
<location>
<path>NewsInformation/</path>
</location>
<object_type>newsml_document</object_type>
<make_entity/>
</xml_content_rule>
<! ******************************************* >
<! CONTENT RULE for the primary news object: NewsItem FOLLOWS HERE >
<xml_content_rule>
<element>NewsItem</element>
<variables>
<variable>
<name>NewsItemId</name>
<element>NewsItemId</element>
<default>MiscNewsItems</default>
</variable>
<variable>
<name>PublicIdentifier</name>
<element>PublicIdentifier</element>
</variable>
<variable>
<name>DateId</name>
<element>DateId</element>
</variable>
<variable>
<name>ProviderId</name>
<element>ProviderId</element>
</variable>
<variable>
<name>Urgency</name>
<element>Urgency</element>
<attr_name>FormalName</attr_name>
<default>Unspecified Urgency</default>

</variable>
<variable>
<name>Status</name>
<element>Status</element>
<default>Unspecified Status</default>
</variable>
<variable>
<name>NewsItemType</name>
<element>NewsItemType</element>
<default>Unspecified Type</default>
</variable>
<variable>
<name>Duid</name>
<element>NewsComponent</element>
<attr_name>Duid</attr_name>
<default>UnknownDUID</default>
</variable>
</variables>
<location>
<! user should customize this path >
<path>NewsItems/</path>
</location>
<object_name>
<var name="NewsItemId"/>
</object_name>
<object_type>newsml_item</object_type>
<! ############### SOME ATTRIBUTES ON THE newsml_item
Object ################# >
<metadata>
<dctmattr>
<name>publicidentifier</name>
<template><var name="PublicIdentifier"/></template>
</dctmattr>
<dctmattr>
<name>urgency</name>
<template><var name="Urgency"/></template>
</dctmattr>
<dctmattr>
<name>status</name>
<template><var name="Status"/></template>
</dctmattr>
<dctmattr>
<name>newsitem_type</name>

<template><var name="NewsItemType"/></template>
</dctmattr>
<dctmattr>
<name>provider_id</name>
<template><var name="ProviderId"/></template>
</dctmattr>
<dctmattr>
<name>date_id</name>
<template><var name="DateId"/></template>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<! ************************************************************** >
<! CONTENT RULE to chunk NewsComponents FOLLOWS HERE >
<! ************************************************************** >
<xml_content_rule>
<variables>
<variable>
<name>Duid</name>
<this_element/>
<default>Untitled NewsComponent</default>
</variable>
<variable>
<name>Confidence</name>
<element>DescriptiveMetadata</element>
<attr_name>Confidence</attr_name>
</variable>
<variable>
<name>Genre</name>
<element>Genre</element>
<default>MiscellaneousGenre</default>
</variable>
<variable>
<name>ByLine</name>
<element>ByLine</element>
<default>Unknown ByLine</default>
</variable>

<variable>
<name>HeadLine</name>
<element>HeadLine</element>
</variable>
<variable>
<name>SubHeadLine</name>
<element>SubHeadLine</element>
</variable>
<variable>
<name>DateLine</name>
<element>DateLine</element>
<default>Date Line Not Given</default>
</variable>
<variable>
<name>CreditLine</name>
<element>CreditLine</element>
<default>Credits Unknown</default>
</variable>
<variable>
<name>SlugLine</name>
<element>SlugLine</element>
<default>Slugger</default>
</variable>
<variable>
<name>Role</name>
<element>Role</element>
<default>No Role Specified</default>
</variable>
<variable>
<name>BasisForChoice</name>

<element>BasisForChoice</element>
<default>Basis Not Specified</default>
</variable>
<variable>
<name>Provider</name>
<element>Provider</element>
<default>Provider Not Specified</default>
</variable>
<variable>
<name>Creator</name>
<element>Party</element>
<default>Creator Not Specified</default>
</variable>
<variable>
<name>Language</name>
<element>Language</element>
<default>Language Unspecified</default>
</variable>
<variable>
<name>Topic</name>
<element>TopicOccurrence</element>
<attr_name>Topic</attr_name>
<default>Topic Unspecified</default>
</variable>
<variable>
<name>OfInterestTo</name>
<element>OfInterestTo</element>
</variable>
<variable>
<name>Source</name>

<element>Source</element>
</variable>
<variable>
<name>EquivList</name>
<! yes/no value only >
<attr_name>EquivList</attr_name>
</variable>
</variables>
<location>
<! user should customize this path >
<path>../NewsComponents/</path>
</location>
<object_name>
<var name="Duid"/>
</object_name>
<object_type>newsml_component</object_type>
<! NewsComponent element, newsml_component objecttype,
METADATA settings ******** >
<metadata>
<dctmattr>
<name>byline</name>
<template><var name="ByLine"/></template>
</dctmattr>
<dctmattr>
<name>creditline</name>
<template><var name="CreditLine"/></template>
</dctmattr>
<dctmattr>
<name>dateline</name>
<template><var name="DateLine"/></template>
</dctmattr>
<dctmattr>
<name>headline</name>
<template><var name="HeadLine"/></template>
</dctmattr>
<dctmattr>
<name>subheadline</name>
<template><var name="SubHeadLine"/></template>
</dctmattr>
<dctmattr>
<name>slugline</name>
<template><var name="SlugLine"/></template>
</dctmattr>
<dctmattr>
<name>role</name>
<template><var name="Role"/></template>
</dctmattr>
<dctmattr>
<name>basis_for_choice</name>

<template><var name="BasisForChoice"/></template>
</dctmattr>
<dctmattr>
<name>provider</name>
<template><var name="Provider"/></template>
</dctmattr>
<dctmattr>
<name>creator</name>
<template><var name="Creator"/></template>
</dctmattr>
<dctmattr>
<name>genre</name>
<template><var name="Genre"/></template>
</dctmattr>
<dctmattr>
<name>equivalents_list</name>
<template><var name="EquivList"/></template>
</dctmattr>
<! some attributes repeating/multivalued >
<name>topics</name>
<template><var name="Topic"/></template>
<name>languages</name>
<template><var name="Language"/></template>
<name>source</name>
<template><var name="Source"/></template>
<name>of_interest_to</name>
<template><var name="OfInterestTo"/></template>
</metadata>
<make_entity/>
</xml_content_rule>
<! CONTENT RULE for ContentItem FOLLOWS HERE >
<! we could use Comment or Duid to put a name on the contentItem
for identification. >
<xml_content_rule>
<element>ContentItem</element>
<variables>
<variable>
<name>MediaType</name>
<element>MediaType</element>
</variable>
<variable>
<name>Comment</name>

<element>Comment</element>
</variable>
<variable>
<name>Duid</name>
<this_element/>
<default>Untitled ContentItem</default>
</variable>
</variables>
<location>
<path>../ContentItems/</path>
</location>
<object_name><var name="Duid"/></object_name>
<object_type>newsml_content</object_type>
<! METADATA for newsml_content object >
<metadata>
<dctmattr>
<name>mediatype</name>
<template><var name="MediaType"/></template>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<! *************************************************** >
<! A LINK RULE NOW for referenced items.... >
<! *************************************************** >
<link_rule peer_or_child="child" ndata="false">
<element>ContentItem</element>
<link_target>
<attr_name>Href</attr_name>
</link_target>
<location>
<path>../ContentItems/References/</path>
</location>
<object_type>newsml_content</object_type>
</link_rule>
</map_rules>
</application>
XML document to produce NewsML newsletter

This section contains the XML file that is used to generate the static portions of the
newsletter. The content of this file would be changed with each newsletter issue to
provide the framework for the content chunks that will be dynamically inserted into the

<Topics> element. See the next section for the XSL stylesheet that accompanies this
example.
<! edited with XML Spy v4.3 U (http://www.xmlspy.com) by
K Chalasani (Documentum) >
<newsletter>
<title>
TerraNews Newsletter
</title>
<intro>
Welcome to the first Aggregated Newsletter from
TerraNews, gathering all the important news of the
past several years in one place from the various
Terra News Agencys across the world and beyond.
</intro>
<Topics>
<topictitle>
Today&apos;s Headlines
</topictitle>
</Topics>
</newsletter>
The NewsML XSLT stylesheet

<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:java="http://xml.apache.org/xslt/java"
xmlns:xalannodeset=
"xmlns:xalannodeset="http://xml.apache.org/xalan"
version="1.0">
<xsl:output method="html" indent="no"/>
<! the Documentum Session ID is passed in, save it in a
variable>
<xsl:param name="DMS_SESSION_ID" select="'default value'"/>
<xsl:template match="newsletter">
<html>
<head>
<! grab the value of the title element in input xml>
<title><xsl:valueof select="title"/></title>
</head>
<body>
<h1><xsl:valueof select="title"/></h1>
<! grab the intro >
<p><xsl:valueof select="intro"/></p>
<xsl:applytemplates select="Topics"/>
</body>
</html>
</xsl:template>
<xsl:template match="Topics">
<h2><xsl:valueof select="topictitle"/></h2>
<! Build a query to get all Main News Components >

<xsl:variable name="myQuery">select * from newsml_component

where role='Main' </xsl:variable>
<xsl:variable name="myResult">
<xsl:withparam name = "dql" select=
"string($myQuery)"/>
</xsl:calltemplate>
</xsl:variable>
<! Build the links >
nodeset($myResult)//object">
<h3>
<a href="#{./content/NewsComponent/@Duid}">
<xsl:valueof select="headline"/>
</a>
</h3>
</xsl:foreach>
<! Now include Article Content >

nodeset($myResult)//object/content/NewsComponent">
<p>
<a name="{@Duid}"/>
<xsl:applytemplates select=".//Description|.//
Genre|.//HeadLine|.//SubHeadLine|.//ContentItem|
.//ByLine|.//CreditLine|.//DateLine|.//
NewsLineText"/>
</p>
</xsl:foreach>
</xsl:template>
<xsl:template match="HeadLine">
<p><b><font size="5"><xsl:valueof select="HeadLine"/>
<xsl:applytemplates/>
</font></b></p>
</xsl:template>
<xsl:template match="SubHeadLine">
<p><b><font size="3">
<xsl:valueof select="SubHeadLine"/>
</font></b></p>
</xsl:template>
<xsl:template match="CreditLine">
<font color="gray">
<font size="2">,
<xsl:valueof select="CreditLine"/>
</font>
</font>
</xsl:template>
<xsl:template match="DateLine">
<font color="gray" size="2">, <br></br>

<xsl:valueof select="DateLine"/>
</font>
</xsl:template>
<xsl:template match="NewsLineText">
<font color="Blue" size="2"><br></br>
<xsl:valueof select="NewsLineText"/>
</font>
</xsl:template>
<xsl:template match="ByLine">
<font color="gray" size="2">
By
<xsl:valueof select="ByLine"/>
</font>
</xsl:template>
<xsl:template match="ContentItem">
<p>
</p>
</xsl:template>
<xsl:template match="Comment | Genre">

<sup/>
</xsl:template>
<xsl:template name="XDQL">
<xsl:param name="dql"/>
<xsl:variable name="xdql" select=
"java:com.documentum.xml.xdql.DfXmlQuery.new()"/>
<xsl:variable name="init" select="java:init($xdql)"/>
<xsl:variable name="param" select=
"java:setDql($xdql, $dql)"/>
<xsl:variable name="includeContent" select=
"java:includeContent($xdql,true())"/>
<xsl:variable name="setContentEncoding" select=
"java:setContentEncoding($xdql,'dom')"/>
<xsl:variable name="setContentFormat" select=
"java:setContentFormat($xdql,'xml')"/>
<xsl:variable name="rootNode" select=
"java:setRootNode($xdql, 'xdql')"/>
<xsl:copyof select="$myResult"/>
</xsl:template>

</xsl:stylesheet>


Appendix F
Source for Cell Phone Catalog Sample
This appendix contains source materials relevant to the cell phone example
Cell phone catalog XML application

configuration file
<?xml version ="1.0"?>
<!DOCTYPE application SYSTEM "config.dtd">
<application>
<!This is the name of the XML Application in Documentum>
<name>CellularPhone</name>
<! Root Element of Content File >
<app_pattern><element>cellphonecatalog</element></app_pattern>
<validation/>
<map_rules>
<! Locating first element and setting it as a new object in Documentum >
<xml_content_rule>
<element>cellphonecatalog</element>
<make_entity/>
</xml_content_rule>
<! In this case we're also chunking out the models >
<xml_content_rule>
<! Extracting values from the XML content for use as variables >
<variables>
<variable>
<name>modelName</name>
<element>model.name</element>
<default>Model Unspecified</default>

</variable>
<variable>
<name>brandName</name>
<element>brand.name</element>
<default>Brand Unspecified</default>
</variable>
<variable>
<name>price</name>
<element>price</element>
</variable>
<variable>
<name>transferTechnology</name>
<element>technology</element>
<attr_name>transfer</attr_name>
<default>Transfer Technology Unspecified</default>
</variable>
<variable>
<name>protocol</name>
<element>technology</element>
<attr_name>protocol</attr_name>
<default>Protocol Unspecified</default>
</variable>
<variable>
<name>weight</name>
<element>weight</element>
<default>Weight Unspecified</default>
</variable>
<variable>
<name>batteryType</name>
<element>battery</element>
<attr_name>type</attr_name>
<default>Battery Type Unspecified</default>

</variable>
<variable>
<name>talkTime</name>
<element>talk.time</element>
<default>Talk Time Unspecified</default>
</variable>
<variable>
<name>standbyTime</name>
<element>standby.time</element>
<default>Standby Time Unspecified</default>
</variable>
</variables>
<! Defining where to store models in Documentum >
<location>
<path>Models/</path>
</location>
<! Setting object name on model object>

<object_name><var name="modelName"/></object_name>
<! Setting object type to a custom type>
<object_type>cell_phone_catalog_item</object_type>
<! How you would automatically apply model to Business Policy or

lifecycle>
<! <business_policy>
<policy_name>
/System/Applications/CellPhoneSampleApp/Cell_Phone_Lifecycle
</policy_name>
<policy_scope>CellPhoneSampleApp</policy_scope>
<policy_state>Review</policy_state>
</business_policy>
>
<! Populating Documentum attributes with Variables above>
<metadata>
<dctmattr>
<name>title</name>
<template>
<var name="brandName"/>(model <var
name="modelName"/>)$<var name="price"/>
</template>
</dctmattr>
<dctmattr>
<name>model_name</name>
<template><var name="modelName"/></template>
</dctmattr>
<dctmattr>
<name>brand_name</name>
<template><var name="brandName"/></template>
</dctmattr>

<dctmattr>
<name>price</name>
<template><var name="price"/></template>
</dctmattr>
<dctmattr>
<name>transfer_technology</name>
<template><var name="transferTechnology"/></template>
</dctmattr>
<dctmattr>
<name>protocol</name>
<template><var name="protocol"/></template>
</dctmattr>
<dctmattr>
<name>weight</name>
<template><var name="weight"/></template>
</dctmattr>
<dctmattr>
<name>talk_time</name>
<template><var name="talkTime"/></template>
</dctmattr>
<dctmattr>
<name>standby_time</name>
<template><var name="standbyTime"/></template>
</dctmattr>
<dctmattr>
<name>battery_type</name>
<template><var name="batteryType"/></template>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<! Also chunking at Description level >
<xml_content_rule>
<variables>
<variable>
<name>Desctitle</name>
<element>Title</element>
</variable>
</variables>
<location>
<path>Descriptions/</path>
</location>
<object_name><var name="Desctitle"/></object_name>
<object_type>dm_document</object_type>
<metadata>
<dctmattr>
<name>title</name>
<template><var name="Desctitle"/></template>
</dctmattr>

</metadata>
<make_entity/>
</xml_content_rule>
<! Locating linked files and importing as children part of VDM into
Documentum>
<link_rule peer_or_child="child" ndata="false">
<element>image</element>
<link_target>
<attr_name>href</attr_name>
</link_target>
<variables>
<variable>
<name>ImgName</name>
<element>image</element>
</variable>
</variables>
<location>
<path>Images/</path>
</location>
<object_type>dm_document</object_type>
<metadata>
<dctmattr>
<name>title</name>
<template><var name="ImgName"/></template>
</dctmattr>
</metadata></link_rule>
</map_rules>
</application>
Cell phone catalog sample document

<?xml version='1.0' encoding='UTF8'?>
<!DOCTYPE cellphonecatalog SYSTEM "CellPhoneCatalog.dtd">
<cellphonecatalog>
<model>
<model.name>Q3200</model.name>
<brand.name>Quasivox</brand.name>
<image href="Q3200.jpg"/>
<description>
<Title>WARRANTY OFFER</Title>
<Para>
A VIP Priority Service Agreement is available for this product
for only $59.95. Our toprated service enhancement program
includes:
</Para>
<ItemizedList>

<ListItem> Loaner program</ListItem>

<ListItem> Nationwide coverage</ListItem>
<ListItem> Tollfree telephone support (7 days a week)</ListItem>
<ListItem>Inhome service plans</ListItem>
</ItemizedList>
</description>
<specifications> <mode.type mode.type="Dual.Mode"/>
<technology transfer="Analog" protocol="AMPS"/>
<technology transfer="Digital.Cellular" protocol="CDMA" frequency="800"/>
<price currency="USD" with.contract="true">69.99</price>
<dimensions>
<height>0</height>
<width>2</width>
<thickness>0</thickness>
</dimensions>
<weight with.battery="true">8.5</weight>
<battery type="nickelmetalhydride">
<talk.time>200</talk.time>
<standby.time>49</standby.time>
</battery>
<display.features characters.per.line="36" text.lines="3">
<Backlight/>
<Battery.Strength.Indicator/>
<Roaming.Or.Channel.Indicator/>
<Signal.Strength.Indicator/>
<Voice.Mail.Or.Text.Indicator/>
</display.features>
<memory.features locations="99" alphanumeric="true">
<Last.Number.Recall number="20"/>
<Memory.Scrolling/>
<Secret.Memory/>
</memory.features>
<call.features>
<System.Select automatic="unknown"/>
<Call.Restriction/>
<Multiple.NAM number="4"/>
<One.Touch.Emergency.Dialing/>
<Speed.Dialing/>
<Caller.ID/>
<Ringer.Alert.Options number="4"/>
<Silent.Alert/>
<Keypad.Lock/>
<Call.Timer multiple="true"/>
<Scratchpad/>
<Mute/>
<Text.Paging/>
</call.features>
</specifications>
</model>
<model>
<model.name>QVX222</model.name>
<image href="QVX222.jpg"/>
<description>
<Title>INFORMATION OFFER</Title>
<Para>
Please note this Quasivox mobile phone is data capable on the

"analog network" only. Before purchasing any data accessories, it

is important to contact your specific service provider to verify
that they will allow you to access analog service where you want
to use your phone for data applications.
</Para>
<Para>
The two OrbaCom data accessories needed to achieve a connection
are:
</Para>
<ItemizedList>
<ListItem> The "QUA6" data cable</ListItem>
<ListItem>The "3CXM756" PCMCIA card</ListItem>
</ItemizedList>
<Para>
For more information or to order these accessories, please contact
OrbaCom at 18005553266 or please visit their website at
www.OrbaComparts.com. The PCMCIA card includes drivers for
Windows 95, 98, 2000, NT 4.0, Macintosh, Dos, and Linux.
</Para>
</description>
<specifications>
<mode.type mode.type="Single.Mode"/>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
</display.features>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Speed.Dialing/>
<Caller.ID/>
<Any.Key.Answer/>
<Keypad.Lock/>
<Automatic.Answer/>
<Silent.Alert/>
<Mute/>
</call.features>
</specifications>
</model>
<model>
<model.name>QVX427428</model.name>

<image href="QVX427428.jpg"/>
<description>
<Title>THIRD PARTY / BUNDLE OFFER</Title>
<Para>
Sign up for IT&amp;I Wireless Service and get up to $180 in Free
Stuff for a new IT&amp;I Activation.
</Para>
<ItemizedList>
<ListItem>Get $100 in free accessories</ListItem>
<ListItem>Receive a $30 gift check from us, and a</ListItem>
<ListItem>
$50 mailin rebate from IT&amp;I Nationwide coverage.
</ListItem>
</ItemizedList>
<Para> Offer good until July 31st.</Para>
</description>
<specifications>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
<Missed.Call.Indicator/>
</display.features>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Automatic.Redial/>
<Speed.Dialing/>
<Any.Key.Answer/> <Caller.ID/> <Silent.Alert/> <Keypad.Lock/>
<Continuous.DTMF.Dialing/> <Scratchpad/> <Mute/>
</call.features>
</specifications>
</model>
<model>
<model.name>QVX9XL</model.name>
<image href="QVX9XL.jpg"/>

<description>
<Title>ADDON SERVICE OFFER</Title>
<Para>
DocuMailbox is a revolutionary FREE messaging service that
integrates your email, voicemail, faxing and paging into a
single webbased Inbox. Now you can access your messages on any
webenabled computer, Web TV browser or touchtone phone from
any point in the world!
</Para>
<ItemizedList>
<ListItem>Your own email address</ListItem>
<ListItem>Tollfree number with extension</ListItem>
<ListItem>Receive voicemails and faxes</ListItem>
<ListItem>Listen to your email</ListItem>
</ItemizedList>
<Para>
Free offer good with QuasivoxQVX9XL cell phone purchase until
July 31, 2001. Order now!
</Para>
</description>
<specifications>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
</display.features>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Automatic.Redial/>
<Speed.Dialing/>
<Any.Key.Answer/>
<Caller.ID/>
<Silent.Alert/>
<Keypad.Lock/>
<Continuous.DTMF.Dialing/>

<Scratchpad/>
<Mute/>
<Speakerphone/>
</call.features>
</specifications>
</model>
<model>
<model.name>ET730</model.name>
<brand.name>Ersatz Technics</brand.name>
<image href="ET730.jpg"/>
<description>
<Title>WARRANTY OFFER 2</Title>
<Para>
A VIP Priority Service Agreement is available for this product
for only $59.95. Our toprated service enhancement program includes:
</Para>
<ItemizedList>
<ListItem> Loaner program</ListItem>
<ListItem> Nationwide coverage</ListItem>
<ListItem> Tollfree telephone support (7 days a week)</ListItem>
<ListItem>Inhome service plans</ListItem>
</ItemizedList>
</description>
<specifications>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
<weight with.battery="true">5</weight>
</battery>
</display.features>
<Memory.Scrolling/>
<Secret.Memory/>
</memory.features>
<call.features>
<Call.Restriction/>
<Electronic.Lock/>
<Automatic.Redial/>
<Speed.Dialing/>

<Silent.Alert/>
< feature name="Linked Dialing" note="2"/>
<Scratchpad/>
<Mute/>
<Text.Paging/>
</call.features>
</specifications>
</model>
<model>
<model.name>ET500</model.name>
<image href="ET500.jpg"/>
<description>
<Title>THIRD PARTY / BUNDLE OFFER 2</Title>
<Para>
</Para>
<ItemizedList>
<ListItem>
</ListItem>
</ItemizedList>
</description>
<specifications>
<technology transfer="Digital.PCS" protocol="GSM" frequency="1900"/>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
<feature name="Clock" note="Real Time"/>
<Volume.Indicator/>
</display.features>
<Secret.Memory/>
<Memory.Protect/>
<Memory.Scrolling/>

<SIM.Or.Smart.Card/>
</memory.features>
<call.features>
<Call.Restriction/>
<Automatic.Redial/>
<Speed.Dialing/>
<Caller.ID/>
<Keypad.Lock/>
<Any.Key.Answer/>
<Linked.Dialing/> <Mute/>
<Scratchpad/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/>
<Voice.Mail/>
<Party.Line number="6"/>
</call.features>
</specifications>
</model>
<model>
<model.name>ETGlobalPhone</model.name>
<image href="ETGlobalPhone.jpg"/>
<description>
<Title>ADDON SERVICE OFFER 2</Title>
<Para>
DocuMailbox is a revolutionary FREE messaging service that integrates
your email, voicemail, faxing and paging into a single webbased
Inbox. Now you can access your messages on any webenabled computer,
Web TV browser or touchtone phone from any point in the world!
</Para>
<ItemizedList>
</ItemizedList>
<Para>
Free offer good with Technics cell phone purchase until July 31,
2001. Order now!
</Para>
</description>
<specifications>
<technology transfer="Digital.Cellular" protocol="GSM" frequency="900"/>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>

<battery type="lithiumion">
</battery>
<Volume.Indicator/>
</display.features>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Speed.Dialing/>
<Caller.ID/>
<Mute/>
<Call.Forwarding/>
<Text.Paging/>
<Fax.Capability/>
<Infrared.Modem/>
</call.features>
</specifications>
</model>
<model>
<model.name>p650</model.name>
<brand.name>Pseudodyne</brand.name>
<image href="p650.jpg"/>
<description>
<Para>
your email, voicemail, faxing and paging into a single webbased Inbox.
Now you can access your messages on any webenabled computer, Web TV
browser or touchtone phone from any point in the world!
</Para>
<ItemizedList>
</ItemizedList>
<Para>
Free offer good with Pseudodyne cell phone purchase until July 31,
2001. Order now!
</Para>
</description>
<specifications>
<dimensions>
<height>0</height>
<width>0</width>

</dimensions>
<weight with.battery="true">6</weight>
</battery>
<Backlight/>
<Volume.Indicator/>
</display.features>
<SIM.Or.Smart.Card/>
</memory.features>
<call.features>
<Call.Restriction/>
<Automatic.Redial/>
<Caller.ID/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/> <Party.Line number="0"/>
</call.features>
</specifications>
</model>
<model>
<model.name>Starburst200</model.name>
<brand.name>Pseudodyne</brand.name> <image href="Starburst200.jpg"/>
<description>
<Para>
</Para>
<ItemizedList>
</ItemizedList>
<Para>
Free offer good with Pseudodyne cell phone purchase until July 31,
2001. Order now!
</Para>
</description>
<specifications>
<dimensions>

<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
<Volume.Indicator/>
</display.features>
<Memory.Protect/>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Call.Restriction/>
<Caller.ID/>
<Electronic.Lock/>
<Vibrating.Alert/>
<Automatic.Redial/>
<Linked.Dialing/>
<Speed.Dialing/>
<Any.Key.Answer/> <Automatic.Answer/>
<Mute/> <Scratchpad/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/>
<Voice.Mail/>
</call.features>
</specifications>
</model>
<model>
<model.name>Cybernation100</model.name>
<brand.name>Cybernation</brand.name>
<image href="Cybernation100.jpg"/>
<description>
<Title>THIRD PARTY / BUNDLE OFFER</Title>
<Para>
</Para>
<ItemizedList>


<ListItem>
</ListItem>
</ItemizedList>
</description>
<specifications>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
<Volume.Indicator/>
</display.features>
<Memory.Protect/>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Call.Restriction/>
<Caller.ID/>
<Electronic.Lock/>
<Vibrating.Alert/>
<Automatic.Redial/>
<Linked.Dialing/>
<Speed.Dialing/>
<Automatic.Answer/>
<Mute/>
<Speakerphone/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/>
</call.features>
</specifications>
</model>
<model>
<model.name>DSMultiRange</model.name>

<brand.name>Digiscreech</brand.name>
<image href="DSMultiRange.jpg"/>
<description>
<Para>
</Para>
<ItemizedList>
</ItemizedList>
<Para>
Free offer good with Digiscreech cell phone purchase until July 31,
2001. Order now!
</Para>
</description>
<specifications>
<technology transfer="Digital.PCS" protocol="CDMA" frequency="1900"/>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>
<Volume.Indicator/>
</display.features>
<Secret.Memory/>
<Memory.Protect/>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Call.Restriction/>
<Caller.ID/>
<Electronic.Lock/>

<System.Select automatic="true"/>
<Automatic.Redial/> <Continuous.DTMF.Dialing/>
<Linked.Dialing/>
<Speed.Dialing/>
<Any.Key.Answer/>
<Automatic.Answer/>
<Mute/>
<Scratchpad/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/>
<Voice.Mail/>
</call.features>
</specifications>
</model>
<model> <model.name>Poem15002000</model.name>
<brand.name>Tonepoem</brand.name>
<image href="Poem15002000.jpg"/>
<description>
<Title>THIRD PARTY / BUNDLE OFFER 5</Title>
<Para>
</Para>
<ItemizedList>
<ListItem>
</ListItem>
</ItemizedList>
</description>
<specifications>
<technology transfer="Digital.PCS" protocol="CDMA" frequency="1900"/>
<dimensions>
<height>0</height>
<width>0</width>
</dimensions>
</battery>
<Backlight/>

<Volume.Indicator/>
</display.features>
<Memory.Protect/>
<Memory.Scrolling/>
</memory.features>
<call.features>
<Call.Restriction/>
<Caller.ID/>
<Electronic.Lock/>
<Silent.Alert/> <Vibrating.Alert/>
<Automatic.Redial/>
<Speed.Dialing/>
<Any.Key.Answer/>
<Automatic.Answer/>
<Mute/>
<Scratchpad/>
<Speakerphone/>
<Voice.Activated.Dialing/>
<Call.Forwarding/>
<Call.Waiting/>
<Text.Paging/>
</call.features>
</specifications>
</model>
</cellphonecatalog>
Cell phone catalog DTD

The following DTD includes the Documentum namespace and attribute declarations.
<?xml encoding='UTF8' ?>
<!ELEMENT model.name (#PCDATA )>
<!ELEMENT brand.name (#PCDATA )>
<!ELEMENT image EMPTY>
<!ATTLIST image href CDATA #REQUIRED >
<!ELEMENT Any.Key.Answer EMPTY>
<!ELEMENT Automatic.Answer EMPTY>
<!ELEMENT Automatic.Redial EMPTY>
<!ELEMENT Backlight EMPTY>
<!ELEMENT Battery.Strength.Indicator EMPTY>
<!ELEMENT Call.Forwarding EMPTY>
<!ELEMENT Call.Restriction EMPTY>
<!ELEMENT Call.Timer EMPTY>
<!ATTLIST Call.Timer multiple CDATA #REQUIRED >
<!ELEMENT Call.Waiting EMPTY>
<!ELEMENT Caller.ID EMPTY>
<!ELEMENT Continuous.DTMF.Dialing EMPTY>

<!ELEMENT Electronic.Lock EMPTY>

<!ELEMENT Fax.Capability EMPTY>
<!ELEMENT Infrared.Modem EMPTY>
<!ELEMENT Keypad.Lock EMPTY>
<!ELEMENT Last.Number.Recall EMPTY>
<!ATTLIST Last.Number.Recall number CDATA #REQUIRED >
<!ELEMENT Linked.Dialing EMPTY>
<!ELEMENT Memory.Protect EMPTY>
<!ELEMENT Memory.Scrolling EMPTY>
<!ELEMENT Missed.Call.Indicator EMPTY>
<!ELEMENT Multiple.NAM EMPTY>
<!ATTLIST Multiple.NAM number CDATA #REQUIRED >
<!ELEMENT Mute EMPTY>
<!ELEMENT One.Touch.Emergency.Dialing EMPTY>
<!ELEMENT Party.Line EMPTY>
<!ATTLIST Party.Line number CDATA #REQUIRED >
<!ELEMENT Ringer.Alert.Options EMPTY>
<!ATTLIST Ringer.Alert.Options number CDATA #REQUIRED >
<!ELEMENT Roaming.Or.Channel.Indicator EMPTY>
<!ELEMENT SIM.Or.Smart.Card EMPTY>
<!ELEMENT Scratchpad EMPTY>
<!ELEMENT Secret.Memory EMPTY>
<!ELEMENT Signal.Strength.Indicator EMPTY>
<!ELEMENT Silent.Alert EMPTY>
<!ELEMENT Speakerphone EMPTY>
<!ELEMENT Speed.Dialing EMPTY>
<!ELEMENT System.Select EMPTY>
<!ATTLIST System.Select automatic (true | unknown ) #REQUIRED >
<!ELEMENT Text.Paging EMPTY>
<!ELEMENT Vibrating.Alert EMPTY>
<!ELEMENT Voice.Activated.Dialing EMPTY>
<!ELEMENT Voice.Mail EMPTY>
<!ELEMENT Voice.Mail.Or.Text.Indicator EMPTY>
<!ELEMENT Volume.Indicator EMPTY>
<!ELEMENT battery (talk.time , standby.time )>
<!ATTLIST battery type (lithiumion | nickelmetalhydride ) #REQUIRED >
<!ELEMENT call.features
(System.Select | Any.Key.Answer | Automatic.Answer | Automatic.Redial |
Caller.ID | Call.Forwarding | Call.Restriction | Call.Timer | Call.Waiting |
Continuous.DTMF.Dialing | Electronic.Lock | Fax.Capability | feature |
Infrared.Modem | Keypad.Lock | Linked.Dialing | Multiple.NAM | Mute |
One.Touch.Emergency.Dialing | Party.Line | Ringer.Alert.Options | Scratchpad |
Silent.Alert | Speakerphone | Speed.Dialing | Text.Paging | Vibrating.Alert |
Voice.Activated.Dialing | Voice.Mail )*>
<!ELEMENT cellphonecatalog (model+ )>
<!ATTLIST cellphonecatalog xmlns:dctm CDATA #IMPLIED
dctm:version_label CDATA #IMPLIED>
<!ELEMENT dimensions (height , width , thickness )>
<!ELEMENT display.features
(Backlight | Battery.Strength.Indicator | Roaming.Or.Channel.Indicator |
Signal.Strength.Indicator | Voice.Mail.Or.Text.Indicator |
Missed.Call.Indicator | feature | Volume.Indicator)*>
<!ATTLIST display.features
characters.per.line CDATA #REQUIRED
text.lines CDATA #REQUIRED >

<!ELEMENT feature EMPTY>

<!ATTLIST feature
name CDATA #REQUIRED
note CDATA #REQUIRED >
<!ELEMENT height (#PCDATA )>
<!ELEMENT memory.features
(Last.Number.Recall | Memory.Scrolling | Secret.Memory | Memory.Protect |
SIM.Or.Smart.Card)*>
<!ATTLIST memory.features
locations CDATA #REQUIRED
alphanumeric CDATA #REQUIRED >
<!ELEMENT model (model.name? , brand.name? , image? , description? ,
specifications )>
<!ATTLIST model
xmlns:dctm CDATA #IMPLIED
<!ENTITY % lists "ItemizedList">
<!ENTITY % ParaLevel "%lists; | Para ">
<!ENTITY % PhraseLevel "Emphasis | Strong |
Underscore | Link ">
<!ELEMENT ItemizedList (ListItem+ )>
<!ATTLIST ItemizedList Style (Simple | Bullet | Dash ) 'Bullet' >
<!ELEMENT ListItem (#PCDATA | %PhraseLevel; )*>
<!ELEMENT Para (#PCDATA | %PhraseLevel; )*>
<!ELEMENT Emphasis (#PCDATA | %PhraseLevel; )*>
<!ELEMENT Strong (#PCDATA | %PhraseLevel; )*>
<!ELEMENT Underscore (#PCDATA | %PhraseLevel; )*>
<!ELEMENT Link (#PCDATA )>
<!ELEMENT description (Title? , (%ParaLevel; )* )>
<!ATTLIST description xmlns:dctm CDATA #IMPLIED
<!ELEMENT Title (#PCDATA | %PhraseLevel; )*>
<!ELEMENT specifications
(mode.type , technology+ , price , dimensions , weight , battery ,
display.features , memory.features , call.features )>
<!ATTLIST specifications
dctm_status CDATA #IMPLIED
dctm_obj_id CDATA #IMPLIED >
<!ELEMENT mode.type EMPTY>
<!ATTLIST mode.type mode.type (Dual.Mode | Single.Mode | Tri.Mode )
#REQUIRED >
<!ELEMENT price (#PCDATA )>
<!ATTLIST price
currency CDATA #REQUIRED
with.contract CDATA #REQUIRED >
<!ELEMENT standby.time (#PCDATA )>
<!ELEMENT talk.time (#PCDATA )>
<!ELEMENT technology EMPTY>
<!ATTLIST technology
transfer (Analog | Digital.Cellular | Digital.PCS ) #IMPLIED
protocol (AMPS | CDMA | GSM | TDMA ) #REQUIRED
frequency (1900 | 800 | 900 ) #IMPLIED
transfer CDATA #IMPLIED >

<!ELEMENT thickness (#PCDATA )>

<!ELEMENT weight (#PCDATA )>
<!ATTLIST weight with.battery CDATA #REQUIRED >
<!ELEMENT width (#PCDATA )>

Appendix G
Sample Configuration File for a
DocBook DTD
This appendix describes a sample configuration file that specifies how to chunk technical manuals.
The sample configuration file contains the chunking rules for DocBook‑compliant technical manuals
that are authored in Arbortext Epic Editor, version 4.2.1.
This sample configuration file was created in Arbortext Epic 4.3 as an instance of the config.dtd
provided with DFC 4.3.x. The sample configuration file can be cut and pasted from this document,
where it can be used as is or as the basis to customize your own configuration file.
This appendix contains the following sections:
• Overview of sample configuration file, page 325
• Description of sample configuration file, page 327
• Sample configuration file, page 332
Overview of sample configuration file

The sample configuration file uses two different methods to chunk and store content
in a repository. The first method creates a single virtual document for each book and
stores the book virtual document in a product‑specific folder within the Documentation
Source\Book Files folder hierarchy (Figure 2, page 326). The second method creates an
individual content object (or virtual document) for each instance of a particular content
type and stores these objects in a product‑specific folder within the Documentation
Source\Reusable Content folder hierarchy for each content type (chapters. concepts,
examples, figures, graphics, procedures, tables, and topics).
Authors use the book virtual documents in the Book Files folder to access and work on
entire book files, along with all their contents. Authors use the content type folders in the
Reusable Content folder to access content objects for reuse in their own book files.

Sample Configuration File for a DocBook DTD
Figure 2. Folder hierarchy defined by sample configuration file
The sample configuration file specifies that each chunk created in the Reusable Content
folder be created as an instance of the custom chunk_type object type. In addition, the
sample configuration file defines attribute values that are written to each instance of the
custom chunk_type object type.
These attributes are:
• Element Type
• Operating System
• Product Name
• Product Version
• Target Audience
The chunk_type custom object type was specifically created to include these five custom
attributes. These five custom attributes enable authors to search for chunks based on any
combination of values on these attributes.
Table 18, page 326 lists each of the elements from an XML source file for which the
sample configuration file specifies a chunk. The decision to create chunks out of these
elements was based on the requirements of authors to reuse content at different levels
of granularity.
Table 18. Chunked XML source file elements
XML Source File Element Rules in Configuration File

<book> Creates a repository object for the
element and puts it in the Documentation
Source/Book Files/value of productname
element folder.

XML Source File Element Rules in Configuration File

<chapter> Creates repository object for the element
and puts it in the Documentation
Source/Reusable Content/Chapters/value
of productname element folder.
<sect1>, <sect2>, <sect3>, <sect4>, <sect5> Creates repository object for the element
without role attribute set to ʺconceptʺ and puts it in the Documentation
Source/Reusable Content/Topics/value of
productname element folder.
<sect1>, <sect2>, <sect3>, <sect4>, <sect5> Creates repository object for the element
without role attribute set to ʺconcept and puts it in the Documentation
Source/Reusable Content/Concepts/value
<figure> Creates repository object for the element
Source/Reusable Content/Figures/value of
productname element folder.
<graphic> Creates repository object for the
element and puts it in the graphic file
in Documentation Source/Reusable
Content/Graphics/value of productname
element folder.
<example> Creates repository object for the element
Source/Reusable Content/Examples/value
<procedure> Creates repository object for the element
Source/Reusable Content/Concepts/value
Description of sample configuration file

The following sections break down the XML application configuration file into
components and describe how the configurations have been set for this sample.

Defining the XML application and application pattern

The first part of the configuration file names the XML application (XML‑MBO) and
specifies all the elements that can appear as the root element of any XML document to
which this application will apply. In this case, there is only one possible root element:
the <book> element.
<application>
<name>XMLMBO</name>
<app_pattern>
</app_pattern>
Setting rules
The sample configuration file uses a content rule (<xml_content_rule>) or link rule
(<link_rule>) for each element in XML documents for which a chunk is to be created.
The content rule is used for elements in the XML document while the link rule is used
for external entities (graphic elements).
Defining the chunk level

The content rule and link rule use <element_selection_pattern> to specify the level at
which XML source documents are to be chunked. The first element selection pattern in
the rule determines the element to which all other specifications in the content or link
rule apply. In the following example, the content rule applies to <book> elements.
<xml_content_rule>
In the next example, the content rule uses an element selection pattern based on an
element and a specific attribute value for that element. The <attribute_test> element
defines the attribute name and value conditions that need to be met for the element
selection pattern.
<element>sect1</element>
<attribute_test>
<value>concept</value>
</attribute_test>

Note: In the sample configuration file, sections (sect1, sect2, sect3, etc...) with a role
attribute set to ʺconceptʺ are saved to different locations than sections without that role
attribute set.
Defining variables
The sample configuration file uses several variables in the content and link rules to
determine the names of chunks, the location of chunks, and attribute values for chunks.
All of the content rules (except for the <book> content rule) and the link rule use the
Element Name variable to store the name of the element specified in the element
selection pattern. This name will be used to populate the Element Type attribute for each
created chunk. If the name of the element cannot be derived, then the ʺUndeducedʺ
value for the Element Name is used.
<variable>
<name>Element Name</name>
<this_element/>
<default>Undeduced</default>
</variable>
All of the content rules use the Element Title variable to store the content of the <title>
element that is associated with the element, specified in the element selection pattern, in
the XML source. The Element Title variable determines the name of each chunk created
in the repository. The name of graphic chunks created through a link rule are derived
differently (Chunking external graphics files, page 331).
<variable>
<name>Element Title</name>
</variable>
The content rule for the <book> element defines four other book‑level variables. These
variables are Operating System, Product Version, Product Name, and Target Audience.
The values of these variables are derived from the <releaseinfo>, <productnumber>,
<productname>, and <othername> elements in the XML source document, respectively.
The values for these four variable are derived the same way as the Element Title variable
and are used to populate attribute values for all chunks created from the same XML
book. The value of the Product Name attribute is also used to specify the location in the
repository to store created chunks.

Specifying the location and object name

Each content rule or link rule in the sample configuration file contains a <location>
element that specifies where chunks should be created. The sample configuration file
uses a full path in the location, which varies for each content or link rule, postpended
with the value of the Product Name variable, which is the same for all chunks belonging
to the same book. Folder paths specified in the <location> element will be created if
they do not already exist.
<location>
<path>/Documentation Source/Reusable Content/Chapters/
<var name="Product Name"/></path>
</location>
Specifying the object name

The <object name> element specifies the name of the object to be created. This name
consists of the value of the Element Title variable, which is defined in each content rule
(Defining variables, page 329).
<object_name><var name="Element Title"/></object_name>
Specifying the type and attribute values

All content rules (except for the <book> element content rule) and the link rule use
the <object_type> element to specify that created chunks should be instances of the
chunk_type object type. Since the <book> element content rule does not specify a
particular object type, the default dm_document object type is used.
All content rules (except for the <book> element content rule) and the link rule use
the <metadata> element to specify the attribute values that need to be written to each
created chunk. The value of the Element Name variable is specific to the element in the
current content rule while the value of the Operating System, Product Name, Product
Version, and Target Audience are constant for all chunks in the same book (Defining
variables, page 329). The values of these variables get written to the <element_type>,
<operating_system>, <product_name>, <product version>, and <target_audience>
attributes of the created objects, respectively (see Overview of sample configuration
file, page 325).
<object_type>chunk_type</object_type>
<metadata>
<dctmattr>
<name>element_type</name>

<template><var name="Element Name"/></template>

</dctmattr>
<name>operating_system</name>
<template><var name="Operating System"/></template>
<name>product_name</name>
<template><var name="Product Name"/></template>
<name>product_version</name>
<template><var name="Product Version"/></template>
<name>target_audience</name>
<template><var name="Target Audience"/></template>
</metadata>
Creating the chunk

The <make_entity> element is the last element in all of the content rules. This element
instructs the XML application to create the chunk according to the specification in the
content rule.
<make_entity/>
The link rule does not require the <make_entity> element because objects referred to by
the link rule (graphic files) are already chunked on the local file system.
Chunking external graphics files

In the sample configuration file, the link rule is used for external graphic files that are
referenced in the XML source. The link rule uses the <link_target> element to specify
that the link is obtained from the fileref attribute of the element specified in the element
selection pattern of the link rule. In the link rule, the chunk name becomes the name
of the external file entity.
<link_target>
<attr_name>fileref</attr_name>
</link_target>

Sample configuration file

The following contains the entire program listing for the sample configuration file. You
should be able to cut and paste this file into your XML editor and use it as is or as the
basis for developing your own custom configuration file.
Note: It is highly recommended that you author your configuration file in an authoring
tool that validates your configuration file, real time, against the config.dtd.
<?xml version="1.0" encoding="utf8"?>
<!ArborText, Inc., 19882001, v.4002>
<!DOCTYPE application SYSTEM "c:\epicuser\XML Configuration\XML Configuration.dtd">
<application>
<name>XMLMBO</name>
<app_pattern>
</app_pattern>
<map_rules>
<xml_content_rule>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
<variable>
<name>Operating System</name>
<element>releaseinfo</element>
<default>Operating System Unspecified</default>
</variable>
<variable>
<name>Product Version</name>
<element>productnumber</element>

<default>Product Version Unspecified</default>

</variable>
<variable>
<name>Product Name</name>
<element>productname</element>
<default>Product Name Unspecified</default>
</variable>
<variable>
<name>Target Audience</name>
<element>othername</element>
<default>Target Audience Unspecified</default>
</variable>
</variables>
<location>
<path>/Documentation Source/Book Files/
</location>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<element>chapter</element>
<variables>
<variable>
</variable>
<variable>
<this_element/>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Chapters/
</location>
<metadata>

<dctmattr>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Concepts/
</location>
<metadata>
<dctmattr>

</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Topics/
</location>
<metadata>
<dctmattr>
</dctmattr>
<dctmattr>


</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>

</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>

</metadata>
<make_entity/></xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>


</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>

</metadata>
<make_entity/></xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>

</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>


</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>

</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<attribute_test>
</attribute_test>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
</location>
<metadata>
<dctmattr>
</dctmattr>

</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<element>figure</element>
<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Figures/
</location>
<metadata>
<dctmattr>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>

<variables>
<variable>
<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Procedures/
</location>
<metadata>
<dctmattr>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<element>table</element>
<variables>
<variable>

<this_element/>
</variable>
<variable>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Tables/
</location>
<metadata>
<dctmattr>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<xml_content_rule>
<element>example</element>
<variables>
<variable>
<this_element/></tagname_of_element>
</variable>
<variable>

</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Examples/
</location>
<metadata>
<dctmattr>
</dctmattr>
</metadata>
<make_entity/>
</xml_content_rule>
<link_rule>
<link_target>
</link_target>
<variables>
<variable>
<this_element/></tagname_of_element>
</variable>
<variable>
<name>graphic_file</name>
<this_element/>

<default>no derived name</default>
</variable>
</variables>
<location>
<path>/Documentation Source/Reusable Content/Graphics/
</location>
<object_name><var name="graphic_file"/></object_name>
<metadata>
<dctmattr>
</dctmattr>
</metadata>
</link_rule>
</map_rules>
</application>

Index
A empty content, 24
ACLs, 22, 37, 47, 58, 61, 99, 101, 132, 142, granularity, 21
227 of external parsed entities, 57, 142
aliases, 61, 99, 101, 182, 185, 189 chunking rules, 56
application support documents and Documentum attributes, 37
downloading, 15 example, 238, 243, 251
prohibiting download, 25 chunks
Application Support Documents importing and checking in, 16
folder, 20, 34 read‑only, 16
creating, 43 config.dtd
minimizing files, 25 elements in, 93
approving content, 27 version, 93
Arbortext Epic, 16, 18, 37, 325 config.dtd elements
archiving content, 28 acl_domain, 99, 101
attribute values acl_name, 99, 101, 133
extracting from XML documents, 111, allow_work_in_progress, 103, 106,
205, 209 130
attributes app_pattern, 106 to 107, 136
Documentum, 15, 37, 39, 229 application, 105
attr_name, 113, 161
attribute_exist_test, 109
B attribute_test, 110, 139, 213
binding rules, 15 to 16, 58, 104, 157, 221 to attribute_value_of_element, 111, 139,
222, 225, 229, 231 204, 216
business process analysis, 27 business_policy, 115
bypassing well‑formedness and child_of, 117, 134, 139
validation, 55, 103, 106 content_of_element, 118, 139, 204,
bypassing XML applications, 49, 104 210, 216
content_of_this_element, 120, 161
context_rule, 121, 139
C date_format, 122
canceling checkout, 16 dctmattr, 124, 171, 206
character entities, 175 dctmattr_repeating, 126, 171
in metadata, 172 dds_validation, 103, 106, 129
checking in XML documents, 16 default, 131, 147, 216
troubleshooting, 47 default_acl, 102, 132
checking out XML documents, 15 descendant_of, 117, 134, 139
troubleshooting, 50 element, 108, 136, 138 to 139
checkout element_selection_pattern, 110, 117 to
canceling, 16 118, 134, 136, 138, 157 to 159, 170,
chunking 175, 201, 206, 209, 225

Index
encode_reserved_XML_chars, 106, version_label, 157, 221, 225

124, 143, 206 xml_content_rule, 125, 134, 139, 142,
entity_rule, 141, 157, 170, 225 158, 163, 167, 169, 179, 185, 217,
expression, 96, 99, 101, 145, 152, 163, 222, 224
177, 179, 182, 184, 189, 191, 203, configuration file
214 description, 93
external_variable, 147 Content Server, 14, 17
external_variables, 106, 149 Corel XMetal, 16
format_attr, 150, 175 CSS, 13
java_class, 151 custom object types, 21, 36, 171, 179, 185,
java_classes, 106, 154, 215 236, 238, 243, 326
link_rule, 139, 155, 159, 170, 177
link_target, 157, 159, 161
link_template, 158, 163, 175, 225
D
location, 165, 175, 179, 185, 225 data dictionary, 20, 23, 37, 55, 106, 129
make_entity, 158, 167, 225, 227 data model
map_rules, 106, 169 analysis, 29
metadata, 165, 171, 173, 207 categorization content, 30
name, 106, 124, 147, 206, 216 descriptiveness, 30
non_xml_content_rule, 139, 150, 163, hierarchy and reuse, 30
170, 174 rigor, 30
object_name, 177 scope, 29
object_type, 165, 179, 227 date/time formatting, 49
occurrence, 139, 181 dctm:link_obj_id, 37 to 38
owner_name, 182, 218, 225, 227 dctm:link_obj_status, 37 to 38
path, 159, 165, 184 dctm:link_version_label, 37 to 38, 221
permanent_link, 158, 187 dctm:obj_id, 37 to 38, 229
policy_name, 115, 188 dctm:obj_status, 37 to 38, 229
policy_scope, 115, 189 dctm:version_label, 37 to 38, 221, 229
policy_state, 115, 191 DFC, see Documentum Foundation
pub_id, 108, 193 Classes
schema, 108, 195 DfXmlQuery, 71
suppress_output_of_default_ example, 89
attributes, 106, 197 dm_docbase_config, 33
sys_id, 108, 194, 199 dm_xml_application, 13
tagname_of_element, 139, 201, 204, dm_xml_config, 13
216 DocApps
template, 124, 203 for XML applications, 51
this_element, 139, 204 Document attributes
two_way_dctmattr, 124 to 125, 145, ignored for root chunk, 229
171, 205, 214 document lifecycles, 20 to 24, 27 to 28, 31,
two_way_dctmattr_repeating, 145, 36, 51, 56, 58, 60, 80, 115, 142, 188, 236
171, 209 initial state, 191
validation, 106, 195, 211 scope, 189
value, 213 Document Object Model (DOM), 82, 90
var, 96, 99, 101, 146, 148, 163, 177, 179, Document Resource Locators (DRLs), 157,
182, 184 to 185, 189, 191, 203, 206, 185
214, 217 constructing, 61 to 62
variable, 206, 214, 216, 220 Document Resource Locators (DRLs),
variables, 125, 220, 225 examples, 63 to 64

Index
Documentum Application Builder, 14, 17, <external_variables>, 55

41, 51, 54 to 55, 107, 172 <format_attr>, 58
Documentum attributes, 15, 37, 39, 229, <java_classes>, 55, 60
321 <link_rule>, 37, 57, 60 to 61, 252
and exported documents, 15 <link_target>, 61
Documentum Content Server, see Content <location>, 58, 238, 243
Server <make_entity>, 58, 238
Documentum Developer Web site, 233 <map_rules>, 238
Documentum Foundation Classes, 13, 17, <metadata>, 49, 58
49, 71, 79 to 80, 84 to 85, 226, 325 <name>, 46, 55
Documentum namespace, 37 to 38, 229, <non_xml_content_rule>, 57
321 <object_name>, 58, 238
Documentum products, 17 <object_type>, 238
DQL queries, 67 <owner_name>, 58, 61
in virtual documents, 68 <path>, 61
to find links, 69 <permanent_link>, 58
to find paths, 69 <schema>, 45
DTD, 13, 93 <sys_id>, 44, 46
See also config.dtd <tagname_of_element>, 59 to 60
DTD management, 15 <validation>, 20, 48, 55
DTD patching, 15 <var>, 60
DTDs <variable>, 60
adding Documentum attributes, 37 <variables>, 59, 239
and external parameter entities, 41 <version_label>, 58
importing, 44 <xml_content_rule>, 37 to 38, 56, 58,
management, 20 60, 238 to 239
troubleshooting, 47 empty content, 24
entities
character, 175
E data model, 29
elements NDATA, 57, 155 to 156, 158
<acl_domain>, 58, 61 parameter, 41, 47, 94, 199
<acl_name>, 58, 61 parsed, 57, 141 to 142, 157, 170, 225
<allow_work_in_progress>, 55 unparsed, 156
<app_pattern>, 55, 237 entity rules, 57
<application>, 46, 55, 237 exporting XML documents, 15
<attr_name>, 59 troubleshooting, 50
<attribute_value_of_element>, 59 to external references
60 patching with repository paths, 26
<business_policy>, 58
<content_of_element>, 59 to 60
<dctmattr_repeating>, 245 F
<dds_validation>, 23, 55 features, new, 11
<default>, 59 FOSI, 13, 25, 34, 43
<default_acl>, 58 full‑text search, 69
<element>, 59 for XML documents, 70
<element_selection_pattern>, 38, 59,
238
<entity_rule>, 57
G
<expression>, 60 graphics files

Index
in Link Rules, 156 map_rule_content, 95

template‑format, 96
paths
I finding with DQL queries, 69
IDfXmlQuery, 71 full, 184
IDfXMLTransformOperation, 80, 82, 84 relative, 184
ignoring XML applications, 15 to 16 permissions, see ACLs
importing XML documents, 15 prolog, 49, 54
troubleshooting, 47 properties, see repository properties
public identifier, 43, 46, 49, 108, 193 to
L 194, 199
Public identifier, 35
legacy content, 31
publishing, 28
linked files
with XSLT stylesheets, 82
handling, 161
linking rules, 57
and Documentum attributes, 37 Q
example, 252 queries, 67
links
finding with DQL queries, 69
localization, 28 R
read‑only chunks, 16
renditions
M creating, 79
metadata repository analysis, 31
querying, 68 repository object types
MetadataEncoding creating, 36
XML Reserved Characters, 143 repository properties
and chunked elements, 24
N and XML content, 24
determining, 22
namespaceURI, 59, 113, 136, 139
requirements analysis
naming the application, 237
and localization, 28
NDATA, 252
and XML content, 27
NDATA entities, 57, 155 to 158
components, 26
new features, 11
content review and approval, 27
NewsML, 85, 235
for XML application, 19
of business process, 27
O of legacy content, 31
object types of repository, 31
creating, 36 review of content, 27
custom, 36, 171, 179, 185, 236, 238, root chunks
243, 326 and Documentum attributes, 229
determining, 21 root elements, 50
oldest_client_version property, 33 rules
general information, 59
P
parameter entities, 94, 199 S
external, 41, 47 schema management, 15
for Documentum attributes, 37 schema namespace, 50

Index
schema patching, 15 of XML documents, 20, 55, 106, 211

schemas, 15 with schemas, 44, 195
adding Documentum attributes, 39 variable scope, 217 to 218
importing, 44 variables
management, 20 in XML application configuration
troubleshooting, 47 file, 60
scope passing into stylesheet, 84
variable, 217 to 218 Virtual Document Manager, 226
search
full‑text, 69
zone, 70
W
session ID, 71, 82, 84, 86, 90, 148, 152, 215 W3C schemas, see schemas
storage Web Development Kit, 17
of XML documents, 21 Web Publisher, 17
stylesheets, 13 Webtop, 15, 17
supporting documents well‑formedness
for download, 43 bypassing, 55, 103, 106
importing, 45 work in progress, 16
See also Application Support workflows
Documents folder and XML content management, 24
non‑download, 43
system identifier, 20, 46, 49 to 51, 93, 108, X
193 to 194, 199 Xalan node, 82
Xalan node‑set function, 85
T Xalan transformation engine, 79 to 80, 85,
tag names 152
extracting from XML documents, 136, XDQL, 16, 24, 28, 67, 71, 79, 82, 85, 88,
201 206, 236
transformations, 24, 27 to 28, 30 to 31, in XSLT stylesheets, 82
79 to 80, 82, 86, 236 XDQL template function, 87, 89
troubleshooting Xerces parser, 15
export or checkout problems, 50 XML
import or checkin problems, 47 and Documentum products, 17
XML application detection, 49 XML application configuration file, 13, 34
XML applications, 46 alias support, 61
assigning object types, 21
attaching document lifecycles, 23, 36
U components, 237
unparsed entities, 156 creating, 53
data dictionary validation, 23
description, 93
V determining requirements, 19, 26
validation, 16 importing, 44
against data dictionary, 20, 23, 37, 55, naming, 237
106, 129 NewsML case study, 235
and parser, 48 setting repository properties, 22, 236
bypassing, 55, 103, 106 setting rules, 56
of legacy XML content, 31 troubleshooting, 46
of XML application configuration turning on validation, 48, 55
file, 34, 53 to 54, 93

Index
using variables, 60 transformations, 79

validating, 93 XML content management
XML application detection, 49 and repository constructs, 24
XML application folder, 13 best practices, 23
creating, 42 XML documents
setting properties and permissions, 42 checking in, 16
XML applications checking out, 15
architecture, 13 chunking, 21
bypassing, 49, 104 exporting, 15
checklist, 35 importing, 15
components, 33 storing in repository, 21
creating, 33 XML Sample Documents folder, 34
detecting applicability, 237 XPath expressions, 96, 145
distributing as DocApps, 51 XSLT stylesheets, 16, 25, 34, 43, 67, 79 to
ignoring, 15 80, 82, 85, 236, 298
preparing to create, 33
testing, 46 to 47
XML Configuration File Editor, 33 to 34,
Z
54 zone searching, 24, 67, 70
XML content

XML Application 6.5 Development Guide

Uploaded by

Copyright:

Available Formats

XML Application 6.5 Development Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XML Application 6.5 Development Guide

Uploaded by

Copyright:

Available Formats

EMC® Documentum®

Chapter 1 Introduction ........................................................................................... 11

Chapter 2 Determining Requirements for Creating an XML Application ................ 19

EMC Documentum XML Application Version 6.5 Development Guide 3

Chapter 3 Creating the XML Application ................................................................ 33

Chapter 4 The XML Application Conﬁguration File ................................................ 53

4 EMC Documentum XML Application Version 6.5 Development Guide

Alias support ..................................................................................... 61

Chapter 5 Queries .................................................................................................. 67

Chapter 6 Transformations .................................................................................... 79

Appendix A Reference Information and Examples for Conﬁg_6.5.dtd ...................... 93

Appendix B Documentum Attributes ...................................................................... 229

EMC Documentum XML Application Version 6.5 Development Guide 5

Chunking rule for <NewsML> ............................................................... 238

Appendix E Source Files for NewsML Sample ........................................................ 255

Appendix F Source for Cell Phone Catalog Sample ............................................... 303

Appendix G Sample Conﬁguration File for a DocBook DTD ................................... 325

6 EMC Documentum XML Application Version 6.5 Development Guide

Figure 1. XML application architecture .......................................................................... 14

EMC Documentum XML Application Version 6.5 Development Guide 7

Table 1. Checklist for creating an XML application ........................................................ 35

8 EMC Documentum XML Application Version 6.5 Development Guide

EMC Documentum XML Application Version 6.5 Development Guide 9

10 EMC Documentum XML Application Version 6.5 Development Guide

This chapter contains the following:

What’s new for XML applications for

EMC Documentum XML Application Version 6.5 Development Guide 11

• Constrained query use case – find a document or set of documents based on a

XML applications overview

12 EMC Documentum XML Application Version 6.5 Development Guide

How XML applications work

XML application architecture

EMC Documentum XML Application Version 6.5 Development Guide 13

Figure 1. XML application architecture

The XML application itself consists of the following:

14 EMC Documentum XML Application Version 6.5 Development Guide

Documentum clients have differing capabilities to perform operations associated with

XML application functionality

EMC Documentum XML Application Version 6.5 Development Guide 15

16 EMC Documentum XML Application Version 6.5 Development Guide

Documentum product support for XML

EMC Documentum XML Application Version 6.5 Development Guide 17

In addition, there are third‑party integrations with Documentum’s XML functionality,

18 EMC Documentum XML Application Version 6.5 Development Guide

A successful implementation of an XML application is dependent upon a full understanding of

Determining conﬁguration requirements for the

EMC Documentum XML Application Version 6.5 Development Guide 19

• What ACL to assign to each object created by the application

DTD and schema management

20 EMC Documentum XML Application Version 6.5 Development Guide

Determining document chunking

Determining storage location

Determining object types

EMC Documentum XML Application Version 6.5 Development Guide 21

Determining repository properties

22 EMC Documentum XML Application Version 6.5 Development Guide

Determining a document lifecycle

Validating against the data dictionary

Best practices in XML content management

EMC Documentum XML Application Version 6.5 Development Guide 23

Content archiving and endoflife