size of XQuery developer community

[Daniela Florescu]

And let me add two more things that you could do with XQuery that you  
can hardy do otherwise
-- because there are more cool :-)

6) virtualize it for the cloud execution.  Scale it up and down for  
cloud execution.
The more layers, and less declarative the layers, the harder is this  
to do.

7) automatically translate Xquery programs into parallel Hadoop  
programs.
This doesn't work with imperative programs.

Best regards
Dana




On Sep 1, 2009, at 8:55 AM, 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
>
>
>
>
>
>
>
>
>> If XQ is just an incremental improvement, it will always be a  
>> marginal language (for example, that's how I see the XQ scripting  
>> in the browser situation; it's simply not THAT much better than  
>> JavaScript, and has the disadvantage of not having a million  
>> libraries and code snippets and programmers).  I actually think  
>> that it is much more than incremental in search, and it may be  
>> elsewhere as well.
>>
>> -Rob
>>
>>
>> On Tue, Sep 1, 2009 at 4:50 AM, Andrew Welch <http://x-query.com/mailman/listinfo/talk 
>> > wrote:
>> 2009/8/31 Daniela Florescu <http://x-query.com/mailman/listinfo/talk>:
>> >> why do developers and architects so stubbornly refuse just to  
>> _listen_ ?
>> >
>> > Because we don't talk to them (a) enough and (b) with a message  
>> that they
>> > understand.
>>
>> What is the number one "killer app" for XQuery, shining example that
>> can be given to people when talking about XML databases - one that is
>> high profile enough that they may have heard of it?
>>
>>
>>
>>
>> --
>> Andrew Welch
>> http://andrewjwelch.com
>> Kernow: http://kernowforsaxon.sf.net/
>> _______________________________________________
>> http://x-query.com/mailman/listinfo/talk
>> http://x-query.com/mailman/listinfo/talk
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090901/d6058752/attachment.htm