Once everyone has gone through the arduous task of chunking and labeling their legacy content, this content needs to be put into a repository where it can be easily accessed. The best way to do this, for instructional designers, is to put the content into a version control system that is linked to a database. ClearCase, for example, can present several different views of the repository for different uses. One view presents a virtual file server that contains all the most recent versions of the training documents. Another view presents selected documents to a web server or Learning Management System. Yet another view presents the XML database elements.
Other views can be created for specific uses, such as creating archives of content, presenting catalogs of approved artwork or source content for other servers such as Adobe Document Server or FramMaker Server.
The first task of the repository is to facilitate collaboration between content creators, editors and production staff. One mistake that is often made with a complex repository is to make customized views that are not shared between different team members. This can be frustrating and time consuming.
The road to XML Content Reuse is a simple progression of responses faced by learning organizations. The following table summarizes some of the objectives and limitations of each step in the progression:
Step | Objective | Limitation |
File Server | To permit access and sharing of files between many users | Slow, Insecure and does not scale well |
Version Control System | To maintain different versions of the same document so that the newest (best) can be identified | Complex to maintain and difficult to use when additional features are added |
Doc Manager | To automate higher features | Proprietary - does not keep pace with new tools and processes |
LMS | To improve the efficiency of training content delivery and progress tracking | Presents limitations to IDs in terms of format or delivery methods. |
LCMS | To improve the efficiency of training development through content management and reuse | Poor user interface - extensive customization required |
XML Repository | To provide content reuse, multiple output formats and extensibility to react to changing needs | Users resist new work methods and process |
When computer networks became common in the workplace, people abandoned the file cabinet for the file server. They soon learned that file servers have their own collection of defects when it comes to sharing important information. The next logical step was to try to remove the most glaring defects of the file server by implementing a version control system. The version control system made it easier to find things, but when you have enough things, it gets harder again. Enter the document manager, which makes it simpler to find things, but which usually required that you use outmoded tools and processes.
Learning Management Systems are student facing applications, primarily, and although more and more content management facets have been sneaking into these learning delivery platforms, that is not their core function. The LCMS is a vendor's best attempt to provide for your needs before they knew what those needs were. The biggest drawback of the typical LCMS is that it locks you into tolls and processes which compromise its own efficiency.
Once you have an XML repository, your repository can inter-operate with other systems, such as LMS or even LCMS, but the content is organized for your exclusive needs and convenience. If your needs or tools change, so can the repository. Why doesn't anyone market an XML repository as an LCMS? Because LCMS vendors sell you purposefully proprietary systems. The architecture of their product is intended to keep you from being able to use any part of the investment you made in the LCMS if you happen to part company with that vendor in the future. Unless you are intending to market the XML repository you make for your organization, you have no reason to follow their example. For that reason, the XML repository is more direct and less difficult to upgrade.
XML and SGML were developed specifically to provide a structure and methodology for content reuse. Many of the lessons learned from early SGML implementations were built into XML, which provides a more streamlined and less labor intensive means of achieving high quality content reuse.
Before legacy content is parsed into XML, it exists in many different forms. Most of these forms represent document instances. Most organizations attempt to maintain a repository of these document instances according to some meaningful hierarchy. ISO documentation standards are an example of this kind of document-centric hierarchy. If documents are correctly named, stored and updated, then the information they contain can be reused, but the process is slow, laborious and prone to failure. The utility of simple file sharing is inversely proportional to the number of documents to be shared.
When content is chunked, it is broken into topics and then broken again into smaller pieces identified as introduction, main body and transitions. We like to have content sound natural and appear to have been written specifically for each use. Content is also chunked by complexity so that more complex material can be added or removed easily.
Audience also plays a big role in content reuse. Identifying specific blocks of information as appropriate or inappropriate for different audiences can simplify document creation immensely. It is also the hardest classification to accomplish.
For example, an offer brief: it is going to have the same look and feel, auxiliary content and illustrations as fifty others, but the new one will be different in 3 main content blocks. The task is now to find the 4-5 other offer briefs that contain almost the same information. You could do a keyword or phrase search, but that would take a long time and produce indiscriminate results. With a properly constituted XML repository, the process is much more like playing 20 questions, only in this case is more like 10 questions (or less).
The only taxonomy that should not be used to chunk content are attributes of the content that change rapidly over time, such as department, owner or other descriptor that is irrelevant to the learning objectives.