Re: is GiST still alive?

Gregor,

> Thanx for your advise, but that's not what I had in mind. The original
> idea to have a native xml database was that I doesn't work too well in a
> relational database.
> I was just wondering wheater I have to reinvent the wheel of database
> technology when it comes to transaction processing, ACID, and Indexes,
> which a native xml database ought to have as well.

Reinvent the wheel? Well, yes.

The first thing ... the VERY first thing, abosolutely ... that you need to do
is invent a theory of XML databases. That is, before you write a single
line of code, you need to have a comprehensive theory that defines:
1) What is an XML database and what is not.
2) How querying an XML database must work
3) Data constraints and data models for an XML database.

Without these things, you're just another idiot floundering around a morass of
acronyms and half-baked ideas. With them, you will have something that no
current XML database project/product has, and can give XML databases a
fighting chance to survive beyond the current fad.

Of course,it's possible in the course of theorizing that you may prove that
XML databases are impossible. But that's how the cookie crumbles ....

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Wed, 22 Oct 2003, Josh Berkus wrote:
> Reinvent the wheel? Well, yes.
>
> The first thing ... the VERY first thing, abosolutely ... that you need to do
> is invent a theory of XML databases.
Well, I have. It doen't cover all parts in detail yet, because I've
started with a simple IO layer (simple page locking, no concurrent
transactions) and worked on the page layout and parsing algorithms from
there on. Querying on that format will follow thereafter. And concurrency
issuses will be dealt with even later.
I am considering hierachical locking (any part of the tree).
I was just wondering wheater I could take some of that fuctionlay from an
existing database.

> Without these things, you're just another idiot floundering around a morass of
> acronyms and half-baked ideas.
I know

> With them, you will have something that no current XML database
> project/product has, and can give XML databases a fighting chance to
> survive beyond the current fad.
If there was a promising project for an xml database, I would have joined
it.

> Of course,it's possible in the course of theorizing that you may prove that
> XML databases are impossible. But that's how the cookie crumbles ....
only an implementation is a real proof.

--
Gregor Zeitlinger
gregor(at)zeitlinger(dot)de

Gregor,

> Well, I have. It doen't cover all parts in detail yet, because I've
> started with a simple IO layer (simple page locking, no concurrent
> transactions) and worked on the page layout and parsing algorithms from
> there on. Querying on that format will follow thereafter. And concurrency
> issuses will be dealt with even later.

Um, I/O and Page layout are not theory. They are implementation issues.

Theory would answer things like "What are the mathematical operations I can
use to define compliance or non-compliance with the DTD for a heirarchy and
for data elements?"

Or, "Is an XML database multiple documents or a single large document?"

Or, "How may new items be added to a DTD for an existing database, and what
operations must then be performed on that database to enforce compliance?"

etc.

> only an implementation is a real proof.

Implementation is proof of a theory. But you've got to have the theory first
or you don't know what you're proving.

Anyway, I don't think you an borrow code from any existing relational
database,since an XML database would be radically different structurally.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, 23 Oct 2003, Josh Berkus wrote:
> Um, I/O and Page layout are not theory. They are implementation issues.
yes or no, depending on your point of view.

> Theory would answer things like "What are the mathematical operations I can
> use to define compliance or non-compliance with the DTD for a heirarchy and
> for data elements?"
<snip>

Yes, that's also tought of. Most of it was done by a collegue at
university, who came up with the idea, but didn't do any implementation.

> > only an implementation is a real proof.
>
> Implementation is proof of a theory. But you've got to have the theory first
> or you don't know what you're proving.
agreed.

> Anyway, I don't think you an borrow code from any existing relational
> database,since an XML database would be radically different structurally.
I'm getting this impression, too.

--
Gregor Zeitlinger
gregor(at)zeitlinger(dot)de