Home | | Service Oriented Architecture | What are the Components of a Content-Management Workflow?

Chapter: XML and Web Services : Building XML-Based Applications : XML and Content Management

What are the Components of a Content-Management Workflow?

The components of a content-management workflow, or event sequence, for the Web are much like the components of traditional content-management workflow.

What Are the Components of a Content-Management Workflow?

The components of a content-management workflow, or event sequence, for the Web are much like the components of traditional content-management workflow. Typically components of Web content-management workflow include a content-input phase, a content-repository phase, and a content-delivery phase shown in Figure 13.1. Because the definition of content management differs based on the profile of the organization, its business goals, and the content it must manage, the components within each phase of any particular content-management workflow can vary as well.

 

Each component of content-management workflow has unique functionality and requires specialized tools. Content is entered into the workflow in the content-input phase, stored and maintained in the content-repository phase, and distributed in the content-delivery phase. The following subsections describe each component/phase of content-manage-ment workflow in greater detail.

Content-Input Phase

The content-input phase is the phase within the content-management workflow where content is introduced into the content-management system. Content input may come from one or more sources, as detailed in the following subsections.


Original Creation

 

Original content creation occurs when content is authored by the organization and imported into the content-management system. Such content can be created in a variety of formats. For example, original content could be authored in a word processing system, in a desktop publishing system, with an HTML authoring tool, or even with an SGML or XML authoring tool. Original content may also be entered into a Web content-manage-ment system through the use of database forms.

 

It is not critical that all original content created for the Web be created in a data standard format, such as all content being required to conform to a particular XML tag set. However, this does make delivery easier. If the intent is to dynamically assemble content for Web delivery, it is critical that content be created in a delivery-neutral format. Often, organizations prepare content for a particular product or delivery media, thus rendering it relatively unusable in a dynamic content-assembly environment.

Database Import

 

Although original content may be created directly in the content-management database system, often content comes from external databases within the same organization or from partner organizations. For example, content within an Enterprise Resource Planning (ERP) system may be valuable to import into a Web content-management system. Here, an import mechanism is a critical component of the Web content-management system.

 

Legacy Inclusion

 

Many times existing content is a critical ingredient for the Web. In this case, the content-management solution must account for the inclusion of the existing, or legacy, content. For example, a Web site for researching scientific journal articles requires the integration of past (legacy) journal articles with each new journal article that is published. A major issue is the data format of the legacy content and determining how that content can be integrated with “new” data on an ongoing basis. If the legacy data format cannot be eas-ily included and managed, data conversion into a more viable format must be considered.

 

Content-Repository Phase

 

The second component of Web content management is the content-repository phase. In this phase, content that has been input is stored and managed.

 

At the heart of every Web content-management system is some sort of database or mechanism for maintaining persistent Web content over time. End users require not only the ability to store Web content but to track how and why it has been changed and to be assured that they can access the most up-to-date version of the content. So, a content-management database often has other features that you will find detailed in the following subsections.

 

Storage

 

The basic function of any content repository is to store data. Different storage options are available. For example, the database may be an inverted index, relational, or object ori-ented. The data may be stored directly in the database, or the database may simply be responsible for storing pointers to the data within some sort of file-storage system.

Revision Control

 

Revision control is important when a body of content is divided into small, logical units that may be worked on by a pool of authors, perhaps on different projects altogether. Revision control, often known as check-out/check-in, provides the capability to track when the content was last updated, who updated it, and why. Revision-control systems often “lock” the content from being updated by a second author while the first author is making updates.

 

Version Control

 

Version control enables end users to access a complete body of content that is valid at either a point in time or by a defined version number. This differs from revision control because it freezes all logical units in a body of content into a single unit that is valid when considered as an entity.

 

Component Assembly

 

A final functionality of a content repository is the ability to automate the assembly con-tent components from the content repository for final delivery. In some cases, this is as simple as exporting the latest version of an entire document for delivery. In other cases, this is far more sophisticated. For example, component assembly may involve analysis of metadata associated with content assets to use as the basis for assembling content into a highly customized view of the content for Web delivery.

 

Content-Delivery Phase

 

Once the content has been assembled for delivery into a document or product, it must then be delivered. Content often comes to the final delivery in a variety of formats. Content that is stored in a Web content repository is fragmented into content objects that do not have a presentation interface for final delivery. Content may be stored as XML that is not intended to be viewed directly. Alternatively, content may be stored as records and fields of a database—again, not intended for direct viewing. Yet, in order to be pre-sented, a common interface between the content and the end user must be set in place. Typically, this involves employing transformation/rendering/presentation software.

 

If content is in a delivery-neutral format such as XML, presentation delivery should be relatively straightforward. In addition, the ability to manage and control the delivery of dynamic content to the Web is a growing component of the content-delivery phase. This implies the application of automated Web publishing processes.

Print Rendition

 

Even though we are concentrating on content management for the Web, many times print delivery is also a consideration. This requirement is validated by the print support found in the W3C XSL Recommendation (October 16, 2001). According to the W3C, “XSL stylesheets are used to express how source content should be styled, laid out, and pagi-nated onto a presentation medium such as a browser window, a pamphlet or a book.” XSL 1.0 provides for the formatting of paged media that can drive professional printing capabilities and functions from XML source documents. XSL 1.0 assumes that we want to be able to specify how to format and render XML content in order to produce versions for both Web and print media using a single style sheet language.

Web Rendition

 

Again, we need some sort of style sheet to produce output for the Web. Today, the most common Web delivery mechanisms transform content into HTML so it can be delivered to the broadest number of browsers. An alternative to HTML delivery, favored by those that want/need page image rendition, is PDF, or Adobe’s Portable Document Format, delivery for the Web.

 

WAP/Mobile Rendition

 

Accessibility of content anywhere, at any time, on any device is a trend in content deliv-ery. The importance of new lightweight delivery devices was a clear focus of W3C stan-dards development activity during 2000–2001. XHTML (a well-formed, modular, XML version of HTML), along with the Wireless Markup Language (WML) has emerged as delivery choices for Wireless Application Protocol (WAP) and mobile devices. Cascading Style Sheets (CSS) now comes with a new Mobile Profile that specifically tailors style sheet properties and values for mobile devices such as wireless phones.

 

In the page-rendition environment, tagged PDF technology now makes the automated resizing and reflowing of PDF page images for WAP/mobile devices a reality.

 

Content Syndication

 

The classic definition of syndication is the delivery of a single body of content to multi-ple end users, or subscribers. It began in the earliest days of the newspaper business when news services distributed news stories to multiple local newspapers. Today, Web-based content aggregation and content syndication make a compelling value proposition for content consumers and for content suppliers alike. XML-enabled syndication mecha-nisms address the need to automate reliable redistribution for both commercial and non-commercial content.


Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
XML and Web Services : Building XML-Based Applications : XML and Content Management : What are the Components of a Content-Management Workflow? |


Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.