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

[Walpole, Robert]

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
>