Doc Smith

Doc Smith is being created as a specialized document manager.  It will store documents as an organized collection of subdocuments. 

The subdocuments will be stored in a database.  The subdocuments will have customizable fields and user-defined tags. The subdocuments can be queried and selected based on the field values, tags, and text content.  The queries will pull subdocuments into new documents. The new documents will be editiable and the changes will be reflected in the original document.

This style of document generation will produce customizable reporting of complex documents and large groupings of documents.

For example, let's say we put the full specifications for the next generation of space shuttle into Doc Smith.  Users will be able to search for subdocs containing the phrase "12mm nut."  The search will produce a document listing all of the text containing the phrase "12mm nut."  Perhaps such a query would produce about 2,000 such subdocs. The user will then be able to review all of those subdocs and edit them in an editor, perhaps changing 12 of the specifications to "13mm nut" using a search-and-replace operation, just like with a word processor such as MS Word or OpenOffice, and then update the modified documents with a single update command. 

All 12 subdocs would be updated with an identifier indicating who made the change, and if appropriate, who approved the change.  The time and date of the change would be recorded for each subdoc. 

Doc Smith will provide full version control, using Subversion as a model for how to do updating.

The style of subdocument management is intended to support the updating of large document collections. It should support specification documentation, such as requirements traceability, as well as the management of large software code bases, and extremely large and inhumanly complex document collections such as the US Tax Codes.

The requirements are stored in Google Docs as

<https://spreadsheets.google.com/ccc?key=0Atwg-jGkw4rwcjdkNHJ2WGFreWN4d1F5clp0NE5ZMkE&hl=en>

Recent changes:

June 28, 2010 - Changed the requirements spreadsheet to read "Doc Smith" instead of "Maria."

- Changed the project name from "Maria" to "Doc Smith" to prevent confusion with MySQL's "Maria" back-end.

- Modified the Java code to reflect the new project name.

Short-term To-Do list:

- Add Javadoc comments to all modules.  Only one or two modules have proper Javadoc documentation so far.

- Create an interface to the database interaction modules.  I want to make the software run on a variety of different databases, so the database operations need to have different code sets for the different databases.

Issues:

- jUnit seems to have a problem doing unit testing.  It doesn't allow a jUnit test class to extend a class being tested.  This causes a problem with writing tests on internal private methods.  How do you test a method you have no visibilty to?  It looks to me like all the classes and methods need to be made public so jUnit 4 can test them.  I need to research this because I don't understand it.