Casey Durfee wrote:

>
>I thought that was the point of using interfaces?  I guess I don't get why you need a standard to be compelled to do something you should be doing anyway -- coding to interfaces, not implementations.
>
>
Interfaces work well with like products (a database abstraction library
is a great example), however interfaces don't lend well to products that
achieve a similar goal but work differently altogether.  Relational
databases all work the same: there are databases, each database has
tables, views, procedures, etc. and each table has columns, etc.
However more infantile systems such as xml storage systems are hard to
map in a similar fashion.  I ran into this exact problem, I developed a
system around eXist and developed an interface for the data layer and a
"driver" for interacting with exist.  I then wanted to compare other
databases such as berkeley db xml.  I quickly found that they achieve a
common goal, but do not implement the same concepts making them very
hard to compare.  eXist has "collections" to group your xml into
distinct groupings and db xml does not.  In my interface I had a method
called getCollections, but since db xml does not have anything like
this, I could not use that method.  So now how would you develop an
interface that would include various xml databases as well as full-text
index systems such as lucene, etc.  I would image this would be very
challenging.