Re: [xml-dev] XML DB - anything new and interesting?

[Thomas Lord <lord@emf.net>]

Robert Koberg wrote:
> Hi,
>
> I am looking into XML databases as it relates to content management and
> as a general web platform. Was wondering about the opinions of people on
> this list -- any thoughts, comments, concerns?
>
> A few things I have noticed:
>
> * EMC/Documentum bought XHive.
(no opinion)

> * MarkLogic seems to be doing a lot of things right. 
Agreed but no hands-on experience with it because:

> They seem to be the default choice /if/
> you have the money. Is that your opinion?
>   

Yes.

Dirty little secret #1: eXist seems to be making progress.
Not sure it scales well, long term, or that the framework
being built in it has legs.

Dirty little secret #2: I'm having a blast playing around with
DB XML (from Oracle (formerly from Sleepycat)).  And, they're
quite actively making it nicer and nicer.   You can do a lot with
very little code.  (My first pass, not ready for prime-time is still up
at http://basiscraft.com -- next pass is underway.)


> Also, it seems a few people are trying to get the XRX (XForms Rest
> XQuery) meme going. In the past when evaluating Xforms I found it
> limiting with what I could do in the UI. I have been more comfortable
> using javascript and XHTML directly. 
>   

I think you're in the right direction.   There's still work to do
to make the Javascript side nice.   There's definitely work to do
to make systems that can work without Javascript.  But, yeah,
XForms didn't seem quite right when I considered it.  (So: "me too.")

Alternative:


> Are you comfortable using XQuery as your templating language?

Heck no.  On the other hand, the combination of XQuery with XSLT
is pretty sweet, I'm finding.    Oh, yeah, sure: XSLT syntax is just plain
painful to type but that's a minor issue because you can do a lot with
a little.

Great minds think alike, apparently:

>  I am very
> interested in using XQuery in an aggregation layer, not so much as a
> templating language which is where the products (at least eXist and
> MarkLogic) seem to want you to go. I think I would prefer to use XQuery
> as the aggregator to feed an XSL transform. I have a slight worry there
> that I would be duplicating some efforts like creating some DOMish
> representation for the XQuery and then another one for the XSL
> transform.
>
> what do you think?
>
>   

Welcome to the party.

Be aware that there *is* a standard XML syntax for XQuery that
might or might not be applicable to what you are contemplating.
My little "first pass" project mentioned above also puts XQuery
in XML but as text (e.g., I wanted all the logic to be stored in
the database along with the content).

You don't say much about why you want a "DOMish" representation
but the idea appeals to me for modularity.   *If* one can devise a
clever enough set of conventions for XSLT and XQuery "components"
then perhaps the transforms actually applied and queries used can
sometimes be automatically synthesized by composing those components
in a content-driven and request-driven way.

It's a rich space and there's tons to do in it ideally resulting in
very little actual code needed for the framework, of course.
I get a chuckle every time I "weigh" the stuff I've been building
against, say, Ruby on Rails.   People are going to be shocked at
how much effort they've been wasting.



-t