RE: [docbook-apps] Database for docbook components (i.e. section, para, etc) questions

["Nelson, Dean" <dean.nelson@eecradar.com>]

Thanks for your input Adam!

We are using a Subversion repository, but it mainly stores our most
current documentation tree (though we could revive older versions). It
also serves as our secure server to check in/out modules. Plus the
oXygen editor works with SVN.

This has worked well for us because we have not "shared" the XML files
with others. Now we are needing to do more config management on the
data.

Regards,

Dean Nelson   
Enterprise Electronics Corp




-----Original Message-----
From: Adam Constabaris [mailto:adamc@unc.edu] 
Sent: Tuesday, March 13, 2007 2:34 PM
To: docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] Database for docbook components (i.e.
section, para, etc) questions


Nelson, Dean wrote:

> All
> We have been generating much of our DocBook XML content over the last 
> year and the few files we started out with have been "fruitful and 
> multiplied". Now we have a large bunch of XML files that is starting 
> to get unweildly in number and we would like to start putting this 
> info under configuration control.
>  
> I would like to hear how others have solved this problem. Do you have 
> a database that stores these XML items or do you just use a structured

> file tree? Can the Docbook tools work with a database? I could not 
> find anything in Stayton's or Walsh's books on this topic but I 
> suspect that someone has ran into this issue and has a solution.

In my organization, we started off by storing all our DocBook documents 
in database tables.  After a few years and growing to a few thousand 
documents, we're moving towards a Subversion-backed filesystem approach.

  The main reason for the move is to make it easier to use various parts

of the "standard" DocBook toolchain, which are at home on the 
filesystem.  Being able to use a version control system for the content 
is an added bonus.

A major source of pain with database storage is URI resolution; for 
example, how does one use olinks among documents stored in a database? 
It's not impossible, but you have to create, plug in, and maintain a 
custom URI resolution mechanism.

A related issue is that the database mediates all access to the 
documents, which can cause all sorts of frustrations, especially when 
you're trying to comprehend the collection in some way the database 
doesn't support.  I've often wanted to run grep over our collection, or 
write a script that replaces the name of an organization wherever it 
occurs, or see how the latest version of the stylesheets handles a 
certain batch of documents.

Depending on your needs and the RDBMSs you're considering, some of these

problems we've seen may not loom as large for you.  Many database 
vendors are adding XQuery support, tag-aware fulltext search, and other 
such Useful Features, and it might be possible to meet whatever 
scripting or collection comprehension needs you have through such tools.

    However, this makes you dependent on your database vendor for 
upgrades and enhancements and puts up barriers to tools that your vendor

doesn't support.  It's far more likely that some nifty new tool to 
organize, categorize, or visualize your collection will work "out of the

box" on a filesystem than it will with a database.


Anyhow, that's this person's perspective ... hope it helps.

AC


---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org