Tips: Invasion of the Virtual Documents

So, I have two topics that are burning for another post, but I had something fresh, and wanted to post on this topic while I still had my thoughts in a semi-coherent collection. Recently, I have run into more designs utilizing Virtual Documents than I had, quite possibly, ever. Your first thought may be that I have been working on similar projects. Wrong! Of these systems, I have seen one where Virtual Documents was called for, and the rest where I just wanted to shoot the designer. Well, once I just laughed because I couldn’t believe my eyes and didn’t have to fix it.

Now, I don’t know if maybe I happen to be in the wake of a rogue Documentum “Architect”. I use that term loosely because that is a term being bandied about more and more frequently. There are very few that I consider Documentum Architects, fewer that are ECM Architects, and none of them, including myself, are Enterprise Architects. However, that is a post for another day.

Regardless of the cause of my problems, I want to take a moment to clarify something that I learned back in Technical Fundamentals years ago, and that hasn’t changed. Virtual documents are a way to combine documents whose contents have a variety of formats into one document. That is a quote from the 5.3 Content Server Fundamentals. What does this mean? Here is a simple example. Say I am working for a Government Agency. When I produce the massive volumes of documentation for any project, I invariably have the same project overview and set of appendices in most of my documents. Some subsets of the documentation may share more content. A Virtual Document allows me to link all of the documents together, assemble them, and publish them as one document. So when I publish all of my documentation, I can be sure that my common resources match. When I update one, I update all.

Now there are several XML processing applications of Virtual Documents as well. However, Virtual Documents are not for grouping a set of files together, just to group them. Something I have seen (modified to protect the innocent) is using Virtual Documents for Case Management. In a case, you have source documents, reference documents, and output documents. That is an oversimplification, but it’ll serve here. What I have been seeing is making those all part of the same Virtual Document! DON’T DO THAT!!! If documents are related, you have at LEAST three easy choices:

  1. Put everything into a folder. Hmmmm. I kept the original files in a folder on a desk, why not a folder in my ECM system? I can even store Case information on the folder.
  2. Tag all the documents with a piece of metadata, like, oh I don’t know, a Case Number. Then you use a quick search to retrieve every related piece of Case content with a simple search. In D6, Documentum is taking this further in their Taskspace interface and not showing folders at all, but using “Smart Folders”. Smart Folders are just simple, saved searches based on some indexed value.
  3. Define a relationship within Documentum. Documentum already uses relationships for several functions including Annotations. You could define a custom relationship and implement it. This requires a little more work than the other two options, but there are times that it would prove more efficient.

There is more than one way to skin a cat and there is more than one way to design most systems. However, Virtual Documents are not to be used lightly. There are a lot of complications that can arise in everyday use of Virtual Documents. For instance adding or removing content from a Virtual Document requires checking the parent document in and the out. There are times where they are called for, but they should be clearly thought out before implementing.

2 thoughts on “Tips: Invasion of the Virtual Documents

  1. Torgo says:

    I’m in a situation where I have lots of time to plan out the document structure, but not sure of the best way to go about it after reading this tip. I was leaning towards Virtual Documents but perhaps metadata would be better.

    This situation would be very similar to a Human Resource collection of documents all relating to individuals. The data would be resumes, reviews, credentials and training records. This would seem to be a perfect situation where you could combine the variety of documents and make a single virtual document that is one “person”.

    Now I’m thinking that a metafield containing “Bob Smith” for each type of document could do the same thing. At this point, I’m seeing several possibilities of going about this, which brings up several questions.

    Virtual Documents from a end-user standpoint makes the most sense, for grouping, viewing and exporting a “person”, but at what point do we need to factor server performance? Metadata would seem best for server performance, but then using Search becomes extremely critical to find a complete “person”. Relationships are intriguing (I currently use them for redlining PDF files), but do they really make sense to the end-user? Can the end-user quickly find the information needed using relationships?


  2. There, as always, are a couple of approaches you could take. Remember, while drag-and-drop works with Virtual Documents, straight imports do not.

    This is similar to a project I am on now. We have files for people. However, the system mostly contains of scanned images. Yours could be dynamic, another reason not to like Virtual Documents.

    Think of it in this way. Are the users going to print the whole thing as one document, or individually? If they were all printed out, would they be stapled together or individually collected into a folder?

    It all boils down to what you, and the users, are comfortable with. You can have a folder, even a custom folder with metadata, that houses basic information on each individual. The documents reside in the folder. Each document could have a meta-data tag that records an identifier for the person. You could also make it part of the name if they are going to search and get back lots of similar documents from different people.

    The most interesting approach would be to have the documents in a folder, and have the meta-data for the person folder be automatically set>/i> by the containing folder upon import.

    As for exporting a folder, you can do that through Webtop. You can use the Deep Folder Export component from the Developer Network.

    To help the end-user, create a pretty icon for the Person Folder. Little things like that go a long way.


Comments are closed.