RE: DOM Implementation for realtional databases

Alexander Stiefel wrote:
> What do you think about an DOM implementation for relatiol
> databases, which
> maps the contens of a database to a DOM structure ? Is there a
> need for such
> a implementation ?

Lets have some background first. Many companies have Product Data Management
(PDM) systems that are usually based on relational databases. Sometimes they
just have a relational database that is used like a PDM system. Some systems
already handle the product documentation as well. It might be possible to
enhance an off-the-shelf PDM system. It certainly is possible to create
tools for plain databases.

I can give you an example that hopefully clarifies things. The situation may
have evolved a bit, but this is how it started: Wärtsilä NSD, the world's
largest manufacturer of diesel engines, had a relational database for
product data. Additional table and relationships were added to the database
to manage documents. The documents were in SGML, stored on a file system,
and the database stored references to the SGML files [1].

I enhanced our SGML browser Multidoc Pro (MDP) so that it could connect to
relational databases and show the information there as if it was a normal
SGML document [2]. The references to files were a special case, and for
those a HyTime link was created. The purpose of the MDP Database Publisher
was to make it easy to select documentation for a (possibly customized)
product. The SGML document that was generated from the database could look
something like:

-Wärtsilä Power Plant
   -Systems
      -Fuel System
         -Parts
            -Bolt X-5654 (Weight: 3 Length: 4)
               +Documents
            +Screw Z-97346 (...)
         -Documents
            -Corrective Maintenance Manual (SGML)
            -Systems Description (SGML)
            -Periodic Maintenance Manual (SGML)
      +Lube Oil System

By selecting the root node from the document I could generate the
documentation for the whole Power Plant. By Selecting the Bolt X-5654 I
could generate the documentation for that part only. I could also select the
root node but leave out parts I did not want. To be able to manually
select/drop nodes from complete products as described in the database, the
normal product data from the database was also included in the generated
document (the weight and length above).

This was done before XML and DOM. My approach mapped the database to SGML,
which was manipulated with a proprietary API. But I believe it could only be
simpler with the new Recommendations.


A related note: Databases that are designed to store SGML and XML documents
are often object oriented databases. They already must have some way of
accessing the documents in the database. I would be a bit surprised if the
vendors weren't preparing DOM interfaces as well.


So to answer your question... I think the (SGML/XML) document database
vendors will implement DOM or DOM-like interfaces to their products. I do
not see there is a need to build a DOM interface to a generic database.
There are some special cases where it might be usable, though, as in my
example above.


[1] http://www.citec.fi/company/services/case/wd_pp.html
[2] http://www.citec.fi/company/it/mdp/brief_db.html

--
  Heikki Toivonen
  http://www.doczilla.com
  http://www.citec.fi

Received on Thursday, 5 August 1999 04:57:28 UTC