Managing XML Content in Documentum®

Version 4.2 May 2001

DOC3-XMLMGMT-0501

$ -"!"")  

Copyright © 2001 Documentum, Inc. 6801 Koll Center Parkway Pleasanton, CA 94566 All 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.

CONTENTS

Preface 1

Introduction Overview of Documentum XML Support . . . . . . . . . . XML Applications . . . . . . . . . . . . . . . . . . . . . . . . What Comprises an XML Application? . . . . . . . . . The XML Application Folder . . . . . . . . . . . . The XML Configuration File . . . . . . . . . . . . The DTD or Schema . . . . . . . . . . . . . . . . . Supporting Documents . . . . . . . . . . . . . . . How the Applicable XML Application is Determined. What Information is Extracted . . . . . . . . . . . How is the XML Application Used? . . . . . . . . . . The Default XML Application . . . . . . . . . . . . . . eContent Server Architectural Support for XML. . . . . . . The Object Types. . . . . . . . . . . . . . . . . . . . . . The Containment Object Type Attributes . . . . . . . . The xml_link Relationship Type . . . . . . . . . . . . . Querying XML Documents. . . . . . . . . . . . . . . . . . . Zone Searching . . . . . . . . . . . . . . . . . . . . XDQL . . . . . . . . . . . . . . . . . . . . . . . . .

2

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. 1-1 . 1-2 . 1-3 . 1-4 . 1-4 . 1-4 . 1-5 . 1-5 . 1-6 . 1-6 . 1-7 . 1-7 . 1-8 . 1-8 . 1-8 . 1-9 . 1-9 . 1-9

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. 2-1 . 2-2 . 2-2 . 2-3 . 2-4 . 2-4 . 2-4 . 2-5 . 2-5 . 2-5 . 2-5 . 2-6 . 2-7 . 2-7 . 2-8 . 2-9

Creating XML Applications Procedure Overview . . . . . . . . . . . . . . . . . . . . . The Preliminary Steps. . . . . . . . . . . . . . . . . . . . . Determining the Requirements . . . . . . . . . . . . Determining What Chunks to Create as Objects Which Object Types to Assign the New Objects Which ACL to Assign to Each New Object . . . Using a Lifecycle . . . . . . . . . . . . . . . . . . Determining the Storage Location . . . . . . . . Determining What Metadata to Set . . . . . . . Validating Against a DTD or Schema . . . . . . Validating Against the Data Dictionary . . . . . Creating the Underlying Architecture. . . . . . . . . Writing the Configuration File . . . . . . . . . . . . . . . . Basic Structure . . . . . . . . . . . . . . . . . . . . . . Defining the General Information . . . . . . . . . . . Writing Validation Rules . . . . . . . . . . . . . . . .

Managing XML Content in Documentum

. . . . . . . . . . . . . . . .

iii

Writing the Map Rules . . . . . . . . . . . . . . . . . XML Content Rules . . . . . . . . . . . . . . . . The make_object Attribute . . . . . . . . . Element Selection Pattern . . . . . . . . . Declaring Variables . . . . . . . . . . . . . Object Rules . . . . . . . . . . . . . . . . . The make_entity Element. . . . . . . . . . Link Rules . . . . . . . . . . . . . . . . . . . . . Non-XML Content Rules . . . . . . . . . . . . . Entity Rules . . . . . . . . . . . . . . . . . . . . Closing the Rules . . . . . . . . . . . . . . . . . . . . Writing the DTD . . . . . . . . . . . . . . . . . . . . . . . Creating the Supporting Documents . . . . . . . . . . . . Storing the Supporting Documents . . . . . . . . . . . . . Storing the DTD . . . . . . . . . . . . . . . . . . . . . Creating the Application Folders and Populating Them . Troubleshooting Your XML Application. . . . . . . . . . Distributing XML Applications as DocApps . . . . . . .

3

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. 2-9 .2-10 .2-10 .2-11 .2-12 .2-12 .2-14 .2-14 .2-16 .2-16 .2-16 .2-17 .2-18 .2-18 .2-19 .2-19 .2-22 .2-22

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3-1 3-1 3-2 3-3 3-4 3-4 3-5 3-8

What is Transformation?. . . . . . . . . . . . . . . . . . . What is XSLT?. . . . . . . . . . . . . . . . . . . . . . . . . Transformation Support in the DFC . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . Using Transformation to Dynamically Build Documents

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

4-1 4-2 4-2 4-2 4-4

Querying XML Documents Overview . . . . . . . . . . . Querying With DQL . . . . . Fulltext Searching . . . . Using a Zone File . Known Limitations . . . Querying with XDQL . . . . DfXMLQuery Methods. Errors . . . . . . . . . . .

4

A

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Transformation

Installing XML Functionality Required Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

iv

Managing XML Content in Documentum

B

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

Index

Managing XML Content in Documentum

v

vi

Managing XML Content in Documentum

PREFACE

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 Discusses how to query XML documents and content. XML Documents 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.

Managing XML Content in Documentum

vii

Chapter

Contents

Appendix B, Text of XML documents used in some examples in the Example Documents chapters.

Conventions This manual uses the following conventions: 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.

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.

viii

Click to follow the link.

Creatng Documentum XML Applications

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, open http://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.

Creating Documentum XML Applications

ix

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, open http://www.documentum.com/

2.

Click the Technical Support link.

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”).

x

➤

To view a document:

1.

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

2.

Click the Technical Support link.

3.

Log on to the Technical Support site.

4.

In the Resources section, click Documentation.

5.

Click the name of the document.

Creatng Documentum XML Applications

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) 6006666. You can pay with a purchase order, check, or credit card.

Creating Documentum XML Applications

xi

xii

Creatng Documentum XML Applications

Introduction

1 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.)

Managing XML Content in Documentum

1–1

Introduction XML Applications

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.

1–2

Managing XML Content in Documentum

Introduction XML Applications

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.

Creating Documentum XML Applications

1–3

Introduction XML Applications

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.

1–4

Managing XML Content in Documentum

Introduction XML Applications

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 (

The next line in the file is the prolog, which has the following format:

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:

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_root_element

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:

2–8

Managing XML Content in Documentum

Creating XML Applications Writing the Configuration File

application_name application_root_element

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:

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:

(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:

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.

Managing XML Content in Documentum

2–9

Creating XML Applications Writing the Configuration File

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.

2–10

Managing XML Content in Documentum

Creating XML Applications Writing the Configuration File

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: cellphone-catalog ... 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: model ...

and description ...

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.

Managing XML Content in Documentum

2–11

Creating XML Applications Writing the Configuration File

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:

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: modelName model.name Model Unspecified

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 () 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

2–12

Managing XML Content in Documentum

Creating XML Applications Writing the Configuration File

■ 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: Models/

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 and headings and specify a relative storage location for the chunks. Their storage location is created relative to the location specified for the 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: cell_phone_catalog_item

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.

Managing XML Content in Documentum

2–13

Creating XML Applications Writing the Configuration File

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: /System/Applications/CellPhoneSampleApp/ Cell_Phone_Lifecycle CellPhoneSampleApp Review

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: title -(model )-$

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.

2–14

Managing XML Content in Documentum

Creating XML Applications Writing the Configuration File

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: image href ImgName image Title Unspecified Images/ dm_document title

Managing XML Content in Documentum

2–15

Creating XML Applications Writing the Configuration File

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 nonXML content rule is started with the non_xml_content_rule element. Here is a simple example of this kind of rule: mybase64 crtext