Essential Parts of a Content Management System (cont...)
* Select content. The repository must allow access and selection of content from within itself. The repository should offer fielded querying to find components with particular meta information associated with them, as well as full text querying against text in the system. In repositories with multiple databases it can be difficult to issue a search that queries all databases in a consistent way.
* Manage content. The repository must facilitate these management tasks:
o Security, including read and write access permissions for
components
o User maintenance that interfaces to system user
management resources
o Content statusing and tracking for staging publications,
workflow triggers, and maintenance operations
o Transaction logging and rollback of major changes in
individual databases or to the repository as a whole
o Bulk automated processes that run periodically against
subsets of the repository
o Input/output processes that load in and push out
information
The repository must be able to communicate over the network with a variety of clients. Ideally, the repository should be able to communicate with LAN-based Web browsers, Internet-based Web browsers, and LAN- or internet-based non-Web client applications. Internet connectivity to the repository enables authoring and other publishing process to take place from multiple locations, a frequent requirement for today's content-intensive Web sites.
Workflow
The workflow system is the tools, procedures, and staff that you employ to assure that the entire process of collection, storage, and publication runs effectively and efficiently, according to well-defined timelines and actions.
A workflow system supports the creation and management of business processes. In the context of a content management system, the workflow system sets and administers the chain of events around collecting, repositing, and publishing
To be successful, the workflow system should:
* Extend over the entire process. Every step of the process, from authoring through final deployment of each publication, should be able to be modeled and tracked within the same system.
* Represent all of the significant parts of the process including:
o Staff members
o Standard processes
o Standard tools and their functions
o Time and data flow with a variety of transitions and
charting representations
* Represent any number of small cycles within larger cycles, with some sort of drill down to the appropriate level of detail.
* Have a visual interface that shows cycles and players in the process graphically.
* Make meta information in the repository available. The workflow system should not have to store its own staff members, content types, outlines, and other meta information. It should be able to read the data that is stored in the repository, and make it available when appropriate in its dialogs and selection screens. For example, an editor might select a content type for an article in a workflow screen order to forward it to the next reviewer. The list of content type selections should come from the repository, not from the workflow system's own internal data store. As an alternative, the workflow's data store (which would need to be some sort of open database) could be considered part of the repository that is responsible for storing certain meta information.
* Provide a conduit to the repository for bottom up meta information. Whether or not the workflow system stores meta information, its screens will be a natural place for staff to enter meta information. Data such as author, status, and type are naturally entered in workflow screens. This data must be able to be transmitted into the repository from the workflow system.
