Re: OO-XQ-OO: to do or not to do

[Daniela Florescu]

Please look bellow:
http://dmsblog.burtongroup.com/data_management_strategie/2010/03/reject-the-[expletive deleted]-of-enterprise-information-systems.html

How timely !

Thanks John for tweeting about it !

Dana









On Mar 9, 2010, at 5:37 AM, Walpole, Robert wrote:

> As an experienced XQuery developer now working on a large Java/ 
> Oracle RDBMS application which, ironically perhaps, produces mostly  
> XML as an output, I am regularly asked how we could "do this better"  
> using "some" XQuery. Like Peter, the conclusion I have reached is  
> that we can't - unless we rip out the entire architecture and start  
> again with an XML database and use pure X-processing end-to-end  
> (just as Dana suggests). There is no doubt whatsoever that this  
> would dramatically decrease our codebase and even my colleagues with  
> no X-experience can see (through the countless little demos I have  
> knocked together) how much easier this would make things (albeit  
> with perhaps some questions to be answered about performance).
>
> However, such far-reaching decisions in an organisation like mine  
> have to be taken at a senior level by architects who tend to be  
> heavily influenced (IMHO) by highly commercial conferences,  
> presentations and publications where new W3C standards just don't  
> make any impact. The only way I think this will change, as far as  
> XQuery is concerned, is through the organic growth of pure X-based  
> applications which gradually make bigger and bigger impacts on the  
> world and simultaneously, the emergence of more commercially- 
> oriented XQuery/XML processing applications which have a vested  
> interest in getting their message across.
>
> Cheers
> Rob Walpole
>
>> -----Original Message-----
>> From: http://x-query.com/mailman/listinfo/talk
>> [mailto:http://x-query.com/mailman/listinfo/talk] On Behalf Of Peter Coppens
>> Sent: 09 March 2010 08:01
>> To: Hans-Juergen Rennau
>> Cc: http://x-query.com/mailman/listinfo/talk
>> Subject:  Re: OO-XQ-OO: to do or not to do
>>
>> Hans-Juergen
>>
>> Thanks for your comforting words :)
>>
>> In my specific case, if ignorance was involved, it was on how
>> to build an application architecture (apologies for the
>> bloated term) where it made sense to use XQuery processing
>> for those parts of the app that deal with XML. Actually, it
>> was a combination of ignorance and lack of motivation to
>> attempt to replace the typical (conservative) OO logic with
>> something that would be implemented with e.g. an XML
>> pipeline.  I knew XQuery fairly well when I started out with
>> the application but I did not immediately want to go along a
>> path where a 'user' and an 'order' etc was not stored in an
>> RDBMS. Once you turn that corner, the battle is lost unless
>> other parts of the app need substantial XML processing (more
>> than your first few pages of additions :) ). There is today
>> just no acceptable way to integrate 'a little bit' of XQuery
>> in your average Java app....at least not one I could come up
>> with after a limited amount of trying (I was getting paid to
>> build an app not to struggle and come up with some
>> environment where XQuery would be used no matter what). The
>> engineer who ripped out the next batch of XQuery expressions
>> in this case was not all that wrong...or I would have stopped him.
>>
>> (but it is not as depressing as it sounds. Once one turns his
>> head, there is a technically challenging life out there where
>> XQuery does not play a part in :) )
>>
>> Cheers,
>>
>> Peter
>>
>>
>>
>> On 08 Mar 2010, at 09:39, Hans-Juergen Rennau wrote:
>>
>>> Peter,
>>>
>>> this is a depressing story. A few thoughts in response.
>>>
>>> An idea's, language's or product's main enemies are: the
>> weakness of its strength, the strength of its weakness, and
>> the ignorance of people. With XQuery, the first is
>> microscopic, the second challenges the understanding required
>> to restrict the use of XQuery to where it is strong and
>> integrate it cleanly, the third is devastating.
>>>
>>> I think the ignorance - exemplified by the "engineer" - is
>> largely based on one oversight: which concerns the
>> scalability of complexity. As long as the XML handling is
>> concentrated around single item access (like a/b[2]/c[3]) and
>> *fixed* patterns of aggregation, conventional Java approaches
>> are acceptable, may be a good choice. When the complexity of
>> aggregation increases and involves unforeseen steps, those
>> approaches let the effort explode and the code deteriorate.
>> Unless those Java approaches invent a *language*,  to know
>> something equivalent to XQuery, which seems to me very unlikely.
>>>
>>> Imagine a world which thinks mathematics is mainly a matter
>> of addition and substraction. Further imagine you have
>> learned the operations of multiplication and division.
>> Further imagine it is mainstream to fill several pages with
>> two columns - one with identical figures, the other with an
>> evenly incrementing sequence of figures. At this point of the
>> story, I would not believe the world.
>>>
>>> With kind regards,
>>> Hans-Juergen
>>>
>>>
>>>
>>> ----- Ursprüngliche Mail ----
>>> Von: "http://x-query.com/mailman/listinfo/talk" <http://x-query.com/mailman/listinfo/talk>
>>> An: http://x-query.com/mailman/listinfo/talk
>>> Gesendet: Sonntag, den 7. März 2010, 21:00:08 Uhr
>>> Betreff: talk Digest, Vol 83, Issue 12
>>>
>>> Send talk mailing list submissions to
>>>   http://x-query.com/mailman/listinfo/talk
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>   http://x-query.com/mailman/listinfo/talk
>>> or, via email, send a message with subject or body 'help' to
>>>   http://x-query.com/mailman/listinfo/talk
>>>
>>> You can reach the person managing the list at
>>>   http://x-query.com/mailman/listinfo/talk
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of talk digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>  1. Re: OO-XQ-OO: to do or not to do (Peter Coppens)
>>>  2. RE: OO-XQ-OO: to do or not to do (Hans-Juergen Rennau)
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 7 Mar 2010 09:31:54 +0100
>>> From: Peter Coppens <http://x-query.com/mailman/listinfo/talk>
>>> Subject: Re:  OO-XQ-OO: to do or not to do
>>> To: http://x-query.com/mailman/listinfo/talk
>>> Message-ID: <http://x-query.com/mailman/listinfo/talk>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>>> "And yes, using XQuery, XSLT, XProc, XForms, X... for the
>> XML-focused
>>>> parts of your application is a huge improvement over manual DOM
>>>> fiddling. But that is hardly news, is it? "
>>>>
>>>> Not to *us* - it would be ridiculous to tell this anyone
>> already interested in xquery-talk. But do you think this is
>> commonly understood by OO developers, do you think the
>> "average" OO project checks this option and then makes a
>> decision pro or con?
>>>
>>> Well...fwiw and being based on my personal experience only
>> and not on some deep knowledge of the industry or the latest
>> developments in the XML processing technologies.....
>>>
>>> When I left the company where I was working on an XQuery
>> implementation I was convinced XQuery would be an important
>> part of the future application architecture I was going to
>> work on. I liked (still do) the language and it is certainly
>> easier to work with XML using XQuery than it is struggling
>> through the verbosity of the DOM API or the state mgmt needed
>> to deal with StAX event streams.  I was almost as motivated
>> to use XQuery than I was motivated to attempt to make the
>> application a success.  After almost four years there is
>> hardly any XQuery left and the last bits will eventually
>> disappear...unfortunately.
>>>
>>> Main reasons being
>>>
>>> 1. Integrating XQuery with Java is cumbersome at best and I am not
>>> sufficiently educated in alternatives to get rid of Java for
>>> substantials parts of the application logic. While I can
>> see in theory
>>> how that could be attempted I am not confident the amount
>> of issues to
>>> deal with when attempting that would not be substantially
>> bigger than
>>> dealing with the Java XML API's. But...I have not attempted
>> so I can't
>>> really know for sure
>>>
>>> 2. The amount of XML processing in my environment is mainly
>> limited to crossing the XML - OO barrier and some limited
>> querying and restructuring. That is obviously partially
>> because of (1), but some carefully crafted Java utilities
>> (DOM and StAX based) have proven to be sufficiently scalable,
>> stable and maintainable for our purposes.
>>>
>>> 3. The one part where it would really matter to use XQuery needed a
>>> guaranteed streaming approach (large repetitive XML structures).
>>> Unless one is willing to fight through the peculiarities of
>> the XQuery
>>> optimizer at hand (and its consecutive versions) there was
>> no way to
>>> make that happen without an interesting upgrade risk when the next
>>> version of the XQuery processor came around
>>>
>>> 4. The next engineer who would come in to work on our system would
>>> raise his eyebrows when he ran into the XQuery (some were less
>>> diplomatic and had more harsh opinions on my technology choice :)).
>>> After a few hours he would have extended the Java utilities
>> (if needed
>>> at all) and removed the next few XQuery expressions...and
>> except for
>>> personal preferences I had hardly any arguments to stop him
>> (for all
>>> of the above reasons)
>>>
>>> To be complete I have to state that when we started the
>> application, XQuery Updates where not available. That might
>> have made a difference....perhaps.
>>>
>>> Using XQuery might save us 80% dev/test/maintenance time on
>> what today is perhaps 5% of the complete system. For that we
>> would have to introduce a new technology that is not well
>> known by the average engineer and who's future availability
>> is not necessary carved in stone. Again, obviously a
>> completely different application architecture based on XML
>> data structures being passed along a pipeline, would result
>> in different numbers.
>>>
>>> I got caught in that previously mentioned vicious circle.
>> For me it proofed to be an uphill battle, one I have almost
>> lost. A single personal experience no doubt, but I am fairly
>> sure it is not unlike a lot of others out there.
>>>
>>>
>>> Peter
>>> ************************************
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Sie sind Spam leid? Yahoo! Mail verfügt über einen
>> herausragenden Schutz gegen Massenmails.
>>> http://mail.yahoo.com
>>
>>
>> _______________________________________________
>> 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