[xquery-talk] Re: The State of Native XML databases
fcohen at pushtotest.com
Tue Aug 21 13:30:41 PDT 2007
For a topic titled "The State of Native XML Databases" the
conversation seems to be more about semantics. From my perspective
the state of native XML databases is pretty poor. There is not that
much uptake on native XML databases from enterprises, developers, and
It seems to me that native XML databases would be in a much better
state when the following happen:
1) The Implementations Provide The Full Benefits of The Data Model.
The XML data model is wonderfully rich and flexible. There is big
divide that developers have to overcome when going from the XML data
model to an XML database. It is not a given that XQuery is way to
implement a database for the XML data model. When I was at the W3C
Plenary 2 years ago there was plenty of energy in discussing
alternatives to XQuery and XSLT. And I would prefer to write code
today, not wait another 7 years for a standard like XQuery to emerge.
It seems to me that developer marketing from the native XML database
vendors and open-source projects is mostly disingenuous when they
position their products as a general-purpose database. In my
experience most of the native XML database projects come to the XML
data model from a different perspective and that impacts their
implementation of the data model as an XML database. For instance,
there is still argument on this list about the best way to create a
collection with one perspective using XML Schema and others arguing
for an language semantics approach. (By the way, neither work for me
as a Java developer. I want to from object definitions and maybe Java
annotations to a collection.)
As a developer I would prefer to know which native XML database is
suited to my application. For instance, Ilya's application requires
node-level locking and my design for the next generation of TestMaker
requires roles-based securing at the XML document level. In the RDBMS
marketplace I have many resources to show me which databases are
appropriate for my applications. The native XML database marketing
needs something similar.
2) The lack of thought leaders
Where are the Tim Bray's, the Adam Bosworth's, and Erik Meijer's, the
Sam Ramji's for the native XML database space? I had great hope for
Jason Hunter but even his star is taking a while to cross over from
the Java to the native XML db space.
The native XML database space needs someone of reputation and
standing in the Java and .NET developer community to stand-up and
show some great and practical applications.
3) The lack of tools
I like some of the tools I have seen. The Progress tools set is nice.
I would love to see native XML database support with a flexible
binding system in NetBeans, in Visual Studio, Eclipse, IntelliJ.
4) The lack of a clubhouse
I want a place to meet up with all of you! JavaOne, JavaPolis, JAOO,
and QCon are my place to meet up, share ideas, and exchange solutions
in the Java space. I would love to have XMLOne once a year!
I spent 2005-6 inside Raining Data and know first hand what it is
like to ask a quarter-by-quarter focused management team to invest in
A lot of work is still needed to move the state of native XML
databases to "excellent".
On Aug 20, 2007, at 8:28 AM, Jeff Dexter wrote:
> I've previously had the argument with Ilya on the collection vs.
> document notion, and while I do disagree this is a relational
> concept, it's
> important to understand that his use case does not work well with the
> concept of collections. He's dealing with very large, single documents
> representing the collaboration point and he requires a high degree of
> concurrent access to them. We tried melding the collection concept
> to this,
> but in his case he's constrained by a standard schema and so
> shredding into
> sets of smaller documents would not work. Hence the document is the
> database, in this use case.
> In regard to XML Schema, leaving all discussion on the failing and
> complexities of the language aside, once you do have the darn
> things written
> they can be quite helpful in authoring XQueries, typing your
> collections and
> other activities so they are germane to the original discussion of
> the state
> of native XML databases. In my anecdotal experience for every
> person that
> squirms when I mention XML Schema in their application there's
> another who
> already has a few dozen cooked up and is raring to use them.
> Finally, "enterprise" and "native" are indeed bandied about
> altogether too much, but again Ilya brings up a good point in the
> of the state of native XML databases, which is how individual
> databases and
> more general XML platforms handle things like locking/concurrency,
> transactions, etc. which are feature very relevant to large scale
> applications, and again, an interesting aspect to use in
> contrasting the
> various implementations.
> -----Original Message-----
> From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On
> Of John Snelson
> Sent: Monday, August 20, 2007 2:22 AM
> To: Ilya Sterin
> Cc: talk at xquery.com; Dr Orlovsky MA
> Subject: Re: [xquery-talk] Re: The State of Native XML databases
> Even if I ignore your use of the amorphous and irrelevant term
> "native XML
> database", there are still some pretty tall claims in this email.
> For a start, not everyone likes or wants XML Schema - it does have
> a habit
> of turning an extensible format into a highly restricted one, which
> I would
> argue was not very forward thinking. Only once in the 3 years I've
> worked on
> Berkeley DB XML has anyone ever commented that we didn't use XML
> Schema (or
> any schema language) to restrict the data stored.
> You use the term "enterprise persistence" without any kind of
> Can you let us know what "enterprise" use cases are handled by
> that other XML databases cannot handle?
> Also, I agree with Michael Kay that collections are in no way a
> concept - so this is another red herring.
> I'm not pretending to be partisan in this debate, but I do try to
> stay away
> from marketing spin and sweeping statements.
> Ilya Sterin wrote:
>> I wish I could find more info on it. The site states acid
>> transactions, but for people people unfamiliar with transaction
>> architectures, that doesn't equate being able to use it in an
>> enterprise application environment. If consistency is enforced at
>> collection entry level, that beats the purpose of having a native xml
>> database where ddl=xml schema. In a perfect world, I wish the
>> would get rid of the collection as a storage metaphor and instead
>> focus on defining schemas with one of the schema languages, which is
>> all that's needed. Why mix relational concepts, which is what a
>> collection really is, with native xml hierarchal storage.
>> We recently engage in numerous native xml storage projects and worked
>> very closely with RainingData on a TigerLogic 3.0 release. As of
>> right now, that is probably the only truly native xml database that
>> defines all facilities needed for enterprise persistence in XML.
>> On 8/19/07, Dr Orlovsky MA <dr.orlovsky at gmail.com> wrote:
>>> On Mon, 13 Aug 2007 22:01:19 -0400, Elliotte Harold wrote:
>>>> On another list I was recently asked to sum up the state of native
>>>> XML databases, especially open source ones. The result is here:
>>>> Comments appreciated.
>>> There is excellent native XML dsatabase completelly implementing
>>> See for Sexdna XML database in google as well as look at the site
>>> talk at x-query.com
>> talk at x-query.com
> talk at x-query.com
> talk at x-query.com
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool
More information about the talk