108 Computer

T H E P R O F E S S I O N

T he many collaboration and document-managementproducts available today helpestablish controls over docu-ment workflows. Essentially,

these applications automate informa-tion categorization, filing, versioncontrol, and historical tracking.

The advent of products that helpfind the necessary but long-forgottendocuments needed to complete a taskhas spurred demand for these applica-tions. Organizations with documentcollaboration requirements clearlybenefit from this technology. Com-puting professionals, in turn, play animportant role in identifying the mostappropriate technology for the collab-oration problem at hand.

Unfortunately, resources are notalways available to acquire the neededproduct. Document-management andcollaboration tools can be cost-prohibitive to many organizations. Thisdoes not bode well for resource-con-strained organizations that need someform of information management.However, computing professionals can

propose nonautomated solutions toaccommodate manual problems, suchas file-naming conventions and docu-ment versioning, through the appro-priate use of the technology at hand.Although automated tools are moreattractive and exciting, making suchacquisitions is not always feasible.

Organizations without processesand procedures in place for informa-tion management can end up withtheir documents scattered in a direc-tory kludge. A lack of structure forinformation management can make itdifficult to find relevant information.People do not always categorize theirinformation efficiently, which impedesfuture rediscovery. This is evident bythe inclusion of file system tools inmodern operating systems that letusers do keyword searches for docu-ments within their control.

Computing professionals can bringorder to file and directory chaos byproposing logical yet nontechnicalsolutions that meet the needs of a col-laboration group. A well-thought-outdirectory structure can also afford

security benefits that might have been missing in the prior informationconglomeration.

COLLABORATION DIRECTORY ALGORITHM

The collaborators can create thedirectory structure by recursively ask-ing a few questions, with the idea of cre-ating a structure of topics within topics.The highest point in the structure rep-resents the most general or abstract viewof a particular subject, while the bottomtopic offers the most granular view. Atopic within a topic is a subtopic. Thepseudocode in Figure 1 shows how tocreate the directory structure.

The pseudocode logic is straightfor-ward. First, create an initial topic. Next,identify any subtopics that might exist.Move to the first subtopic, if it exists,and ascertain more subtopics. Repeatthis process until the current topicreturns no immediate subtopics. In thiscase, create a directory within the cur-rent topic that includes the path/Year/Month/Draft, return to the imme-diate parent level, and move to the nextsubtopic if it exists.

The approach for creating the out-put, which appears in pseudocode,exemplifies the idea that a logicalprocess can help solve a manual prob-lem. It relies on properly identifying thesubtopics, which in turn requiresinvolving the collaboration of groupmembers with strong analytical abili-ties. With their combined expertise, thecollaborators can decompose theworkflow’s major components into ahierarchy structure. Primarily, they willneed to correctly determine if a givensubtopic best fits under the immediateparent topic. Computing professionalscan facilitate this process—manuallyor through organization policy—toachieve the desired results.

DEFINITIONS AND DIRECTORY TYPES

Names for topic and subtopic direc-tories should be kept as short as possi-ble. This makes it easier for users toquickly navigate or explore deep direc-tory trees. Acronyms well-known to

Supporting Resource-ConstrainedCollaborationEnvironmentsSean M. Price, Sentinel Consulting

Using an approach that incorporates a directory structurehelps collaborative group membersfind information while protectingtheir work’s integrity.

Continued on page 106

106 Computer

organizing information so that userscan easily locate and identify it.

NAMING CONVENTIONSCollaboration participants will likely

fill the roles of document (or infor-mation) owners and reviewers duringtheir tenure with the group. An owneris the principal author or topic owner,while reviewers are those who providecomments or approvals for draft andfinal documents.

Administrators implement the firsttwo of the three naming conventionsshown in Figure 2 to identify the rolesused for creating draft documents:document owners use Convention 1,reviewers use Convention 2. They useConvention 3 to name final docu-ments. No owner is associated withthe final document because it repre-sents the group’s collaborative efforts.

Each convention consists of uniquefields. The date and version fields areconcatenated; all others are delimited

the collaboration group will providethe most concise naming scheme.

In some cases, the directory structuremight exceed five or more levels. How-ever, a directory tree that is too deepbecomes more cumbersome to use.Deep directory structures should firstbe examined to validate their necessity.

Necessarily deep directory structuresshould be pruned to enhance usability.This involves taking a subtopic and itschildren to a higher level. Where theadministrators place that subtopicdepends on the logic the collaborationgroup’s expert members use to createthe tree. It might make sense to extracta subtopic and its children several layersdown and place it at the root topic level.This could require rewording the newlycreated topic so that users can easilyassociate it with the actual root topic.

Pruning reduces the tree’s depth butretains the structure’s logic so that theinformation is well organized. Theoverall strategy here involves logically

with the underscore character forreadability. Table 1 contains an expla-nation of the fields associated witheach convention.

The following rules express theimplementation for the conventions:

1. All documents within a directoryuse the same title-naming scheme.

2. In each case, the date selected isthe working document’s last date.

3. Collaboration participants neveralter other user documents ortitles.

4. Comments or changes subsequentto comments are recorded in acopy of the former document.

Upon completion and acceptance ofthe last draft, the owner will move acopy of the latest draft to the parentof the Draft directory. This copy willbe renamed using Convention 3 in thepreceding list. The title chosen shouldclosely match the document’s actualtitle. Keep in mind that shorter titlesare easier to read.

PUTTING IT IN ACTIONThe directory structure in Figure 3

shows how the framework and nam-ing conventions might be used. Thethree collaboration members in thisgroup, with their associated initials, areAlice (ALC), Bob (BOB), and Carol(CRL). ALC is the topic owner; BOBand CRL provide peer-review support.

As the following example shows,the collaboration group members canrecreate an action timeline based onthe naming conventions used:

• 1 July 2007: ALC creates a newdraft document with the short title“Fireworks.”

• 1 July 2007: BOB and CRL pro-vide comments to ALC in the formof new individual documents.

• 1 July 2007: ALC incorporates thereviewer comments, using the ver-sion letter “a” because it repre-sents the latest draft by ALC on 1 July.

• 3 July 2007: ALC further updatesand edits the work from 1 July. Theupdate warrants a new document

T H E P R O F E S S I O N

Continued from page 108

Initial_Topic( )MAKE Current_Directory with root topic nameCALL Create_Topic ( Current_Directory )

Create_Topic( Current_Directory )DOAdd a unique Subtopic

LOOP UNTIL no more Subtopics

IF no Subtopic exists THENMAKE Directory "Current_Directory / Year / Month / Draft"

ELSEFOR EACH SubtopicCALL Create_Topic ( Current_Directory / Subtopic )

NEXTEND IF

Figure 1. Pseudocode for a directory structure.The logic recursively creates subtopics

within other subtopics under an initial topic.

Convention 1: D_Short Title_YYMMDDV_OWN.extConvention 2: D_Short Title_YYMMDDV_OWN_REV.extConvention 3: Full Title_YYMMDD.ext

Figure 2. Naming conventions. Document owners use Convention 1, reviewers use

Convention 2, and both use Convention 3 to name final documents.

that is considered the last draftprior to final acceptance.

• 4 July 2007: The last draft docu-ment in the list is copied to the par-ent of the Draft folder and renamedusing Convention 3, indicating thatthis is the final approved version ofthe collaboration effort.

This approach’s elegance becomesclear once implemented. Most OS filesystems display the directory and itsfiles in alphabetical order. Using thisnaming convention guarantees that thelatest draft document will be the last inthe list. This makes it much easier forusers not only to see the chronologicalorder of the workflow but also toquickly find the latest draft documentthrough a concise directory structure.Further, only allowing final documentsto be kept in the same path as the asso-ciated Draft directory makes it easierto locate completed work.

ENHANCING SECURITYIn many collaborative situations

not controlled with specialized tools,all users will likely have equal rightsto the work in the mutually shareddirectories. This strategy makes it rel-atively simple for users to read andmodify work done by the group.However, this situation proves prob-lematic when malicious logic, such asa virus, begins modifying or destroy-ing the group’s work. This threat canbe countered with the proper use ofthe OS file system access control list(ACL).

The naming conventions presentedprovide an opportunity to leverage theOS access control mechanism toenhance security. We assume that thetarget system uses discretionary accesscontrol (DAC) for object management.Whenever users create a new docu-ment or a copy of an existing one, theybecome that new object’s owner.

Setting the ACL for the documentso that only the owner retains full con-trol and all others have read-onlyaccess provides an elevated assuranceof the integrity of information used in the collaboration. This inherentDAC mechanism can prevent acci-

dental or malicious insiders frommodifying or deleting files they do notown. Collaborators and systemadministrators must pay special atten-tion to policies in the host system thatmight attempt to propagate ACLentries from the directory to the newobject. This might result in a less thanadequate ACL implementation.

A read-only ACL entry for nonown-ers provides protection against mali-cious logic that might try to subvertthe system. For example, a virus mightbe able to delete or encrypt files. Ifthose involved follow the proposedACL strategy, only the files the infecteduser owns are at risk. Proper use ofACL mitigates the effect of maliciouscode on the other documents in thegroup because the user is limited toread-only access.

U sing the inherent capabilities of anOS file system can meet somecommon challenges that collabo-

ration groups encounter.

June 2007 107

Designing and implementing coher-ent file and directory structures willmake it easier for collaborating mem-bers to locate relevant files as well asthe latest version. Leveraging file sys-tem access-control capabilities willprevent unauthorized modifications towork the group’s members have devel-oped. A directory-structure approachnot only makes it easier for groupmembers to find relevant informationbut also helps protect their work’sintegrity. ■

Sean M. Price is an independent securityconsultant. Contact him at sean.price@sentinel-consulting.com.

Table 1. Document-naming-convention fields.

Field Explanation

D Represents a draft document Short title A very short title of the document; relevant acronyms preferred Full title A descriptive title of the document YY Last two digits of the current year MM Two digits for the current month DD Two digits for the current day V This is a version character starting with the letter “a” and incremented for succeeding

versions of an original within the same day. This aspect of the convention is used onlywhen multiple versions of a document are created on a given day.

OWN Initials of the topic owner or manager REV Initials of the document reviewer .ext Appropriate document extension

Events / 2007 / Draft / D_Fireworks_070701_ALC.extD_Fireworks_070701_ALC_BOB.extD_Fireworks_070701_ALC_CRL.extD_Fireworks_070701a_ALC.extD_Fireworks_070703_ALC.ext

Events / 2007 / Fire in the Sky_060704.ext

Figure 3. Directory structure.The three collaboration group members are Alice (ALC), Bob

(BOB), and Carol (CRL).

Editor: Neville Holmes, School of Computing, University of Tasmania;neville.holmes@utas.edu.au. Links tofurther material are at www.comp.utas.edu.au/users/nholmes/prfsn.