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

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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4121569
By: cyqotiq

I've already answered this question in the mailing list, but for the sake of
having the answer here in the future as well, I will re-post my answer.  This
was a very good set of questions, and the answers should be available for anyone
who needs this information in the future.

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 separate 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 modifiable 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
Management, 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 dependent 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 Management
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

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=645437