Re: [Publex-developers] [publex - Developers] database

[PubleX Developer's M. L. <pub...@li...>]

Actually, you just about hit the mark on everything.  The process can really
get detailed when you begin describing the precise activities for each
person in the documentation process.  But I've managed to narrow this down
to a necessary three positions.

Optionally, when PubleX is installed, it may be installed as a stand-alone
(single-user) module, which will use local anonymous DB access.  It may also
be installed in a group (multi-user) module, where it will require that a
server component be pre-installed on a remote machine (or possibly running
locally over a virtual machine or some type of VPN.  The details of how this
will work are still shady right now.  The idea is that PubleX may be used to
modify a documentation project on a single computer - DB is local - or over
a network with multiple clients - DB is managed on a server with write
access restricted to just that service.

All SQL input/output methods will need to be placed within
PubleX.Core.DB(in the PubleXCore project) as classes or interfaces
that may be exposed by
a server component (a seperate EXE project) or by a 'Virtual Server" for
stand-alone mode.  As far as PubleX itself is concerned, the DB requests
should all be the same, regardless of which model is being used.  The
protocol being used (local direct or remote TCP) will be set in the
configuration during installation, and will be modifyable during runtime by
the user.  This is to allow a single-user mode to be "switched" into a
client mode.

The three positions I mentioned are as follows:  Publication Control,
Project Mangement, and Project Editor.  It is possible for all three of
these to be the same person, but it's really not recommended.

Publication Control - This position is responsible for assigning tasks to
users, tracking the document locations and status, and gathering the files
to send on to another station.  This is where the DB interface for end-users
will be used.  I'll get into the stations a little later.

Project Management - This position is responsible for deciding guide lines
for documents, which documents go with which projects (or chapters), and
which documents are a higher priority than the others.

Project Editor - This is our primary end-user.  This person actually edits
the files.  There will be user levels within this group, but what those user
levels are and what they can do will be dependant on what the Project Manger
decides.  For example, with a technical manual, a certain chapter might be
designated as "expert" while another might be designated as 'general'.  A
level 1 user (lowest level) would only be allowed to work on general
documents, while a level 3 (highest level) would be allowed to work on any
documents.  Of course, there might be more than just 3 levels.  That depends
on what the Manger decides.

Stations are the various "check-points" of a document's life.  When the
project is first created, the Project Manger sets up all the technical
details (assigning documents to chapters, giving the priority for the
documents, and getting the basic database ready for use).  At this point,
the documents are put into play.  Editors may check them out.  Ideally, the
Project Control will be able to assign documents to different editors based
on which editors are available for editing and what the user levels for the
editors are compared to the status of the document.  The editor checks the
files out for editing, at which point the file is copied to their machine
into a local directory.  The database will then mark that file as being
"unavailable".

When the editor is finished, he will check the file back in, moving his
local data back to the server's repository.  The database is updated with
the new status of the documents and a snapshot of old data is made when the
old data is archived.  Once all of the edits have been made - this requires
several checking in and checking out of the files - and the document is
ready for delivery, the Publication Control station will gather all of the
documents that pertain to a delivery package - this might be a single
chapter, or an entire book.  This package is then sent out to whoever is
receiving the delivery.

Additional stations might be included within this process.  It would make
things much more difficult to track, but the more we can readily track with
the database, the better our program will be.  Configuration Management
members would then be used to communicate between various stations.
Configuration Management and Publication Control might be the same station.
This would probably only be used if there were a station for a Technical
Editor (someone to correct technical errors and grammar) and/or a Subject
Matter Expert to correct the subject matter and make "redline" changes for
outdated or incorrect data.

In order to fully support all of these stations, PubleX would need to
support displaying the XML documents as if it were a PDF or a print
preview.  Then provide tools for both technical editors and SME stations to
make corrections (annotations).  These corrections would be sent back to the
Publication Control with the document, and the Project Editor would update
the documents with these changes.

There are a lot of variables in all of this, and there is no way we could
provide an interface and tools for every possible station.  But if we can
meet the main three stations (Pubs Control for assigning editors their work,
Project Mangement for running administrative tasks on the project, and
Editors for editing the documents), then we will be fine.  Eventually, I
would like to also support handling an additional station for Configuration
Management, SME, and Technical Editor.  But that might very well be version
3 or 4. :)

>From this basic overview - and that's all this is... an overview - you can
probably get an idea of what the database would be used for.  If you have
any ideas or suggestions, I'm open to hear them.  If you have any questions,
let me know.

Jason