Re: The State of Native XML databases

[Frank Cohen]

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  
architects.

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  
developer programs.

A lot of work is still needed to move the state of native XML  
databases to "excellent".

-Frank





On Aug 20, 2007, at 8:28 AM, Jeff Dexter wrote:

> John,
>
> 	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  
> discussion
> 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.
>
> Jeff.
>
> -----Original Message-----
> From: http://x-query.com/mailman/listinfo/talk [mailto:http://x-query.com/mailman/listinfo/talk] On  
> Behalf
> Of John Snelson
> Sent: Monday, August 20, 2007 2:22 AM
> To: Ilya Sterin
> Cc: http://x-query.com/mailman/listinfo/talk; Dr Orlovsky MA
> Subject: Re:  Re: The State of Native XML databases
>
> Ilya,
>
> 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  
> definition.
> Can you let us know what "enterprise" use cases are handled by  
> TigerLogic
> that other XML databases cannot handle?
>
> Also, I agree with Michael Kay that collections are in no way a  
> relational
> 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.
>
> John
>
> 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  
>> the
>> collection entry level, that beats the purpose of having a native xml
>> database where ddl=xml schema.  In a perfect world, I wish the  
>> vendors
>> 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.
>>
>> Ilya
>>
>> On 8/19/07, Dr Orlovsky MA <http://x-query.com/mailman/listinfo/talk> 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:
>>>>
>>>> http://cafe.elharo.com/xml/the-state-of-native-xml-databases/
>>>>
>>>> Comments appreciated.
>>>>
>>>>
>>> There is excellent native XML dsatabase completelly implementing  
>>> XQuery.
>>> See for Sexdna XML database in google as well as look at the site
>>> http://modis.ispras.ru/sedna/
>>>
>>> _______________________________________________
>>> http://x-query.com/mailman/listinfo/talk
>>> http://x-query.com/mailman/listinfo/talk
>>>
>> _______________________________________________
>> http://x-query.com/mailman/listinfo/talk
>> http://x-query.com/mailman/listinfo/talk
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>
>
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>



--
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool