As I understand it, XML:DB serves two key functions. One is to build a spec,
the other is to help create the market for XML databases. The second
objective won't be met until there are practical and usable drivers
available to build apps. So, I am in agreement with Kimbro and Ronald that
there should be focus on building usable drivers without loosing sight of
the first objective, building a solid and scalable spec.

__________________________
Jason Barney
[EMAIL PROTECTED]
__________________________

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Ronald Bourret
> Sent: Tuesday, April 17, 2001 9:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: How should the API develop
>
>
> Kimbro Staken wrote:
>
> > The reason I'm asking is because there has been very little activity
> > based on the last draft that was posted. I expected that to at least
> > spark some comment or maybe even cries of outrage but it has been very
> > quiet instead.
>
> Sorry about that -- nothing is worse than complete silence.
>
> I'm usually so busy that I only have time for localized bursts of
> activity on XML:DB. I've only had time to glance at the latest draft,
> but it looked reasonable to me. I'll try to look closely later this
> week.
>
> > I'll state the current goal of the API is to provide the ability to
> > build applications that can move easily from one vendors product to
> > another.
>
> Exactly.
>
> > Now times have changed a lot since both ODBC and JDBC were developed and
> > Open Source has become a very viable way of developing software to
> > achieve the same goal. An example of this would be Perl DBI and SAX.
>
> Actually, both SAX and ODBC were developed in the same way XML:DB was
> developed: iterative work on the spec and implementations by a number of
> different vendors, until enough experience was gained to label the spec
> 1.0.
>
> > So
> > what I wanted to throw out was the question of would it be of more value
> > to us to focus more on implementation and less on specification?
>
> I think so. If we get several different implementations over several
> different databases, it should ferret out any problems.
>
> > What I
> > mean is should the output of this project be not only a driver manager
> > and specification but also the drivers? One stated goal of XML:DB is to
> > develop specs and reference implementations of those specs so this isn't
> > inconsistent.
>
> I don't think the project itself needs to be a delivery vehicle for
> drivers. I think it just needs to deliver the spec and any common code,
> such as the driver managers in JDBC or ODBC. However, I do think that
> drivers need to be written. A spec without implementations to prove it
> is not useful.
>
> > We're so early in the XML database game and everyone's implementations
> > are so immature and so different that a comprehensive spec is going to
> > be very difficult to develop. Basically I'm thinking a simple usable API
> > with a few drivers in 3 months is much more valuable then waiting a year
> > for us to fully detail a spec and then get some initial implementations.
>
> Agreed.
>
> One useful measure of success is getting a handful (three to five) of
> independently-written applications to work with a handful
> independently-written of drivers. If we can do this, then I'd say we
> have a pretty useable spec.
>
> -- Ron
>
> ----------------------------------------------------------------------
> Post a message:         mailto:[EMAIL PROTECTED]
> Unsubscribe:            mailto:[EMAIL PROTECTED]
> Contact adminstrator:   mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> ----------------------------------------------------------------------


----------------------------------------------------------------------
Post a message:         mailto:[EMAIL PROTECTED]
Unsubscribe:            mailto:[EMAIL PROTECTED]
Contact adminstrator:   mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------

Reply via email to