DTD: Possible missing attributes/entities - Was: revised gda-xml-query.dtd

["David T. Bath" <bathd edipost auspost com au>]

Sorry if this is old ground, but I'm new to the list.
Various wrote:
> > My idea about the DATABASE DTD is to include on it information about all
> > the objects contained in a database, so that you can use it to
> > import/export data as well as to design a database in the db designer
> > and then create it for a given DBMS. An example of this:
> >
> > <DATABASE>
> >   <TABLE NAME="table1" OWNER="me">
(snip)
> >   </TABLE>
> > </DATABASE>
What about the case where a table is NOT accessible directly,
but is indirectly accessible via the database you are connecting
to ?
I am thinking in particular of dblinks in Oracle.
Perhaps an extra table attribute is warranted ?
      <TABLE NAME="table1" OWNER="me" INDIRECT="dblinkname">
Or is the dblink an entity under the database that itself
has tables?
     <DATABASE>
        <DBLINK NAME="dblinkname" TYPE="indirect" OWNER="me">
           <TABLE.....
        </DBLINK>
        <DBLINK TYPE="direct" OWNER="me">
           <TABLE.....
        </DBLINK>
     </DATABASE>
Note that the direct link might be best left "anonymous".
Alternatively, given that most objects live inside a
schema, perhaps the schema should be the higher entity,
and the tables living under it:
    <database>
       <schema name="Fred">
          <object type="table" name="ABC">
             ...
          </object>
       </schema>
       <schema name="MARY">
          ...
       </schema>
    </schema>
Here we have a problem, and that is the namespace of objects
inside database engines.  The namespaces of various object
types vary between engine to engine.  THEN you have the
problem of public and private synonyms.

Another problem is that different engines will have different
concepts as to users such as Oracle's PUBLIC, which is not
really a user at all.

Musings:
   Now that OpenSource is starting to be taken seriously
   among the great unwashed masses, the competitive edge
   between dbvendors may well be not just whether their
   engine does x and somebody else's engine does not,
   but whether x can be used through the premier open
   source interfaces.

   If this assumption is correct, then it might be worthwhile
   running the plans through the occasional friendly techie
   working for a vendor (hey you!) to get feedback as to
   whether their features are properly supported by our
   DTD.  It may even be worth their while donating time
   and expertise to the gda-provider for their engine, so
   it gets up and running sweetly as soon as possible.

   Imagine if you are the integrator for a company
   deciding between dbvendor A and B, knowing the
   gda-A-srv is problem free, while gda-B-srv is
   very beta.  (Similar issues crop up with the DBI::DBD
   layers of perl - and maybe Tim Bunce might be contacted
   for his wisdom).  It's a no-brainer what you are
   going to choose even if B has a few bells and
   whistles that A does not have.

   Basically, if you are a technie from a dbvendor lurking
   here, tell your manager that gda is the ODBC that won't
   screw you around.  Just as dbvendors take responsibility
   for developing free ODBC drivers, (and accept the hassle
   when the ODBC spec gets moved by its owner), its time
   they took some responsibility for gda (and DBI::DBD)
   development.  Its in their own interests to contribute.

   Does anyone here have the contacts to push this idea
   with your closest vendor?
-- 
David T. Bath bathd@edipost.auspost.com.au
+613 9204 8713 (W) 0418 316 634 (Mbl)