Ah -- but why do you assume that the developer is coming from an object background. Perhaps that developer is not the right person to be writing the application.
The choice to use an native XML processing language (e.g., XSLT, XQuery, dynamic languages) vs an OO language (e.g., Java, .NET) should be driven by the task you are trying to do. If you have XML coming in, and XML going out, and you're simply manipulating the data, stick with XML. XQuery is a remarkably powerful programming language. If you need a GUI to go with it, try XForms, InfoPath, or Word. On the other hand, if you have complex data relationships to manipulate or complex algorithms to process, then the task calls for transforming the data into an object graph. But I recommend avoiding the data binding and transformation unless the task really calls for it. Anne On Tue, Jan 20, 2009 at 6:41 AM, Dennis Sosnoski <[email protected]> wrote: > Michael Poulin wrote: >> Actually, I do not catch the point "but if you're using essentially >> all the document data in your processing, this approach is going to be >> both very slow and very awkward for developers who are coming at the >> problem from a programming language background" because XMLBeans do >> not transform the whole doc but only the part you work with at the >> time, they use lazy-transformation, this is why they fast. > > The lazy transformation approach gives great performance if you only > need to apply it to small portions of the document, but if you end up > applying it to most of the document it involves a lot more overhead than > just a direct data binding approach which transforms the entire document > at once. > > As for the awkwardness of the interface, here's a sample web services > client call using XMLBeans: > > // retrieve a book directly > GetBookDocument gbd = GetBookDocument.Factory.newInstance(); > GetBookDocument.GetBook gb = > GetBookDocument.GetBook.Factory.newInstance(); > gb.setIsbn("0061020052"); > gbd.setGetBook(gb); > GetBookResponseDocument gbrd = stub.getBook(gbd); > BookInformation book = gbrd.getGetBookResponse().getBook(); > System.out.println("Retrieved '" + book.getTitle() + '\''); > > Here's the same call using JAXB: > > // retrieve a book directly > GetBook gb = new GetBook(); > gb.setIsbn("0061020052"); > GetBookResponse gbr = stub.getBook(gb); > BookInformation book = gbr.getGetBookReturn(); > System.out.println("Retrieved '" + book.getTitle() + '\''); > > And here's the same call using JiBX or ADB binding with an unwrapped > interface: > > // retrieve a book directly > Book book = stub.getBook(isbn); > System.out.println("Retrieved '" + book.getTitle() + '\''); > > In my experience, most developers find the extra layers of wrapper > classes and factory classes, and the mix of outer/inner classes used by > XMLBeans, a bit painful. Certainly it leads to considerably more verbose > code, at any rate. > > - Dennis > >
