size of XQuery developer community

[Ronald Bourret]

I agree with Daniela. For some real-world examples of this kind of 
thing, see:

   http://www.rpbourret.com/xml/UseCases.htm

It's worth noting that people tried to build many of these applications 
on relational databases and failed. The article explains some of the 
reasons why.

This article is based on a non-scientific survey of XML database 
companies. It was done in 2005 and included about half of the XML 
database companies at the time, including most of the major ones.

-- Ron

Daniela Florescu wrote:
>>
>>
>> I honestly think that all the talk about XDM as a data model and XQ as 
>> a turing complete declarative language, etc., is sort of moot unless 
>> they do somehow enable something that RDBMS/BI/Data warehouses/search 
>> vendors can't readily do with existing approaches.
> 
> Well, that's relatively simple to answer, I would say.
> 
> Here is are some examples of what you could do with XML/XQuery that you 
> cannot do with the traditional three
> tier stack (communication + application logic written in an imperative 
> language + declarative query layer)
> 
> 1. Have schema flexibility. Start writing code without a fixed idea of 
> your schema, and/or change
> your mind later. (one schema is evil enough, three layers of 
> superimposed schemas, in three different models,
> are exponentially evil for flexibility and customizability. Almost no 
> evolution of schema is possible.)
> 
> 2. Integrate text and documents into your information processing flow 
> without adding software license, yet another layer,
> more mappings, and different programming languages.
> 
> 3. Optimize the performance of your information processing program 
> globally, not locally, layer by layer,
> by adding more and more intermediate caches and shortcuts, which in turn 
> will turn your code maintenance a nightmare.
> 
> 4. Be done in 2 weeks instead of 10 months. Time to market, by writing 
> significantly less amount
> of code, layer to layer connectors, plus data mappers from one model to 
> another, etc, etc. Less
> useless and redundant code to write and later deal  with.
> 
> 5. Spend less time maintaining the code. If the XQuery optimizer is 
> doing a good job, you don't need
> to constantly rewrite your code to fix performance problems, as you do 
> in java. Plus less number of lines of
> code usually means less bugs. So smaller total cost of ownership of the 
> code.
> 
> That would be my quick personal answer.
> 
> But that of course works if you know what you are doing with XQuery ....
> 
> Best
> Dana