Re: OO-XQ-OO: to do or not to doWalpole, Robert robert.walpole at metoffice.gov.uk
Tue Mar 9 13:37:43 PST 2010
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/c) 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 >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format