String vs. DOM XML Support
Brought to you by:
cbegin
Menu
▾
▴
SQL Maps 2.0 introduced a new feature that directly supports XML as a type, therefore allowing simpler storage and retrieval of XML data via SQL Maps.
Currently this support works using Strings containing the XML document (for both reading and writing).
This thread is here to discuss the pros and cons of using String vs. a DOM.
To start us off, so far I think it's been said that:
* String is simpler and faster.
* DOM is more flexible and possibly more useful.
Thoughts?
Clinton
Why not just have a DomXmlDataExchange, SaxXmlDataExchange, StringXmlDataExchange, etc... I think this would satisfy the desires of Vic ;-). I am a bit curious about the context in which the XML results would be used. It might provide some more relevance as to which we should use.
Vic's needs are interesting...I believe what he needs is actually a feature above the mapping layer. He want's a getAsXML which will basically get any of the statement results as XML.
This is an interesting approach, certainly easier to work with and implement. But I'm worried that performance may suffer. It also might be beyond the scope of SQL Maps to do something like this (why not just transform the bean or map outside of the SQL Maps API?).
The trick about the data exchange is that it unfortunately is not the only part impacted by this change...it should have been...but it didn't work out that way.
In any case, I think we're heading down the right track.
Cheers,
Clinton
The more I think about this, the more I'm worried about it. I'm seriously considering implementing DOM (w3c) instead of String.
Here are the reasons:
* Better iBATIS implementation. The current solution with Strings has a "patchwork" feel to it. I think DOM will allow us to have a cleaner and more robust implementation.
* More flexible for users. I've already had requests from users for this, and although the String solution is technically faster, it actually has a negative impac on performance if the user immediately reparses the XML to get the DOM. The iBATIS internal implementation uses a DOM anyway, so it's actually less work for the framework.
* If we do end up implementing higher level XML functions (as Vic has asked for), they'll be able to convert the DOM to an XML string anyway.
* Gilles has indicated that he believes Nausicaa will be best implemented with a DOM solution for XML support.
Can we get a quick vote? +1 (agree) -1 (disagree) or 0 (no opinion)
Clinton
<quote>
* More flexible for users. I've already had requests from users for this, and although the String solution is technically faster, it actually has a negative impac on performance if the user immediately reparses the XML to get the DOM. The iBATIS internal implementation uses a DOM anyway, so it's actually less work for the framework.
</quote>
If I may comment on it as a user: I completely agree.
Current situation when iBatis returns the XML document as a string holds me back from using iBatis for cases where I need a query results in the form of a pure DOM.
Having the data in DOM form allows great level of flexibility of how the data can be repeatedly displayed, formatted, and manipulated. E.g. two or three org.w3c.Document's can be altered and/or combined into one and then pushed through different XSLT transformations to get custom views. Doing these manipulations with strings seems to be against good design and efficiency.
There are a few different APIs for manipulating XML in Java (JAXP, JDOM, dom4j). JDOM is more or less abandoned. dom4j is decent but is not standard. I am for standard W3C's DOM API because it is supported by a number of implementations:
(1) Apache (Xerces-J 2.x + Xalan-J XSLT)
(2) JAXP RI (bundled with a JDK)
(3) Saxon (parser and XSLT processor)
(4) GNU JAXP
Regards,
Valeri
Hi Valerie,
Thanks for the feedback. It definitely won't be JDOM or DOM4J. Version 1.x had a lot of problems with JDOM. I agree, it's abandoned.
That leaves us with W3C, which I agree is probably the most flexible choice, even if it's a bit heavy...
Cheers,
Clinton
0 (leaning towards a +1) - I don't know enough about the xml implementation. But, if you say it is already DOM now... then it seems like a no brainer. I think the XML stuff will have to come with a warning label though. DOM isn't light-weight. However, Lists of Beans ain't exactly the lightest thing in the world either.
+1
Even if the XML support for Nausicaa is not for yet
Gilles
OK, now that I understand the direction here, I like it.
+1 on this (but don't tell Ted we voted, ok?)
Larry
My vote : +1
And with W3C because it's a standard and beause related interface are included in Java distribution (package org.w3c.dom).