Re: Help with XML Fwd: Re: [xml-doc] dynamic data dictionary

[Judy Silvasi-Patchin <jspatchi -at- qualcomm -dot- com>]

Marie,

This is not the only list with people asking questions about dynamic data 
dictionaries.
Below your post is another question and the answer I sent.  You might want 
to join the list.
 xml-doc -at- egroups -dot- com

I wrote before about needing help with a data dictionary and I got a lot of
responses, but they were all from people saying "God, if you find something
to help, please tell us."  So, it looks like many of us are in the same
boat.

Has anyone out there tried to manage documentation so that source text is
stored in one place and linked in where it's needed?  We figure, if we're
using a web browser as the front end, and the data dictionary text is in a
very fixed, standard format, XML is a natural.  But do we have to build a
back-end data entry piece from scratch?  And what about managing the
front-end display?  And can you have XML entries that contain links pointing
to other XML entries?

Any tales of managing document creation this way is very welcome (and not
just by me).  Any tales of managing documentation this way for the web is
very, very welcome.  And if XML is involved, I owe you drinks.

Thanks,
Marie

At 02:49 PM 7/12/00, you wrote:
>Hi all,
>
>I'm looking for suggestions...
>
>We are in the process of creating a dynamic, online data dictionary to
>describe a large financial database. This documentation has to be dynamic,
>in the sense that different classes of users have different requirements, so
>the same topic will have to be presented in a couple of different ways. For
>example, a developer may need to see different information than a financial
>analyst.

Depending on what language the developers used, and how well they
documented their code, you may be able to use scripts to pull documentation
out of the code and deposit it into a database.


>We want only one central store of data, and the system should be
>flexible enough to be able to assemble and present different chunks of data
>depending on (well-defined) circumstances.

You are talking about a document repository that will store your data in
XML and   create "documents" - web pages etc on the fly according to your
business rules.  These repositories are not cheap to buy or to build.  In a
quick and dirty survey of 5 repository vendors, the average time to build a
basic repository that can parse documents to xml and output new documents
according to your business rules is about 2 1/2 years.  Nor is it "cheap"
to update your dictionary manually when you add the cost of additional
personnel that you will need to continue servicing your customers and
support this additional service.

My advice is to determine your requirements for the system and set up a
good business case for bringing in a system.  The folks who implement
systems like yours are telling me that they recoup their initial outlay in
less than a year. If the system was very complicated break even was less
than two years.

Good Luck
Judy Silvasi-Patchin