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

[Peter Coppens]

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