Managing XML Content in Documentum - Dell EMC · Managing XML Content in Documentum 1–1 1...

Managing XML Content in Documentum®

Version 4.2

May 2001

DOC3-XMLMGMT-0501

��

Copyright © 2001Documentum, Inc.6801 Koll Center ParkwayPleasanton, CA 94566All Rights Reserved.

Documentum®, Documentum 4i™, Docbase™, Documentum eContent Server™, Documentum Server®, Documentum Desktop Client™, Documentum Intranet Client™, Documentum WebPublisher™, Documentum ftpIntegrator™, Documentum RightSite®, Documentum Administrator™, Documentum Developer Studio™, Documentum Web Development Kit™, Documentum WebCache™, Documentum ContentCaster™, AutoRender Pro™, Documentum iTeam™, Documentum Reporting Gateway™, Documentum Content Personalization Services™, Documentum Site Delivery Services™, Documentum Content Authentication Services™, Documentum DocControl Manager™, Documentum Corrective Action Manager™, DocInput™, Documentum DocViewer™, Virtual Document Manager™, Docbasic®, Documentum DocPage Server®, Documentum WorkSpace®, Documentum SmartSpace®, and Documentum ViewSpace® are trademarks or registered trademarks of Documentum, Inc. in the United States and throughout the world. All other company and product names are used for identification purposes only and may be trademarks of their respective owners.

Managing XML Content in Documentum iii

Preface

1 IntroductionOverview of Documentum XML Support . . . . . . . . . . . . . . . . . . . . . . . . . 1-1XML Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

What Comprises an XML Application? . . . . . . . . . . . . . . . . . . . . . . . . 1-3The XML Application Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4The XML Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4The DTD or Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Supporting Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

How the Applicable XML Application is Determined. . . . . . . . . . . . . . . . 1-5What Information is Extracted . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

How is the XML Application Used? . . . . . . . . . . . . . . . . . . . . . . . . . 1-6The Default XML Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

eContent Server Architectural Support for XML. . . . . . . . . . . . . . . . . . . . . . 1-7The Object Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8The Containment Object Type Attributes . . . . . . . . . . . . . . . . . . . . . . . 1-8The xml_link Relationship Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Querying XML Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Zone Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9XDQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

2 Creating XML ApplicationsProcedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1The Preliminary Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Determining the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Determining What Chunks to Create as Objects . . . . . . . . . . . . . . . . 2-3Which Object Types to Assign the New Objects . . . . . . . . . . . . . . . . 2-4Which ACL to Assign to Each New Object . . . . . . . . . . . . . . . . . . . 2-4Using a Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Determining the Storage Location . . . . . . . . . . . . . . . . . . . . . . . . 2-5Determining What Metadata to Set . . . . . . . . . . . . . . . . . . . . . . . 2-5Validating Against a DTD or Schema . . . . . . . . . . . . . . . . . . . . . . 2-5Validating Against the Data Dictionary . . . . . . . . . . . . . . . . . . . . . 2-5

Creating the Underlying Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 2-6Writing the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Basic Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Defining the General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Writing Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

C O N T E N T S

iv Managing XML Content in Documentum

Writing the Map Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9XML Content Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10

The make_object Attribute . . . . . . . . . . . . . . . . . . . . . . . . .2-10Element Selection Pattern . . . . . . . . . . . . . . . . . . . . . . . . .2-11Declaring Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12Object Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12The make_entity Element. . . . . . . . . . . . . . . . . . . . . . . . . .2-14

Link Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14Non-XML Content Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16Entity Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16

Closing the Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16Writing the DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17Creating the Supporting Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18Storing the Supporting Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18

Storing the DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19Creating the Application Folders and Populating Them . . . . . . . . . . . . . . . . .2-19Troubleshooting Your XML Application. . . . . . . . . . . . . . . . . . . . . . . . . .2-22Distributing XML Applications as DocApps . . . . . . . . . . . . . . . . . . . . . . .2-22

3 Querying XML DocumentsOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Querying With DQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Fulltext Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Using a Zone File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Querying with XDQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

DfXMLQuery Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

4 TransformationWhat is Transformation?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1What is XSLT?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Transformation Support in the DFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Using Transformation to Dynamically Build Documents . . . . . . . . . . . . . . . . 4-4

A Installing XML FunctionalityRequired Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Managing XML Content in Documentum v

B Example DocumentsCellphone Catalog Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1Style Sheet for Dynamic Transformation Example . . . . . . . . . . . . . . . . . . . . B-2

Index

vi Managing XML Content in Documentum

Managing XML Content in Documentum vii

P R E F A C E

Purpose of the Manual

This manual describes how Documentum supports and manages XML documents.

Intended Audience

This document is addressed to application developers and system administrators who are implementing XML management processes using Documentum within their enterprise.

Organization of the Manual

The following table describes the contents of this manual:

Chapter Contents

Chapter 1, Introduction

Contains a brief overview of how Documentum supports XML documents.

Chapter 2, Creating XML Applications

Describes how to create Documentum XML Applications.

Chapter 3, Querying XML Documents

Discusses how to query XML documents and content.

Chapter 4, Transformation

Describes the transformation features available using Documentum and the Documentum Foundation Classes.

Appendix A, Installing XML Functionality

Describes how to install Documentum’s XML support in a 4.1 Documentum Server installation.

viii Creatng Documentum XML Applications

Conventions

This manual uses the following conventions:

Using Links in PDF Files

If you are reading this document as a Portable Display Format (PDF) file, cross-references and page numbers in the index are clickable blue hypertext links. Table of contents page numbers are also clickable links, but they appear in black.

➤ To follow a link:

1. Move the pointer over a linked area.

The pointer changes to a pointing finger when positioned over a link. The finger pointer displays a W when moved over a Weblink.

2. Click to follow the link.

Appendix B, Example Documents

Text of XML documents used in some examples in the chapters.

Chapter Contents

Convention Description

➤ Represents a pop-up or pull-down menu.

Indicates the introduction to a procedure.

italics Represents a variable name for which you must provide a value, or a defined term.

typewriter Represents code samples, user input, and computer output.

[] square brackets Indicates an optional argument.

{} braces (curly brackets)

Indicates an optional argument that can be repeated more than once.

Creating Documentum XML Applications ix

Note: To follow Web links, your Weblink preferences must specify a Web browser. See Setting Weblink preferences in your Adobe Acrobat Help for more information.

Special Considerations

This manual is provides the basic information needed to begin managing XML documents using Documentum. Future editions of the manual will add more information about creating specific behaviors using rules in the configuration file and about using the transformation features. For more information about those topics currently, refer to the Documentum’s developer.com site (Choose Developers from the menu on Documentum’s web site.)

Bug Lists and Documentation Online

Customers with a Software Support Agreement can read our product documentation and, after commercial release of a product, view lists of fixed bugs on Documentum’s Technical Support web pages. To access online support, first request access and obtain a user name and password.

Applying for Access

➤ To apply for access to online support:

1. In your Web browser, openhttp://www.documentum.com/

2. Click the Technical Support link.

3. Click the Request Access link.

4. Complete the form and send it.

Documentum will respond to your request within two business days.

http://www.documentum.com

x Creatng Documentum XML Applications

Fixed Bugs List

A list of customer-reported bugs that have been fixed will be available two weeks after this release, at the Technical Support area of the documentum.com Web site. For information about obtaining access to online support, refer to “Applying for Access.” The lists of fixed bugs are in PDF format.

➤ To view the list of fixed bugs:

1. In your web browser, openhttp://www.documentum.com/


3. Log on to the Technical Support site.

4. In the Troubleshooting section, click View Bugs.

5. Click Fixed Bugs and Feature Requests Lists.

6. Click the name of the bug list.

Product Documentation

Customers with a software support agreement can view PDF format product documentation at the documentum.com Web site. First request a user name and password (refer to “Applying for Access”).

➤ To view a document:

1. In your Web browser, open http://www.documentum.com/


3. Log on to the Technical Support site.

4. In the Resources section, click Documentation.

5. Click the name of the document.

http://www.documentum.com/support/index.htm

http://www.documentum.com/support/index.htm

Creating Documentum XML Applications xi

Purchasing Bound Paper Manuals

Our product documentation is available for purchase as bound paper manuals. To place an order, call the Documentation Order Line at (925) 600-6666. You can pay with a purchase order, check, or credit card.

xii Creatng Documentum XML Applications

Managing XML Content in Documentum 1–1

1Introduction 1

XML is rapidly becoming the standard language for e-business. Using XML content facilitates e-commerce transactions, Web publishing operations, and re-use of knowledge within the enterprise. This chapter provides a brief overview of how Documentum supports XML content. It includes the following topics:

■ “Overview of Documentum XML Support” on page 1-1

■ “XML Applications” on page 1-2

■ “eContent Server Architectural Support for XML” on page 1-7

■ “Querying XML Documents” on page 1-9

Overview of Documentum XML Support

Documentum provides full support for XML documents. The implementation allows you to chunk XML documents at any level of granularity and provides the full range of server services, such as versioning and security services, for each of the objects associated with the top-level document and the chunks. XML documents can also participate in workflows and lifecycles. In addition to the standard document services, XML documents are provided with validation and transformation services that are specific to XML content. Documentum also provides additional querying capabilities for XML content.

XML support is implemented through the DFC (Documentum Foundation Classes), in the operations package and the xml.xdql package. The Java classes in the operations package provide the basic library services, such as check in, checkout, import, export, and so forth, for XML documents. The Java classes in the xml.xdql package provide the extra querying functionality available for XML documents. (Note: XML functionality is not supported in the IDfSysobject class.)

IntroductionXML Applications

1–2 Managing XML Content in Documentum

The XML functionality is exposed and accessible through Documentum clients, such Documentum Desktop Client™ and WDK (Web Development Kit), that use the DFC. Additionally, Desktop Client integrations with SoftQuad and Arbortext provide users with seamless coordination between the editing environment and the Docbase.

XML documents in the Docbase are managed through Documentum XML Applications. A Documentum XML application contains the rules for validating an XML document and managing it during Docbase operations. You can also store style sheets and other supporting documents with an XML application. XML applications are user-defined, to reflect the needs and rules of your enterprise. (Documentum does provides one default XML application.) A Docbase can have multiple XML applications. For a full description of XML applications and their use, refer to “XML Applications” on page 1-2. Chapter 2, Creating XML Applications describes how to create an XML application.

For an overview of the added XML querying capabilities, refer to “Querying XML Documents” on page 1-9. Chapter 3, Querying XML Documents, describes the XML querying capabilities in detail.

“eContent Server Architectural Support for XML” on page 1-7 describes the changes to the object type hierarchy in Documentum that support XML content.

For more information about the DFC classes that implement XML content management, refer to the Javadocs. For general information about DFC, refer to Using DFC in Documentum Applications.

XML Applications

A Documentum XML application is a folder containing a set of documents that define the rules for processing an XML document in the Docbase. The XML features that make XML so versatile for managing knowledge—the ability to reference entities, to represent a document as chunks, to output the content in varying formats—also mean that varying XML documents will have different processing requirements in the Docbase. A Documentum XML application defines the processing rules for a particular kind of XML document.


Creating Documentum XML Applications 1–3

The rules that you put in the XML application’s configuration file determine how documents processed by the application are handled. For example, you may write rules that direct the system to chunk the document into smaller objects and save the document and the chunks into the Docbase. When this happens, the document is saved as a virtual document and the chunks are the components of the document.

You can also use an application to process documents that simply contain information that needs to be saved into the Docbase. In such cases, the rules can extract the information from the document, create Docbase objects such as folders as needed, set properties (metadata), and so forth. There may be no need to save the actual document in the Docbase.

The rules in the XML application associated with the document determine whether the document is saved into the Docbase, whether and how the document’s content is chunked, what objects are created, what properties are set, how links and entity references are handled, and so forth.

The XML application can also control how an XML document is formatted when you use the document to generate a Web page or a printed document or some other form of output.

“What Comprises an XML Application?, “ below, describes the documents that are included in an XML application.

“How the Applicable XML Application is Determined” on page 1-5 describes how the system determines which XML application to use with a particular XML document.

“How is the XML Application Used?” on page 1-6 describes in more detail how an XML application is used.

What Comprises an XML Application?

An XML application consists of a configuration file, an optional DTD or schema, and supporting documents, such as style sheets and FOSIs (Formatting Output Specification Instances) stored in an XML Application folder.

Note: Support for schemas is limited to the level of support provided by the Xerces XML parser provided with the Documentum DFC.



The XML Application Folder

An XML application folder contains and identifies through its properties the documents that define a particular XML application. XML application folders are a subtype of dm_folder. Properties defined for the application folders are used to determine which application is used to process a particular document.

XML application folders are stored in the Docbase in /System/Applications.

The XML Configuration File

Each XML application must have a configuration file. The file defines the rules that govern how the system processes documents handled by the application. For example, a configuration file controls:

■ Whether documents are validated on import or check in

■ Chunking rules for the document

■ How links are handled

■ Where the document and its components are stored in the Docbase.

For a more complete description of the rules you can place in a configuration file, refer to “Writing the Configuration File” on page 2-7.

A configuration file is itself an XML document. It must be well-formed and must conform to the config.dtd supplied by Documentum. Documentum also provides an online file, config.htm, that describes the valid elements in a configuration file.

The DTD or Schema

A DTD (document type definition) defines the structure of the XML documents that the XML application will handle. It defines the elements tags and how each is structurally related to the other tags with a document.

This is an optional document. However, we recommend providing a DTD for XML applications because it ensures that users cannot include unexpected element tags in the XML documents.



A DTD can be stored in the XML application folder (in a subfolder with the supporting documents) or it can be stored anywhere accessible to users working with the documents processed by the application. The DTD is associated with the XML application through an attribute set for the XML application folder.

For information about creating a DTD for a Documentum XML application, refer to “Writing the DTD” on page 2-17. Storage information is found in “Storing the Supporting Documents” on page 2-18.

If you plan to use a schema for validation, Documentum supports XSD support to the level provided by the Xerces XML parser provided with the Documentum DFC. If you use a schema, the URI that references the schema must reference a site accessible to users.

Supporting Documents

XML editors typically require a variety of supporting files, to provide the user interface and other customizations for various kinds of XML documents. These files (cascading style sheets, FOSIs, macro files, and so forth) can be stored in a folder called Application Support Documents that resides inside the XML application folder.

All documents stored in an Application Support Documents are downloaded to the client machine when a user works with a document processed by the application.

How the Applicable XML Application is Determined

When a user imports or checks an XML document in to a Docbase, the system examines the document’s prolog to determine which XML application is governing the document. The system uses the following algorithm to determine which XML application to use for a particular XML document:

1. If a Documentum (<?dctm...>) XML_APP processing instruction is found in the document, the application identified in the instruction is used.

2. If there is no XML_APP processing instruction, the system extracts some information from the document and compares that information to attribute values in the XML application folders in the Docbase to find a match.

■ If only a single XML application matches, that application is used.



■ If multiple applications match:

❒ The user is presented with a dialog box listing the choices, and the user can choose.

❒ If the user fails to make a choice or if the choice is being made programmatically and no choice is specified in the application, the first match returned by the query is used.

3. If there are no matches, the system uses the default XML application.

What Information is Extracted

The system extracts the following values from the document:

■ Root element

■ System identifier

■ Public identifier, if present

■ Namespace of the root element, if present

The root element, system identifier, and public identifier are found in the prolog of the document. For example, here is the prolog of a document processed by the cell phone catalog sample application:

<!DOCTYPE cellphone-catalog PUBLIC "/documentum//DTDCellPhoneInlineentity//EN" "CellPhoneInline Entity.dtd">

In this example, cellphone-catalog is the root element, "/documentum//DTD CellPhoneInlineentity//EN" is the public identifier, and "CellPhoneInline Entity.dtd" is the system identifier.

The name space of the root element is found in an attribute defined for the root element.

How is the XML Application Used?

After the system determines which XML application to apply to a document, it uses the configuration file in that application to process the document. It applies the rules in the file to create objects, set metadata (properties), validate the document, and so forth.

Documentum also uses the XML application to manage the XML documents during check out, check in, viewing, and exporting operations. For example, any properties set by rules are set each time a document is checked in.

IntroductioneContent Server Architectural Support for XML


When the document is processed to generate output, such as a web page or a printed document, any appropriate style sheets in the XML application can be applied.

The supporting documents stored in the application’s Application Support Documents folder are downloaded to the user’s local machine when a user works with a document handled by the application.

For check out and view operations, the system creates a subdirectory called XML Application in the user directory. Under that directory, a separate directory is created for each XML application and the documents are downloaded to that application-specific directory.

For export operations, the system creates a subdirectory for the supporting documents in the target export directory and downloads all supporting documents to that subdirectory.

The Default XML Application

The Default XML Application, provided by Documentum, is used to process any XML document in the Docbase that is not associated, either programmatically or explicitly by a user, with a user-defined XML application.

The default application has a configuration file that is stored in the Default XML Application folder and is also named Default XML Application. The configuration file contains only one rule, which tells Documentum how to recognize and process external parsed entities (entity references within the document). You can modify the configuration file for this default application, to add rules for general processing, for example.

eContent Server Architectural Support for XML

eContent Server supports XML content using a set of object types, attributes in the containment and assembly object types, and a relationship type called xml_link.

IntroductioneContent Server Architectural Support for XML


The Object Types

The object types that support XML applications are:

■ dm_xml_application

■ dm_xml_config

■ dm_xml_style_sheet

The dm_xml_application object type is a subtype of dm_folder. dm_xml_application objects are used to store all the documents that comprise an XML application.

The dm_xml_config object type is a subtype of dm_document. The content of an dm_xml_config object is an XML configuration file. dm_xml_config objects are stored in an xml application folder.

The dm_xml_style_sheet object type is a subtype of dm_document. The content of an dm_xml_style_sheet object is an XSL style sheet. dm_xml_style_sheet objects are stored in an xml application folder.

For a list of the attributes of these object types, refer to the eContent Server Object Reference Manual.

The Containment Object Type Attributes

When an XML document is brought into the Docbase and created as a virtual document, eContent Server creates component documents from any entity references in the XML document. To manage the connection between the virtual document and those components, the server uses two attributes: a_contain_type and a_contain_desc.

The a_contain_type attribute indicates whether the reference is a link or an entity. The a_contain_desc attribute contains the actual identification string for the child component.

For more information about these attributes and virtual documents, refer to the information about virtual documents in eContent Server Fundamentals.

The xml_link Relationship Type

The xml_link relationship is a system-defined relationship.

IntroductionQuerying XML Documents


You can include rules in the configuration file that direct the system to create xml_link relationships between the source document and any cross-referenced documents it contains. If you do, when an XML document processed by that configuration file is imported into the Docbase, the system also brings into the Docbase any cross-referenced documents and creates a relationship between them and the XML document of type xml_link.

For more information about relationships, refer to Chapter 1, Object Basics, of the eContent Server Object Reference Manual.

Querying XML Documents

In addition to the standard querying abilities available through DQL (querying attribute values and full-text searching), two additional capabilities are available for XML documents:

■ Zone searching

■ XDQL

Zone Searching

Zone searching lets you conduct a fulltext search within specified elements of an XML document. For example, suppose a particular XML document type contains elements called product_description. You can write a query that searches only the text within the product_description elements in the selected documents. For more information, refer to “Fulltext Searching” on page 3-2.

XDQL

XDQL is a Java class that provides an XML interface over DQL. Using XDQL allows you to return attribute values and content of the queried documents. Additionally, with XDQL, you can control the format of the results. For more information about using XDQL, refer to “Querying with XDQL” on page 3-4.

IntroductionQuerying XML Documents



2Creating XML Applications 2

Most enterprises have many different types of documents, with different purposes and content. If the content of some of these documents is XML, then you may need to create custom XML applications to handle the documents. The custom XML applications define type-specific processing, such as how to process the metadata, how to chunk the XML content, or which lifecycle to apply to the document.

This chapter describes how to create XML applications. It includes the following topics:

■ “Procedure Overview” on page 2-1

■ “The Preliminary Steps” on page 2-2

■ “Writing the Configuration File” on page 2-7

■ “Writing the DTD” on page 2-17

■ “Creating the Supporting Documents” on page 2-18

■ “Storing the Supporting Documents” on page 2-18

■ “Creating the Application Folders and Populating Them” on page 2-19

■ “Troubleshooting Your XML Application” on page 2-22

Procedure Overview

➤ To develop and create an XML application, you must:

1. Complete the following preliminary steps:

a. Determine the requirements of the application.

b. Create any needed object types, ACLs, and lifecycles.

Refer to “The Preliminary Steps” on page 2-2 for information about these preliminary steps.

Creating XML ApplicationsThe Preliminary Steps


2. Create the configuration file.

Refer to “Writing the Configuration File” on page 2-7 for guidelines about creating a configuration file.

3. Create any other supporting documents, such as the DTD, style sheets, or FOSIs.

These are optional in an XML application. For information about creating a DTD, refer to “Writing the DTD” on page 2-17. For information about other supporting documents, refer to “Creating the Supporting Documents” on page 2-18.

4. Create the folders for the XML application.

5. Import the XML application documents into the appropriate folders.

“Creating the Application Folders and Populating Them” on page 2-19 contains instructions for creating the folders and importing the application documents into the folders.

The Preliminary Steps

Be sure to complete these steps before you create the application in the Docbase.

Determining the Requirements

After you decide to create an XML application for a particular kind of XML document, you must make several decisions before you actually create the application. These decisions include:

■ What elements within the document, if any, do you want to create as separate objects in the Docbase?

■ What object type will be applied to each of those elements when they are saved as objects?

■ What ACL will be assigned to each new object created by the application?

■ Will any of the objects be attached to a lifecycle? If so, which lifecycle?

■ Do you want to set any metadata for the new objects?



■ In which folder or cabinet do you want the new objects stored in the Docbase?

■ Do you want to validate XML documents processed by the application?

■ Do you want to validate the objects that comprise 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.

Determining What Chunks to Create as Objects

One of the advantages of using XML content is the ability to chunk the content, to break an XML document into smaller pieces that can be reused in multiple documents. Documentum allows you to chunk on any element tag in the document.

Documentum creates a separate Docbase object for each chunk of content that falls between the opening and closing tag of any tag designated in the configuration file as a chunking element. For example, suppose you want to chunk documents processed by an application on all <Head1> tags. This means that all the content in a document occurring within any matched set of opening and closing <Head1> tags (<Head1> - </Head1>) is chunked and saved in the Docbase as a separate object.

The appropriate level of chunking granularity for any particular kind of XML document will depend on your manageability and re-usability requirements. You can chunk your documents into any number of chunks, and chunks can be nested. However, keep in mind that as the level of granularity increases, the amount of time needed to process the document increases. For example, a document that is chunked on paragraphs takes longer to process than a document that is chunked on section headings. And a document chunked on section headings will take longer to process than a document chunked on chapters.

You can decide not to create any chunks from documents handled by an application.



Which Object Types to Assign the New Objects

In the configuration file, you can define a rule that tells the system what object type any new objects created by the rules must be.

If the new objects are components of the top-level virtual document, there is no requirement that each new object be the same object type. They can be SysObjects or SysObject subtypes except folders, cabinets, or subtypes of these. Typically, the new objects will be dm_document subtypes.

Your business rules will determine which object types to make the new objects. If you need to use custom metadata, you may need to create some custom object types.

If you don’t provide a rule to define the object type, the system creates the new objects as dm_document.

Which ACL to Assign to Each New Object

The ACL defines which users can access each object and what level of access the users have. You can create a rule that assigns an ACL to each chunk. The ACL must be a system ACL and it must exist in the Docbase at the time it is assigned to a chunk.

If you chose not to assign an ACL to a chunk using a rule, the system uses the standard default when creating the object. (The standard default is determined by the setting in the default_acl attribute of the server config object.)

For information about ACLs and how they are implemented, refer to eContent Server Fundamentals and the eContent Server Administrator’s Guide.

Using a Lifecycle

A lifecycle, also called a business policy, is a series of states that represent the stages of life for a document or other SysObject. Business rules typically determine when an object in a lifecycle 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. Lifecycles are described in detail in eContent Server Fundamentals.



You can attach a lifecycle to any or all of the objects created from the chunks of an XML document.

Determining the Storage Location

You must specify a storage location for each object created by the processing. There is no default. The storage location must be a folder or cabinet in the Docbase. If the folder or cabinet you specify in the rules doesn’t exist, the system will create it at runtime.

You can use the var element to dynamically set the location. You can also set metadata for the folder or cabinet when you specify the location.

Determining What Metadata to Set

You can define rules to set any of the read and write metadata in the objects. However, when determining what metadata you want to set, keep in mind that the system sets the metadata when it creates the objects and each time the object is subsequently checked in to the Docbase. If a rule sets an attribute and a user sets that attribute through a client application such as Desktop Client™, the value is overwritten when the document is checked back into the Docbase.

Validating Against a DTD or Schema

If you include a validation rule to validate against a DTD or schema, each time the application processes a document for import or checkin, it will validate the document against the DTD or schema.

Validating Against the Data Dictionary

The data dictionary is a repository of information in the Docbase about object types and metadata. You can define a rule that directs the system to validate the objects that make up the document against the information in the data dictionary. The objects are validated when they are created and each time they are checked in to the Docbase.

The scope of the validation rule is all objects that make up the document. If you enable data dictionary validation, all objects in the document are validated. The objects are validated at the object type and attribute levels.



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, flags such as read-only, is_immutable, is_required, and format_pattern.

In some instances, failure to pass data dictionary validation causes the save or check in operation to fail. In other instances, failure will display a dialog asking the user to pick a value.

If you choose to use data dictionary validation, it may significantly decrease processing performance. The length of time requiredfor the save or check in operation increases directly in proportion to the number of objects and the amount of information that must be validated.

For information about defining data dictionary information, refer to eContent Server Fundamentals.

Creating the Underlying Architecture

After you have made the decisions outlined in “Determining the Requirements,” you may need to create new object types, new ACLs or a new lifecycle or two. If you are validating the objects against the data dictionary, you may also need to define the desired data dictionary information.

To create a new object type, you must have Create Type, Sysadmin, or Superuser privileges. Creating a system-level ACL requires Sysadmin or Superuser privileges. To define data dictionary information, you must be the owner of the object type or have Superuser privileges.

Instructions for creating new object types and ACLs are found in eContent Server Administrator’s Guide.

Instructions for creating new lifecycles and defining data dictionary information are found in eContent Server Fundamentals.

Creating XML ApplicationsWriting the Configuration File


Writing the Configuration File

The configuration file contains the rules that tell the system what Docbase operations to perform on the XML document. The system parses the document and applies the rules based on the content of the document.

The configuration file is itself an XML document and must conform to the config.dtd provided by Documentum with the Default XML Application. The config.dtd is stored in /System/Applications/Default XML Application.

Note: Documentum also provides an online reference for the DTD called config.htm. This file describes each element in the DTD, its use and attributes.

Each Documentum XML application must have one and only one configuration file.

Basic Structure

A configuration file contains, in the listed order:

■ General application information (required)

■ Validation rules (optional)

■ Map rules (required)

The general application information comprises the XML declaration, the prolog, and some other information. For details about this section and the material to include, refer to “Defining the General Information” on page 2-8.

The validation rules direct the system to validate documents processed by the XML application against a DTD or the data dictionary or both. For instructions about writing the validation rules, refer to “Writing Validation Rules” on page 2-9.

The map rules define the rules for the Docbase operations on the individual objects that make up the XML document. The rules determine which elements are chunked and created as objects, what metadata are set for those objects, where the objects are stored, and so forth. For instructions about writing map rules, refer to “Writing the Map Rules” on page 2-9.



Note: For a complete list of the elements that can appear in configuration file rules and details of each, refer to the config.htm document. The guidelines in the following section for map rules do not describe all possibilities, only the common ones.

Defining the General Information

The general information is placed at the beginning of the configuration file. Because this file is an XML document, the first line must be the following XML declaration:

<?xml version="1.0"?>

The next line in the file is the prolog, which has the following format:<!DOCTYPE application SYSTEM "config.dtd">

The next line tells the system which XML application to use when processing this document. However, because this is a configuration file and is not usable if chunked, format this instruction as follows to bypass the application processing:

<?dctm xml_app="Ignore"?>

The value Ignore tells the system not to process this document as an XML document. You must include this instruction; if you leave it out, the system will use the Default XML Application to process the document.

After the processing instruction, include the root element, which is application, followed by the name and app_pattern elements:

<application><name>application_name</name><app_pattern><element>application_root_element</element>

</app_pattern>

The root element of the configuration file is “application”.

The name element identifies the XML application to which this configuration file belongs. Note that each XML application in a Docbase must have a unique name. The app_pattern element identifies the root element of documents processed by this XML application.

When you complete the general information portion of the configuration file, it should look like this:

<?xml version="1.0"?><!DOCTYPE application SYSTEM "config.dtd"><?dctm xml_app="Ignore"?><application>



<name>application_name</name><app_pattern><element>application_root_element</element>

</app_pattern>

Writing Validation Rules

If you want to validate XML documents processed by the application against a DTD, include the following rule in the configuration file:

<validation/>

If you want to validate the objects that make up the document against information in the data dictionary, include the following rule in the configuration file:

<dds_validation/>

(For information about the scope of the validations and what data dictionary information is used for validation, refer to “Validating Against a DTD or Schema” on page 2-5 and “Validating Against the Data Dictionary” on page 2-5.)

Writing the Map Rules

All configuration files must have map rules. To begin the map rules portion of the file, include the following tag:

<map_rules>

The map rules tell the system how to process the XML document. There are four kinds of rules:

■ XML content rules, which describe how to chunk the XML content and what Docbase operations to perform on each resulting object

■ Link rules, which describe how to handle links and NDATA entities

■ Non-XML content rules, which describe how to handle non-XML content

■ Entity rules, which describe how to handle parsed general entities

You must include an XML content rule for each element tag that will be chunked into a separate document. “XML Content Rules” on page 2-10 contains some instructions and samples. The system automatically creates the top-level virtual document. However, if you want to include some special processing rules for that document or declare some variables for use in any element of the document, you can include an xml content rule for the top-level document also.



Include link rules if the processed documents will contain links and NDATA entities. Refer to “Link Rules” on page 2-14 for guidelines and a sample.

Include a non-XML content rule if you expect the documents processed by the application to include non-XML content. “Non-XML Content Rules” on page 2-16 shows a sample non-XML content rule.

If you don’t include an entity rule, the system treats parsed entities as part of the XML document and processes them according to the rules in the xml content rules. If an entity rule is included, parsed entities are stored in the Docbase as separate objects and maintained as parsed entities. “Entity Rules” on page 2-16 shows a sample entity rule.

All four kinds of rules have the following general structure, in the listed order:

■ Element selection pattern

■ Variable selection

■ Object rules

The element selection pattern defines which element tag triggers the rule. When an element in a document matches the pattern, the rule is applied. If two rules apply for the same element, the first one in the configuration file is applied.

The variable selection portion declares variables to use when extracting information from the processed document.

The object rules are used to define the object type created for a chunk, set object metadata, assign an ACL, specify a location for the object, and attach a lifecycle to the object.

XML Content Rules

XML content rules are defined with an xml_content_rule element. You must include an xml_content_rule element for each element tag within the document that you want to chunk out as a separate object.

The make_object Attribute

The xml_content_rule element has an attribute called make_object. By default, this rule is true and directs the system to create a Docbase object from the element that triggered the rule.



However, you can use xml content rules for purposes other than creating objects. For example, you might want to simply gather some information from parts of a document. In such cases, set the make_object attribute in the rule’s opening element tag to false.

Element Selection Pattern

The element_selection_pattern element within the xml_content_rule triggers the application of the rule.

If you include an xml content rule for the top-level document, the element_selection_pattern element must identify the root element of the XML document. For example, here is the element_selection_pattern in the xml_content_rule for the top-level document in the cellphone catalog example:

<xml_content_rule export="inline" editable_virtual_doc="false">

<element_selection_pattern> <element>cellphone-catalog</element>

</element_selection_pattern> ...

cellphone-catalog is the root element of documents processed by the cellphone catalog application.

The cellphone catalog documents are chunked on two elements: model and description. Consequently, there is an xml_content_rule element for each, with the appropriate element_selection_pattern in each rule:

<xml_content_rule export="inline" editable_virtual_doc="false">

<element_selection_pattern> <element>model</element>


and<xml_content_rule export="inline" editable_virtual_doc="false">

<element_selection_pattern> <element>description</element>


Notes: The export attribute controls how Documentum handles the document when it is exported. The only valid value is “inline”, which directs the server to pull together all parts of the document and export it as one document.



The editable_virtual_doc attribute determines whether users can edit the document’s structure in VDM (Documentum’s Virtual Document Manager). The only valid value is “false”.

Declaring Variables

Variables have many uses. For example, you can use them to obtain contents of elements, metadata, and tag names.

To declare variables, you begin by including the following element in the xml_content_rule:

<variables>

Then, use a variable element and the elements it uses to declare the variable, define its content, and optionally, provide a default value for the variable. For example, here is a variable declaration from the cellphone catalog example:

<variable><name>modelName</name><content_of_element>

<element_selection_pattern><element>model.name</element>

</element_selection_pattern></content_of_element><default>Model Unspecified</default>

</variable>

Variables are locally scoped, based on the element that triggers the rule in which they declared. 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 an content rule for an element with the document, then the variable is available only when processing content within that chunk.

When you have included all the variable declarations you want, be sure to put the closing element (</variables>) in the content rule.

Object Rules

Object rules define Docbase operations that the system will perform on the objects created from the XML document. There are several kinds of object rules. You can include rules that tell the system:

■ Where to place the object in the Docbase (in which folder or cabinet)

■ What object type and object name to assign the object

■ Which ACL to assign to the object



■ To attach a lifecycle to the object

■ To set object metadata

Designating the location: Use the location element to define the location for the object created by the xml content rule. For example, here is the location rule for the xml content rule for model chunks in the cellphone catalog application:

<location> <path>Models/</path>

</location>

You can dynamically identify the location using the var element.

The location you identify must be a folder or cabinet. If it doesn’t exist, the system will create it.

You can specify full or relative paths. If the object is the top-level virtual document and you specify a relative path, the location is created relative to the folder or cabinet into which the document is being imported. If the object is a chunk of the document and you specify a relative path, the path is relative to the parent chunk. For example, suppose you create chunks from <Head1> and <Head2> headings and specify a relative storage location for the <Head2> chunks. Their storage location is created relative to the location specified for the <Head1> chunks.

The location rule allows you to set metadata for the folder or cabinet.

Designating the Object Type, Name, and Owner: Use the object_type element to define the object type of the stored chunk. If you don’t identify an object type in the xml content rule, the system creates the object as a dm_document by default.

Use the object_name element to set the object’s name. Use a variable to set the name, so that each object created by that rule has a different object name.

For example, here are the rules setting the object type and name of each model chunk in the cellphone catalog application:

<object_name><var name="modelName"/></object_name>

<object_type>cell_phone_catalog_item</object_type>

Use the owner_name element to define an object’s owner. By default, the user executing the import operation is the object’s owner.

Assigning an ACL: Use the acl_name element to assign an ACL to the object created by the xml content rule.



The ACL identified by the rule must be a system ACL and must exist when the rule is executed. If you don’t assign an ACL, the system assigns the default ACL to the object.

Attaching a Lifecycle: To attach a lifecycle to the object, use the business_policy element. For example, here is the rule that attaches the model objects in the cellphone example to a 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>

Setting Object Metadata: Include all the metadata in one section of the rule that begins with the metadata element. After the metadata element, use the dctmattr element to identify and set the desired single-valued properties. Use the dctmattr_repeating element to set repeating properties.

You can define explicit values for the properties or use variables to set the values dynamically. For example, here is a portion of the xml content rule for model chunks that sets the title property:

<metadata> <dctmattr>

<name>title</name> <template><var name="brandName"/>-(model <var

name="modelName"/>)-$<var name="price"/></template> </dctmattr>

Any properties that you set in the xml content rule are set when the object is created and each time the object is checked in to the Docbase.

The make_entity Element

The make_entity element directs the system to manage the structural elements of the virtual document as entities. You must include the make_entity element in each xml_content_rule element. Include it just before you close an xml_content_rule element.

Link Rules

Link rules determine how the XML application handles links and NDATA entities in the documents processed by the application. There are two kinds of links that a link rule can handle: peer and child.



A peer link is a link such as a See Also reference in an XML document. A link rule for a peer link creates a relationship between the referenced document and the XML document. The system pulls the referenced document into the Docbase and creates a relationship of type xml_link between the referenced document and the XML document. (Relationships are described in detail in eContent Server Object Reference Manual.)

A child link is a link that refers to a document whose content is displayed within the document. For example, a graphic image that is visible in the XML document may be referenced in the underlying document as a link. A link rule for a child link pulls the linked document into the Docbase as an object and makes that object a component of the XML document’s virtual document.

Like xml content rules, you can declare variables, set object metadata, and perform the other Docbase operations in a link rule. However, don’t use the make_entity rule in a link rule.

Here is a sample of a link rule, taken from the cellphone catalog application:<link_rule peer_or_child="child" ndata="false">

<element_selection_pattern> <element>image</element>

</element_selection_pattern> <link_target>

<attr_name>href</attr_name> </link_target> <variables>

<variable><name>ImgName</name> <content_of_element>

<element_selection_pattern> <element>image</element>

</element_selection_pattern> </content_of_element> <default>Title Unspecified</default>

</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>



Non-XML Content Rules

A non-XML content rule defines how Documentum recognizes and handles non-XML content, such as base64encoded data, in an XML document. A non-XML content rule is started with the non_xml_content_rule element. Here is a simple example of this kind of rule:

<non_xml_content_rule><element_selection_pattern>

<element>mybase64</element></element_selection_pattern><format_attr>crtext</format_attr><link_template><muybase64ref ref=<var name="location"/>"></mybase64ref></link_template>

</non_xml_content_rule>

Non-XML content rules can also contain rules to define object metadata, assign ACLs, and so forth, if you wish to save the non-XML content as an object in the Docbase.

Entity Rules

An entity rule defines how to handle external parsed entities referenced in the XML document. If you don’t include an entity rule, the system treats parsed entities as part of the XML document and processes them according to the rules in the xml content rules. If an entity rule is included, parsed entities are stored in the Docbase as separate objects and maintained as parsed entities.

Begin an entity rule with the entity_rule element. There are only two properties you can set for an entity rule: location and object_type.

Closing the Rules

XML documents must be well-formed. That is, all the element tags must be closed or defined as empty tags (end with />). After you write your configuration file, make sure that all the rules, variable declaration sections, and metadata sections are closed. Check all elements to ensure that they are properly written and closed.

Creating XML ApplicationsWriting the DTD


Writing the DTD

A DTD is an optional document in an XML application. However, if you want to validate documents processed by the application, you must associate a DTD or schema with the application. We strongly recommend that you use a DTD for your application. Using a DTD ensures that the system won’t encounter unexpected element tags when processing documents.

If the application has a DTD, the DTD must declare the attributes listed in Table 2-1. Documentum adds these attributes to each element tag in the document that represents a chunk. These attributes have two purposes:

■ The XML editors use the attributes to make text read only and indicate changes when text is edited.

■ Documentum uses the attributes to process objects on import and checkin.

Table 2-1 Documentum Attributes Declared in DTD

Attribute Values Purpose

xmlns:dctm http://www.documentum.com

DCTM Namespace URI declaration

dctm:obj_status default This value is added for an object that is checked out. If the object status is default on check in, the object is versioned.

read-only The attribute is set to this value if the object is not checked out. The editors will make the contents read-only.

continued on next page

changed The attribute is set to changed by an editing application. If the attribute value is ”changed” when the object is checked in, the object is versioned.

unchanged If the attribute value is set to unchanged when the object is checked in, the object is not versioned.

Creating XML ApplicationsCreating the Supporting Documents


Declare the attributes in the following format: xmlns:dctm CDATA #IMPLIEDdctm:obj_id CDATA #IMPLIEDdctm:obj_status CDATA #IMPLIEDdctm:version_label CDATA #IMPLIED

Creating the Supporting Documents

An XML application may require additional documents, such as cascading style sheets, XSL style sheets, or FOSIs (Formatting Output Specification Instances) to support XML authoring tools.

If you need these documents, you can create them before or after you create the XML application. The only supporting document that must be created before you create the application is the DTD—if you intend to use one with the application.

Storing the Supporting Documents

Within an XML application folder, you can create another folder called Application Support Documents. When a user works with an XML document processed by the application, the system downloads any documents in this folder to the user’s local machine.

Using the Application Support Documents folder as the storage location for the supporting documents is an easy way to manage these documents automatically.

Note: Do not put the configuration file in the Application Support Documents folder.

dctm:obj_id Value of r_object_id Object id of the object in Documentum

dctm:version_label Value of r_version_label

Version label of the object in Documentum

Creating XML ApplicationsCreating the Application Folders and Populating Them


Storing the DTD

You can store the DTD in the Application Support Documents folder or anywhere it is accessible to users when handling documents processed by the application. However, if you want Documentum to validate XML documents using the DTD, you must put the DTD in the Application Support Documents folder.

If it is stored in the Application Support Documents folder, it will be downloaded to the client machine with the other supporting documents. The system will also modify the general information in the checked out XML document to reflect the local location of the downloaded DTD.

If you put the DTD in another location, it must be somewhere that is accessible to the users who will be working with the documents that reference the DTD.

If the DTD is modular, then you must store all parts of it in the Application Support Documents folder.

Creating the Application Folders and Populating Them

You can create an XML application using any Documentum client that allows you to create folders and documents. The following procedure shows you how to do it using Desktop Client.

➤ To create an XML application in Desktop Client:

1. In Desktop Client, connect to the Docbase as a superuser.

2. Create the folder for the application:

a. Select the Applications folder in the Systems cabinet.

b. Choose File➤ New➤ Folder.

A New Folder dialog box appears.

c. Type the name of the folder.

The name must match the name of the XML application, identified in the configuration file, and this must be unique within the Docbase.



d. Choose XML Application from the drop-down list in Type.

e. Click New.

3. Set the new folder’s properties and permissions:

a. Make sure the folder is selected, then choose File➤ Properties.

The Properties dialog box for the folder appears.

b. Select the Custom tab to display the fields for the custom metadata.

c. Set the following:

❒ Public_Identifier

This is the PUBLIC identifier in the DOCTYPE declaration in the application’s configuration file.

❒ System_Identifier

This is the SYSTEM identifier in the DOCTYPE declaration in the application’s configuration file. This is a required attribute.

❒ Root Elements

Type in the names of the element tags that are defined as element selection patterns in xml content rules. The first should be the root element of the top-level document. This is a required attribute.

❒ NameSpace

This attribute value is the NamespaceURI associated with the first root element specified in Root Elements.

d. Select the Permissions tab to display the current permissions.

e. If the current permissions don’t give Read access to the users who will process documents using the application, change them to do so.

f. Click Apply, and then OK.

4. To create the Application Support Documents folder:

a. Select the folder created in Step 2.

b. Choose File➤ New➤ Folder.

A New Folder dialog box appears.

c. Type Application Support Documents as the name of the folder.

d. Choose dm_folder from the drop-down list in Type.



e. Click New.

5. Import the configuration file into the XML application folder created in Step 2:

a. Open the XML application folder.

b. In your file system, browse to the configuration file.

c. Select the file and drag and drop it into the XML application folder.

The Import dialog box appears.

d. Type the name of the configuration file.

This must match the name of the XML application.

e. Choose XML Configuration from the drop-down list in Type.

f. Choose XML Document in Format if it isn’t displayed by default.

g. Click Import.

6. To import the DTD into the Application Support Documents folder:

a. Open the Application Support Documents folder.

b. In your file system, browse to the DTD file.

c. Select the file and drag and drop it into the Application Support Documents folder.

The Import dialog box appears.

d. Type the name of the DTD file.

This must match the value identified in the System Identifier for the XML application folder.

e. Choose dm_document from the drop-down list in Type.

f. Click Import.

7. Import any other supporting documents you have created for the application into the Application Support Documents folder.

Creating XML ApplicationsTroubleshooting Your XML Application


Troubleshooting Your XML Application

After you set up your XML application, import an XML file using Desktop Client. You should see the name of the XML application you created in the drop-down list box. If the name is not there, check to make sure that the XML Application is of type dm_xml_application and that you have set all the metadata correctly.

If you receive an error when you import the XML document, check to see if a binary rendition was created for the XML application configuration file. If a rendition has not been created, there is a problem with the validity of the XML document, or the XML configuration file does not conform to the config.dtd. If a rendition does exist, you may have specified some options incorrectly, for example, defining an object type that does not exist.

Distributing XML Applications as DocApps

After you have created an XML application, you can package the application and its supporting object types, workflows, and lifecycles as a DocApp, for distribution to other Docbases in your enterprise. For instructions about creating DocApps, refer to the Documentum manual Developing DocApps.


3Querying XML Documents 3

This chapter describes the various ways that users can query XML documents. It includes the following topics:

■ “Overview” on page 3-1

■ “Querying With DQL” on page 3-1

■ “Querying with XDQL” on page 3-4

Overview

You can use either DQL or XDQL to query XML documents.

DQL, Document Query Language, allows you to query properties (metadata) and content of a document. Basic query statements allow you to query properties, and the optional SEARCH clause allows you to query content. “Querying With DQL” describes how to use DQL to query XML documents.

XDQL is a Java class that allows you to query properties and content and return the objects as XML documents. The methods that make up the class give you control over the format of the results. “Querying with XDQL” on page 3-4 describes XDQL in more detail.

Querying With DQL

DQL has a set of basic query statements that allow you to query both the metadata and content of documents in the Docbase.

Whether you decide to query metadata or content in your applications will depend on your business requirements. For example, suppose you want to return all documents that have a particular value, such as a particular model name, in a given element. In this case, querying against an attribute would be

Querying XML DocumentsQuerying With DQL


the best way to query this information. Or, perhaps you want to obtain all documents whose content references a particular topic. In this case, a fulltext search of the content is best.

To support queries against metadata, Documentum’s XML implementation allows you to use rules in the configuration file to extract information from the document and store it in the metadata.

If the document is stored as a virtual document, you can query the document’s entire hierarchy or some portion of it.

Querying metadata of an XML documents is no different from querying metadata of any other document in the Docbase. For information about using the basic query statements to query metadata and virtual documents, refer to eContent Server Fundamentals, Chapter 3, Using DQL, and the descriptions of the statements in the eContent Server DQL Reference Manual.

Fulltext Searching

Because of their structured nature, XML documents lend themselves well to queries that make use of the fulltext searching capabilities of DQL. You can use the fulltext searches to find documents that contain specified text within particular elements of an XML document.

The Verity FullText Engine treats each element in the document as a zone. (A zone consists of everything between a start element and an end element.) This allows you to execute queries that search for a given value within specified elements at the granularity level you choose.

For example, the following query finds all catalogs that have the value quasivox in the element brandname:

SELECT * FROM dm_document SEARCH TOPIC ’quasivox <IN> brandname’

The next example returns all documents that have the value speed dialing in the memoryfeatures element. The search is furthur limited to documents in which the memoryfeatures element occurs within a cellphone-catalog element.

SELECT * FROM dm_document SEARCH TOPIC ’(speed dialing <IN> memoryfeatures) <IN> cellphone-catalog’

Querying XML DocumentsQuerying With DQL


The next example restricts the search 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 memory features element must be contained in a cellphone-catalog element.

SELECT * FROM dm_documentSEARCH TOPIC ’((speed dialing <IN> callfeatures)<IN> memoryfeatures) <IN> cellphone-catalog’

You can, of course, use SELECT’s optional clauses to apply other restrictions to the results. For example, the following query returns only documents that are owned by JoanK that meet the SEARCH clause requirement:

SELECT * FROM dm_document SEARCH TOPIC ’quasivox <IN> brandname’WHERE owner_name=’JoanK’

Using a Zone File

A zone file is a Verity style file. Style files are used to customize a fulltext index. You can use zone files to provide enhanced capabilities for fulltext searching in zones. With zone files, you can:

■ Set up special filters for different types of XML documents to indicate what metadata and elements should be made into searchable zones

■ Designate zones to be stored within Verity to set up queries that compare two different elements

When you create a zone file, you must identify:

■ Elements to use as zones

By default, all elements constitute zones in Verity.

■ Elements to extract as fields

■ Metadata to use as zones or fields

■ Processing information about how entities are to be read by the full-text engine

For instructions about creating a zone file, refer to the Verity documentation. After you create the zone files, use Documentum Administrator to add these files to your fulltext indexes. For instructions about adding zone files to fulltext indexes, refer to the eContent Server Administrator’s Guide.

Querying XML DocumentsQuerying with XDQL


Known Limitations

There are some known limitations with the Verity FullText Engine included with e-Content Server 4.1. For example, the zone searching in 4.1 does not account for the syntax changes between SGML and XML. EMPTY element tags are not recognized and there is no support for namespaces.

Querying with XDQL

XDQL is implemented as a Java class called DfXMLQuery. The methods in this class allow you to run DQL queries and return the results as XML documents. Unlike DQL, XDQL retrieves the actual content of the objects in the search results. The class methods also you to control the format of the returned document.

XDQL is a powerful tool because you can use it in avariety 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 by calling from a servlet or JSP

■ Build dynamic XML documents by calling through XSLT extensions

You can call DfXMLQuery from any Java application, servlet or JSP, and EJB. You can also call it through XSLT using extension functions. (Extension functions are a feature of XSLT that allow you to call out to Java programs and other scripting languages.)

DfXMLQuery uses the DFC library to communicate with the Docbase for querying and retrieving result collections and style sheets. The calling instance must establish a Documentum session (log in to the Docbase) and pass it to DfXMLQuery. This session is used to query the Docbase and to retrieve defined style sheets.



DfXMLQuery Methods

Table 3-1 briefly describes the methods in the DfXmlQuery class:

Table 3-1 DfXmlQuery Methods

Methods Description

getXMLDOM() Returns the resulting XML document as a DOM (class Document).

getXMLDOM(node) Returns the resulting XML document as a DOM with the specified node as starting point (class Document).

getXMLString()

getXmlString(PrintWriter)

Returns the resulting XML document as a string or writes the string to the print writer. If there is a stylesheet specified, it will be applied to the result.

getXMLString(Node) Returns the resulting XML document as a string with the specified node as the starting point. If there is a stylesheet specified, it will be applied to the result.

includeDCTMChunkInfo(Boolean) If TRUE, the values of the dctm_obj_id and dctm_status attributes are included as part of the returned content.

setErrorTag(String) If an error occurs during processing, use this string as an element tag name for including error messages. The error element is the top-level element, and the value contains the Documentum error message. The default is “error”.

setMaxRows(int) Sets the maximum number of rows to return. The default value is no maximum (the value is set to 0).

Notes:

The resulting DOM is loaded into memory.

For nested virtual documents, this value limits the number of objects returned; it does not limit the number of row-elements.



setRowIDAttrName(String) Specifies an XML attribute name of the rowset that is an XML ID value. The default is ID.

setRowIDColumn(String) Specifies the column (Documentum attribute name) to be used to populate the XML ID value.

Note: You must construct your query appropriately to ensure unique ids are returned

setRootNode(String) Sets the root node for all rowsets. The default root node tag name is “root”.

setRowsetTag(String) Sets the tag to be used for each row of a collection. The default is “object”.

setStyleSheet(String) Specifies a style-sheet to use to transform the results before sending them back. The transformation is done when the getXMLString(PrintWriter) is called. The parameter is either a valid r_object _id, a valid Docbase folder path (starting with a forward slash, /), or an URL.

useGivenCaseTagNames() Directs the processor not to change the case of tag names.

useLowerCaseTagNames() Sets tag names and attribute names to lowercase. For example, MyDocs returns as mydocs.

useUpperCaseTagNames() Sets tag names and attribute names to uppercase. For example, MyDocs returns as MYDOCS.

useNullAttributeIndicator(Boolean) Returns a null value (nullstring, nulldate) as “null”.


Methods Description



includeContent(Boolean) Includes the content of a returned result. It must include r_object_id in the SELECT statement of the query. The default returns the primary content as an element value that is “base64” encoded.

setContentFormat(String)s Defines the Docbase format to be used. It can specify a comma-separated list or “*” to use default content. If the content is not found, an error is returned as an attribute of the content element. To return a result in either case, specify “*” (e.g. “html,pdf,gif,*”).

setContentTag(String) Sets the element tag name to include content in the result set. The default value is “content”. The content element has the following attributes by default: format, mime-type, encoding.

setContentAsLink(Boolean) Includes a link to the content file, not to the content itself. The URL syntax is: <base>DMW_OBJECTID=<r_object_id>&DMW_FORMAT= <format>.

<base> must be set with “setLinkBase”.

setExportContent(Boolean) If set to TRUE, passes the content through the XML export function before the content is embedded.

setLinkBase(String) Sets the base URL for link retrieval of content. For example Right Site can retrieve the content with the following URL: “http://myhost/rs-bin/RightSite.dll/getcontent/foo.htm?DMW_DOCBASE=mydocbase&”

setVirtualDocumentNested(Boolean) Setting this flag to “yes” means that a Virtual Document query must contain “depth” in the query SELECT statement for this to be valid. This will nest the result set.

setRepeatingIncludeIndex(Boolean) By default, includes the index number as an attribute.


Methods Description



Errors

If an error occurs when a method in the DfXMLQuery class executes, the method either:

■ Throws an exception

■ Returns an element called <error> that contains the error message.

For example, if a query returns an object whose content isn’t found, the method returns an error element in the XML content that contains the error message.

setRepeatingAsNested(Boolean) Nests repeating attribute values adding “-value” for tagname or whatever was specified using “setRepeatingAsNestedTag(String)”.

setRepeatingAsNestedTag(String Sets the element tag-name extension of the nested repeating values. By default it is set to “-value”.

setMetadataAsAttributes(Boolean) If set to TRUE, metadata is expressed as attributes, instead of elements. The default value is to express metadata as elements not attributes.

Repeating attributes are always element values.

setDql(String) Defines the DQL statement to be executed.

execute(String, IDfSession) Executes the query and loads the resulting DOM. With the string, the mode of the query is specified (Read/Exec). The session passed to DfXmlQuery has to be connected and established by the calling class.


Methods Description


4Transformation 4

This chapter describes the XML transformation features available through Documentum. The chapter includes the following topics:

■ “What is Transformation?” on page 4-1

■ “What is XSLT?” on page 4-2

■ “Transformation Support in the DFC” on page 4-2

■ “Using Transformation to Dynamically Build Documents” on page 4-4

What is Transformation?

Transformation is a process that takes an XML document and an XSL style sheet as input and outputs a document as HTML, text, or XML. The Documentum XSLT integration is a powerful feature. In addition to using the transformation capability to transform a document from one format to another, you can use it to create a rendition of a document, transform a document from one schema to another, or even change the document’s content.

For example, suppose your business is exchanging documents with another business in a B2B exchange. You may need to transform the documents coming from the other business from their schema to yours before processing them. Or, perhaps you’ve changed a product’s name and you want to replace the old name with the new name in your documents.

All these options are possible because XSL style sheets are powerful, almost a programming language.

The style sheet and the document are given as input to an XSLT engine, which applies the style sheet to the document and produces the output. Documentum provides the Apache Xalan XSLT engine as a standard transformation engine.

TransformationWhat is XSLT?


Because the transformation capabilities are implemented through the DFC (refer to “Transformation Support in the DFC” for details), you can invoke transformation from any Java application or through lifecycles or methods.

What is XSLT?

XSLT is the acronym for Extensible Style sheet Language for Transformation. XSLT is a subset of the XSL language.

Transformation Support in the DFC

The DFC classes DfTransformOperation and IDfTransformOperation support XML transformation operations. After you instantiate a DfTransformOperation object (representing a transformation operation), you use the methods in the IDfTransformOperation class execute the transformation operation. These methods let you pass XML documents in the Docbase and style sheets to the transformation engine and store the results in the Docbase as either new objects or renditions of the original objects.

You can also call the DFC, including the XDQL interfaces, directly from the style sheets. This gives you full access to the Docbase during processing, allowing to dynamically build XML documents. (Refer to “Using Transformation to Dynamically Build Documents” on page 4-4 for an example of this.)

The DfTransformOperation class supports all the standard input and output options of the Xalan XSLT engine.

For details of the IDfTransformOperation and DfTransformOperation class, refer to the Javadocs.

Example

Here is an example of the steps needed to execute a transformation operation. Additional code samples for transformation are available on the Documentum Web site under Products & Services - Developer.

TransformationTransformation Support in the DFC


➤ The basic steps are:

1. Create a new transformation operation:IDfXMLTransformOperation transformOperation = new DfXMLTransformOperation();

2. Establish the session to use for the transformation processing:transformOperation.setSession(session);

3. Get the dm_sysobject of the document to be transformed: IDfSysObject inputObj = (IDfSysObject)session.getObject(new DfId("0901b66980009a45"));

4. Add the document to be transformed by the operation:IDfXMLTransformNode inputNode = transformOperation.add(inputObj);

5. Get the dm_sysobject of the stylesheet:IDfSysObject transformObj = (IDfSysObject)session.getObject(new DfId("09053db98003ab00"));

6. Set the stylesheet to be used:transformOperation.setTransformation(transformObj);// Setup to output the transformation results to a file. //DfFile output = new DfFile("C:\\transform.html");transformOperation.setDestination (output);

7. Execute the operation and check for errors:boolean execute = transformOperation.execute();

// Handle errors. // if(execute == false) {

IDfList errorList = transformOperation.getErrors();

for(int i = 0 ; i < errorList.getCount() ; i++) {

IDfOperationError error = (IDfOperationError)errorList.get(i);

String message = error.getMessage(); message = message + ".";

} }

TransformationUsing Transformation to Dynamically Build Documents


Using Transformation to Dynamically Build Documents

The ability to build documents dynamically during the transformation operation is accomplished by combining XDQL with the Java extension capabilities of XSLT.

XML documents that you transform can contain queries or data that you can use to build a query. In the XSLT style sheet, you then include rules that read the queries or data and execute calls to XDQL. The methods in XDQL allow you to return results (including content if needed) as a DOM, which can, in turn, be processed by the style sheet using XPATH queries.

For example, the following document contains two queries that retrieve information from the model-type element. When this document is processed using the style sheet in Appendix B, each query is extracted from the document and executed using a template function (named “XDQL”) defined in the style sheet.

<?xml version="1.0"?><cellphone-catalog><title>My Custom Cell-Phone Catalog</title><models><model-type>select r_object_id, object_name from cell_phone_catalog_item where price <= 99.99</model-type><model-type>select r_object_id, object_name from cell_phone_catalog_item where price > 99.99</model-type></models></cellphone-catalog>

The queries return all model objects and their content that meet the WHERE clause criteria. When processing is complete, the result is one document that includes all the models in the Docbase that meet the criteria.

Managing XML Content in Documentum A–1

AInstalling XML Functionality A

This appendix describes how to install the XML functionality in a 4.1 Documentum installation. Documentum’s XML support is an integral part of the Documentum 4.2 release. However, if you are installing 4.2 Desktop Client™ against a 4.1 Documentum server installation, you can use the procedure in this appendix to add XML support to the Documentum Server installation.

Required Files

There are three files required to install and use the XML functionality in a 4.1 Documentum Server installation. The files are:

■ dm_xml_install.dql

■ DefaultXMLapplication.xml

■ config.dtd

dm_xml_install.dql is the script you will use to install the XML support. This script adds to the Docbase the new object types that support XML functionality. DefaultXMLapplication.xml and config.dtd are needed to create Documentum XML applications.

These three files are packaged with Documentum Desktop Client. After you download the zip file that contains the 4.2 DTC release and extract the files, you will find these files in a folder called Docbase_Configuration_Files.

Installing XML FunctionalityInstallation Procedure

A–2 Managing XML Content in Documentum

Installation Procedure

➤ To install the XML support:

1. Navigate to the directory that contains the extracted files for Desktop Client 4.2.1.

2. Open the Docbase_Configuration_Files folder.

3. Move (or copy) the following files to the %DM_HOME%\bin ($DM_HOME/bin) directory of the Documentum Server installation:

■ dm_xml_install.dql

■ DefaultXMLapplication.xml

■ config.dtd

4. Log into the Documentum Server host machine.

5. Change to the %DM_HOME%\bin ($DM_HOME/bin) directory.

6. For each Docbase in the installation:

a. Start IDQL:idql -Uusername -Ppassword docbase_name

where username is a user with at least System Administrator privileges in the docbase; password is the user’s password; and docbase_name is the name of the Docbase.

b. At the prompt, enter: @dm_xml_install.dql

Note: If you previously installed the Desktop Client 4.2 Controlled Release, multiple error messages will display indicating that the XML types are already installed. You can ignore these error messages.

7. To check that the script installed the object types successfully, use Documentum Administrator:

a. Start Documentum Administrator and connect to the Docbase in which you ran the script in Step 6.

b. Click Types under Docbase Management.

A list of object types in the Docbase appears.

c. Expand the dm_sysobject entry and then the dm_document entry.


Managing XML Content in Documentum A–3

If the types were successfully installed, they appear under dm_document. The types you are looking for are:

❒ dm_xml_config (application configuration information)

❒ dm_xml_style_sheet (used for XSL style sheets)

❒ dm_xml_zone (not currently implemented; will be used in zone searching)

❒ dm_xml_application (dm_folder subtype)

8. Download the sample cell phone application from the XML_Sample_Application directory on the FTP site.

The readme file contains instructions for installing the sample application in a Docbase.

Installing the sample application is optional, but strongly recommended. This sample is an excellent way to test the XML processing and examine a working example.


A–4 Managing XML Content in Documentum

Managing XML Content in Documentum B–1

BExample Documents B

This appendix contains the text of some XML documents that are used to illustrate concepts in the previous chapters. The following are included:

■ “Cellphone Catalog Document” on page B-1

■ “Style Sheet for Dynamic Transformation Example” on page B-2

Cellphone Catalog Document

Here is the text of a document processed by the cellphone catalog application.

<?xml version="1.0"?><!DOCTYPE cellphone-catalog SYSTEM "CellPhoneCatalog.dtd"><cellphone-catalog> <model><modelname>Q-3200</modelname>

<brandname>Quasivox Brands</brandname> <description>

<Title>WARRANTY OFFER</Title> <Para>A VIP Priority Service Agreement is available for this product for only $59.95. Our top-rated service enhancement program includes:</Para> <ItemizedList> <ListItem> Loaner program</ListItem> <ListItem> Nationwide coverage</ListItem> <ListItem> Toll-free telephone support)

</ListItem> <ListItem>In-home service plans</ListItem> </ItemizedList>

</description> <specifications> <modetype modetype="Dual Mode"/>

<technology transfer="Analog" protocol="AMPS"/> <technology transfer="Digital Cellular"

protocol="CDMA" frequency="800"/> <price currency="USD" withcontract="true">69.99</price> <dimensions> <height>0</height> <width>2</width> <thickness>0</thickness>

Example DocumentsStyle Sheet for Dynamic Transformation Example

B–2 Managing XML Content in Documentum

</dimensions> <weight withbattery="true">8.5 killos</weight> <battery type="nickel-metal-hydride"> <talktime>200 minutes</talktime> <standbytime>49 minutes</standbytime> </battery> <displayfeatures characters.per.line="36"

text.lines="3"> <item>Backlight</item>

<item>Battery Strength Indicator</item> <item>Roaming or Channel Indicator</item>

<item>Signal Strength Indicator</item> <item>Voice Mail Or Text Indicator</item> </displayfeatures> <memoryfeatures locations="99" alphanumeric="true">

<item>Last Number Recall 20</item><item>Memory Scrolling</item><item>Secret Memory</item>

<callfeatures> <item>System Select automatic unknown</item><item>Call Restriction</item><item>4 MultipleNAM</item><item>One Touch Emergency Dialing</item><item>Speed Dialing</item><item>Caller ID</item>

<item>4 Ringer Alert Options</item><item>Silent Alert</item><item>Keypad Lock</item><item>Call Timer multiple true</item><item>Scratchpad</item><item>Mute</item><item>Text Paging</item>

</callfeatures> </memoryfeatures> </specifications>

</model></cellphone-catalog>

Style Sheet for Dynamic Transformation Example

This XSL stylesheet extracts the contents of each model-type element from the cell phone catalog, calls a reusable template called XDQL that issues the XDQL query to Documentum, and returns an XML DOM stream. The returning XML DOM stream can then be processed using the XSLT engine.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:java="http://xml.apache.org/xslt/java" version="1.0">

<xsl:output method="xml" indent="yes" media-type="text/xml"/>



<xsl:param name="DMS_SESSION_ID" select="’default value’"/>

<xsl:template match="*|/"><xsl:apply-templates/</xsl:template>

<xsl:template match="text()|@*"><xsl:value-of select="."/></xsl:template>

<xsl:template match="/"><xsl:apply-templates/></xsl:template>

<!—This rule matches an element called model-type

Model type -->

<xsl:template match="model-type"><xsl:apply-templates select="description"/>

<xsl:variable name="mydql" select="string(.)"/><xsl:variable name="myqueryresult"> <xsl:call-template name="XDQL">

<xsl:with-param name="dql" select="$mydql"/><xsl:with-param name="includecontent" select="true"/>

</xsl:call-template></xsl:variable>

<xsl:copy-of select="$myqueryresult"/>

</xsl:template>



<xsl:template match="*|@*|comment()|processing-instruction()|text()"> <xsl:copy><xsl:apply-templates select="*|@*|comment()| processing-instruction()|text()"/> </xsl:copy> </xsl:template>

<xsl:template name="XDQL"> <xsl:param name="dql"/>

<xsl:param name="roottag" select="string(’xdql’)"/> <xsl:param name="UpperTags" select="string(’false’)"/> <xsl:param name="includecontent"

select="string(’true’)"/> <xsl:param name="ContentasLink"

select="string(’false’)"/> <xsl:param name="ContentEncoding"

select="string(’dom’)"/> <xsl:param name="ContentTag"

select="string(’content’)"/> <xsl:param name="ContentFormat" select="string(’xml’)"/

> <xsl:param name="ErrorTag"

select="string(’XDQLError’)"/> <xsl:param name="LinkBase"/> <xsl:param name="MaxRows" select="10"/> <xsl:param name="Metadataasattributes" select="false"/> <xsl:param name="Repeatingasnested" select="false"/> <xsl:param name="Repeatingasnestedtag" select="-value"/

> <xsl:param name="Repeatingincludeindex" select="true"/> <xsl:param name="RowIDAttrName" select="ID"/> <xsl:param name="RowIDColumn" select="Object-ID"/> <xsl:param name="RowsetTag" select="Row"/> <xsl:param name="Stylesheet"/> <xsl:param name="VDNested" select="true"/> <xsl:param name="UseGivenCaseTagNames" select="true"/> <xsl:param name="UseNullAttrIndicator" select="false"/>

 <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="param1" select="java:setRootNode($xdql,$roottag)"/> <xsl:if test="contains($UpperTags,’true’)">

<xsl:variable name="param2" select="java:useUpperCaseTagNames($xdql)"/> </xsl:if> <xsl:choose> <xsl:when test="contains($includecontent,’true’)">

<xsl:variable name="param3" select="java:includeContent($xdql,true())"/> </xsl:when>

<xsl:otherwise><xsl:variable name="param3"

select="java:includeContent($xdql,true())"/></xsl:otherwise>

</xsl:choose> <xsl:choose> <xsl:when test="contains($ContentasLink,’true’)">

<xsl:variable name="param4" select="java:setContentAsLink($xdql,true())"/> </xsl:when> <xsl:otherwise>

<xsl:variable name="param" select="java:setContentAsLink($xdql,false())"/> </xsl:otherwise></xsl:choose>

<xsl:variable name="param" select="java:setContentEncoding($xdql,$ContentEncoding)"/> <xsl:variable name="param" select="java:setContentTag($xdql,$ContentTag)"/> <xsl:variable name="param" select="java:setContentFormat($xdql,$ContentFormat)"/> <xsl:variable name="param" select="java:setErrorTag($xdql,$ErrorTag)"/> <xsl:variable name="param" select="java:setLinkBase($xdql,$LinkBase)"/> <xsl:variable name="param" select="java:setMaxRows($xdql,$MaxRows)"/>

<xsl:choose><xsl:when test="contains($Metadataasattributes,’true’)">

<xsl:variable name="param" select="java:setMetaDataAsAttributes($xdql,true())"/></xsl:when><xsl:otherwise>



<xsl:variable name="param" select="java:setMetaDataAsAttributes($xdql,true())"/></xsl:otherwise></xsl:choose>

<xsl:choose><xsl:when test="contains($Repeatingasnested,’true’)">

<xsl:variable name="param" select="java:setRepeatingAsNested($xdql,true())"/> </xsl:when><xsl:otherwise>

<xsl:variable name="param" select="java:setRepeatingAsNested($xdql,false())"/> </xsl:otherwise></xsl:choose>

<xsl:variable name="param" select="java:setRepeatingAsNestedTag($xdql,$Repeatingasnestedtag)"/>

<xsl:choose>

<xsl:when test="contains($Repeatingincludeindex,’true’)">

<xsl:variable name="param" select="java:setRepeatingIncludeIndex($xdql,true())"/> </xsl:when> <xsl:otherwise>

<xsl:variable name="param" select="java:setRepeatingIncludeIndex($xdql,false())"/>

</xsl:otherwise> </xsl:choose> <xsl:variable name="param" select="java:setRowIDAttrName($xdql,$RowIDAttrName)"/> <xsl:variable name="param" select="java:setRowIDColumn($xdql,$RowIDColumn)"/> <xsl:variable name="param" select="java:setRowsetTag($xdql,$RowsetTag)"/>

<xsl:variable name="param" select="java:setStyleSheet($xdql,$Stylesheet)"/>

<xsl:choose> <xsl:when test="contains($VDNested,’true’)">

<xsl:variable name="param" select="java:setVirtualDocumentNested($xdql,true())"/> </xsl:when> <xsl:otherwise>

<xsl:variable name="param" select="java:setVirtualDocumentNested($xdql,false())"/>

</xsl:otherwise>

</xsl:choose> <xsl:choose>

<xsl:when test="contains($UseGivenCaseTagNames,’true’)"><xsl:variable name="param"

select="java:useGivenCaseTagNames($xdql)"/> </xsl:when><xsl:otherwise> </xsl:otherwise>

</xsl:choose> <xsl:choose>

<xsl:when test="contains($UseNullAttrIndicator,’true’)"><xsl:variable name="param"

select="java:useNullAttributeIndicator($xdql,true())"/> </xsl:when>

<xsl:otherwise> <xsl:variable name="param"

select="java:useNullAttributeIndicator($xdql,false())"/> </xsl:otherwise> </xsl:choose>



<xsl:variable name="execute" select="java:execute($xdql,’DF_READ_QUERY’,$DMS_SESSION_ID)"/> <xsl:variable name="queryresult" select ="java:getXMLDOM($xdql)"/>



<xsl:copy-of select="$queryresult//model"/>

</xsl:template>

</xsl:stylesheet>

Managing XML Content in Documentum Index-1

I N D E X

Aa_contain_desc attribute 1-8a_contain_type attribute 1-8ACLs

assigning 2-4, 2-13permissions to create 2-6

app_pattern element 2-8Application Support Documents folder

overview 1-5usage 1-7, 2-18

attributes. See metadata

Bbase64 encoded data 2-16binary rendition of configuration file 2-22business_policy element 2-14

Ccascading style sheets 2-18cellphone catalog sample document B-1child links 2-15chunking

ACLs, assigning 2-4, 2-13dctm attributes 2-17granularity 2-3lifecycles, attaching 2-14object name/owner, setting 2-13object type

choosing 2-4default 2-4setting 2-13

config.dtdconfiguration files and 1-4installing in 4.1 server A-1storage location 2-7

config.htm 1-4configuration files

Application Support Documents folder and 2-18

beginning entries 2-8binary rendition 2-22components 2-7config.dtd 2-7config.dtd and 1-4Default XML Application 1-7dm_xml_config object type 1-8map rules 2-9overview 1-4prolog 2-8root element 2-8storage location 2-13validation rules

data dictionary 2-5DTDs 2-5writing 2-9

variablesdeclaring 2-12scope 2-12

XML processing instruction 2-8containment objects, supporting attributes

1-8cross references

link rules for 2-15in XML documents 1-8

Ddata dictionary

permission to define 2-6validation against 2-5

dctm attributesdeclarations, format of 2-18purpose 2-17

dctm Namespace URI declaration 2-17dctm:obj_id attribute 2-18dctm:obj_status attribute 2-17

Index-2 Managing XML Content in Documentum

dctm:version_label attribute 2-18dctmattr element 2-14dctmattr_repeating element 2-14Default XML Application 1-7DefaultXMLapplication.xml file A-1DFC, transformation support 4-2DfTransformOperation class 4-2DfXMLQuery class

described 3-4error handling 3-8methods, list of 3-5

dm_xml_application object type 1-8dm_xml_config object type 1-8dm_xml_install.dql script A-1dm_xml_style_sheet object type 1-8Docbases

installing XML support in 4.1 A-1storing XML documents 2-5XML applications

creating 2-1described 1-2troubleshooting 2-22

document type definitions. See DTDs (Document Type Definitions)

documents, building dynamically 4-4Documentum Server 4.1, installing XML

A-1DQL (Document Query Language)

XML documents and 3-1DTDs (Document Type Definitions)

config.dtd 1-4dctm attribute declarations 2-17described 1-4, 2-17storage 2-19validating against 2-5

Eeditable_virtual_doc element attribute 2-12element attributes

editable_virtual_doc 2-12

export 2-11make_object 2-10

element_selection_pattern element 2-11elements

app_pattern 2-8business_policy 2-14dctmattr 2-14dctmattr_repeating 2-14element_selection_pattern 2-11entity_rule 2-16location 2-13make_entity 2-14metadata 2-14name 2-8non_xml_content_rule 2-16object_type 2-13owner_name 2-13root 1-6variables 2-12as zones 3-2

entity references 1-8entity rules 2-10, 2-16entity_rule element 2-16error handling, in DfXMLQuery class 3-8execute method 3-8export element attribute 2-11

FFOSIs

described 2-18dm_xml_style_sheet object type 1-8

full-text searchingXML documents 3-2zone files 3-3zones 1-9

GgetXMLDOM method 3-5getXMLDOM(node) method 3-5getXMLString method 3-5


getXMLString(Node) method 3-5

Iidentifiers 1-6IDfTransformOperation class 4-2includeContent method 3-7

JJava classes

DfTransformOperation 4-2DfXMLQuery 3-4IDfTransformOperation 4-2

Llifecycles

attaching to objects 2-14described 2-4

link rules 2-10, 2-14links, types of 2-14location element 2-13

Mmake_entity element 2-14make_object element attribute 2-10map rules 2-7, 2-9, 2-10

See also XML content rules; link rules; non-xml content rules; entity rules

metadatadata dictionary validation scope 2-6setting 2-5, 2-14

metadata element 2-14

Nname element 2-8namespace, root element 1-6non_xml_content_rule element 2-16non-xml content rules 2-10, 2-16

Oobject rules

ACLs, assigning 2-13Docbase location, specifying 2-13lifecycles, attaching 2-14metadata, setting 2-14object type/name/owner, setting 2-13usage 2-12

object typesdata dictionary validation scope 2-6dm_xml_application 1-8dm_xml_config 1-8dm_xml_style_sheet 1-8dmr_containment 1-8permissions to create 2-6

object_type element 2-13owner_name element 2-13

Pparsed entities, handling 2-16peer links 2-15processing instruction, configuration files

2-8prolog

defining in configuration files 2-8extracted information 1-6

public identifier 1-6

Rrelationships, for peer links 2-15repeating attributes, setting 2-14requirements for XML applications 2-2root element 1-6, 2-8root element namespace 1-6

Sschemas. See DTDs (Document Type

Definitions)setContentAsLink methods 3-7


setContentFormat method 3-7setContentTag method 3-7setDql method 3-8setErrorTag method 3-5setExportContent method 3-7setLinkBase method 3-7setMaxRows method 3-5setMetadataAsAttributes method 3-8setRepeatingAs NestedTag method 3-8setRepeatingAsNested method 3-8setRepeatingIncludeIndex method 3-7setRootNode method 3-6setRowIDAttrName method 3-6setRowIDColumn method 3-6setRowsetTag method 3-6setStyleSheet method 3-6setVirtualDocumentNested method 3-7storage locations, setting dynamically 2-5style sheets

dm_xml_styles_sheet object type 1-8example B-2outputing documents dynamically 4-4in XML applications 2-18XSL 4-1

system identifier 1-6

Ttransformation

defined 4-1DFC support 4-2example 4-2outputing documents dynamically 4-4

troubleshooting XML applications 2-22

UuseGivenCaseTagNames method 3-6useLowerCaseTagName method 3-6useNullAttributeIndicator method 3-6useUpperCaseTagNames method 3-6

Vvalidation rules

data dictionary 2-5in DTDs 2-5overview 2-7writing 2-9

variablesdeclaring 2-12scope 2-12

variables element 2-12

XXalan XSLT engine, supported options 4-2XDQL

described 3-4example of use in style sheet B-2introduced 1-9

XML application folderscreating/populating 2-19described 1-4dm_xml_application object type 1-8

XML applicationsApplication Support Documents folder

1-5, 1-7, 2-18checkout operations and 1-7choosing applicable 1-5components of 1-3configuration file 1-4creating 2-1Default XML Application 1-7described 1-2, 1-6DTDs and 2-17, 2-18export operations and 1-7installing in 4.1 server A-1object types, supporting 1-8requirements, determining 2-2troubleshooting 2-22view operations and 1-7XML application folder 1-4


XML configuration file. See configuration files

xml content ruleseditable_virtual_doc attribute 2-12element selection pattern 2-11export attribute 2-11make_entity element 2-14make_object attribute 2-10usage 2-9, 2-10variables

declaring 2-12scope 2-12

XML declarations 2-8XML documents

cellphone catalog example B-1checkout operations 1-7child link 2-15chunking

ACLs, assigning 2-4granularity 2-3object name/owner, setting 2-13object type, setting 2-4, 2-13object type, settingt 2-4

cross-references in 1-8data dictionary validation 2-5dctm attributes 2-17Default XML Application 1-7Docbase storage 2-5DTDs

described 1-4validating against 2-5

entity references 1-8export operations 1-7extracted information 1-6full-text searching 3-2lifecycles and 2-4metadata, setting 2-5parsed entities, handling 2-16peer links 2-15querying

with DQL 3-1

overview 1-9querying with XDQL 3-4support for 1-1, 1-7view operations 1-7as virtual documents 1-3well-formed requirement 2-16XML application

choosing 1-5processing with 1-6

zone files and 3-3XML processing instruction 2-8xml_link relationship 1-8, 2-15xmlns:dctm attribute 2-17XSL style sheets 4-1XSLT 4-2

Zzone files 3-3zone searching

examples 3-2introduced 1-9limitations 3-4zone files 3-3

Managing XML Content in Documentum - Dell EMC · Managing XML Content in Documentum 1–1 1...

Documents

Transcript of Managing XML Content in Documentum - Dell EMC · Managing XML Content in Documentum 1–1 1...