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

[Rodrigo Moya <rodrigo linuxave net>]

> 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 ?
>
yes, this should also be supported in the DTD, although I'm not sure
about how to represent it. What you propose is really needed in our DTD,
since we must support every kind of object supported by any DBMS.

> 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>
>
yes, definetely this should be the format. And in DBMS not supporting
schemas, they can just ignore the <schema> tag.

I'll make an initial DTD during the weekend, and then we'll comment on
it. Although David, you can prepare one proposal as well if you want.
Although, as I said in a previous mail, I would start just defining the
stuff for the TABLES (and maybe VIEWS) and then we'll extend it, all
right?

> 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?
>
well, quite interesting what you're saying, but, firstly, I don't have
myself contacts to do so, and, most importantly, gnome-db is not yet in
a state where we can say it's the premier open source interface. I'd
love to say so, but let's be realistic, there are many things to do
before that, although, as I hope, with all the help we're getting in the
last weeks, I'm sure we'll get into that state. So, let's keep your idea
in the TODO list, and, as soon as we all agree that gnome-db is really
really awesome, we'll do what you're proposing. Although, if somebody
has the contacts and wants to start doing so, I won't protest!

cheers