DewDrop is an open-source framework that generates source code to
support any entity-relationship data model. In practical terms: it
generates SQL DDL (Data Definition Language, a.k.a. Database Definition
Language) for any database.

DewDrop addresses the need to:

Define a database generically.

Support multiple database vendors.

Simplify database definitions.

Eliminate numerous vendor-specific files.

Propagate design changes from a single location.

DewDrop allows you to define your entity-relationship database just
once in XML in the form of SQLML, regardless of what database(s) you
might want to use. In doing so, you are freed from knowing database-specific
DDL for any of these databases. DewDrop provides its own standards-based,
easily understandable XML DDL for you, otherwise known as SQLML. No
more worrying about "Does rdbms-X support foreign-keys? or What
is the syntax that rdbms-Y uses for adding a table constraint?"

All you have to do is define your tables and their relationships
in SQLML, and DewDrop takes care of all the nasty details. You tell
DewDrop what target database(s) you want to use, and it generates
clean, human-readable SQL DDL code for your target. If you like, you
don't even have to look at the SQL; you can just have DewDrop install
the generated database for you automatically and be on your way developing
your application. That's it...no more worrying about how to port (or
even worse, completely rewrite) your datamodel to other databases.

Nicely summarized: "One XML Definition. Any Database."

What is DewDrop not?

DewDrop is not:

A complete replacemet for SQL

DewDrop currently only handles definitions of data models
via SQLML. That is, it nicely handles the equivalent of all SQL
statements for creating tables, columns, table
and column constraints, indices, etc. To actually insert/update/retrieve
data from these databases, you still need to execute SQL insert/update/select
queries. However DewDrop's SQLML provides a <native> target
that allows you to embed any sql within the XML document, ensuring
all databases are supported, and you still only have one file to
deal with.

A Data Binding framework (yet)

As DewDrop is fairly new, it cannot yet take your SQLML data model
and create Java or C# classes that directly map (or bind)
to your definition. However, this feature is of prime concern for
the project managers, and this functionality will definately be
included in later releases. Other open source projects such as Hibernate,
JiBX, Castor
or Zeus may be utilized. If
functionality requirements deem necessary, we might also create
our own binding framework.

A persistence layer (yet)

Currently, DewDrop itself does not provide a means of saving data
model instances to a RDBMS (Relational DataBase Management System).
Since DewDrop does not (yet) generate source code in languages other
than SQL (e.g. Java or C# classes), it has no means of persisting
data instances of these classes. Again, other means may be used
to provide this type of functionality (e.g. Hibernate,
EJB, Castor,
or OFBiz), or we may
create our own persistence layer.

The above features will be reviewed over time, and if the need arises,
will likely be implemented in one way or another.

Why the Name?

Water vapor in the evening is composed of many independent water
molecules, just floating around with no common bond. However, at dawn,
after the temperature has dropped, the water molecules condense
and gather. Together, they eventually form a single drop of water,
or dew.....a dew drop.

DewDrop is the condensation, or consolidation of multiple
database definition language implementations into a single point of
gathering...essentially a dew drop of SQL DDL.

We know this explanation is somewhat ethereal and overtly metaphorical.
But it sounded good, so why not? ;)