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

Subject: Re: Help with XML Fwd: Re: [xml-doc] dynamic data dictionary
From: Judy Silvasi-Patchin <jspatchi -at- qualcomm -dot- com>
To: techwr-l -at- lists -dot- raycomm -dot- com
Date: Tue, 18 Jul 2000 09:53:16 -0700

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





Previous by Author: RE: funny behavior in HTML Help files... indented paragraphs?? -- THANKS!
Next by Author: DocBook is available for downloading
Previous by Thread: ADMIN: Ads again (was Re: TECH*COMM 2000 Middle East Survey)
Next by Thread: Help with job description, please..


What this post helpful? Share it with friends and colleagues:


Sponsored Ads