This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes XML and Related Technologies and the fly likes large amount of information Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » XML and Related Technologies
Bookmark "large amount of information" Watch "large amount of information" New topic
Author

large amount of information

Brendan Kennedy
Ranch Hand

Joined: May 02, 2001
Posts: 65
I want to use (java)XSLT as a way of displaying results from a search. Is it faster to use a SQL database and then convert the results to XML, or use a large XML file, or use many small XML files?
The information base will eventually be very big, so I am wondering what is the best way to store it if I'm always going to be using XSLT for my front end.
On an unrelated topic, does anyone know if the Whitespace problem of JAXB(it removes all whitespace when you unmarshal your doc) has been fixed yet?
Best Regards,
Brendan
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
Originally posted by Brendan Kennedy:
I want to use (java)XSLT as a way of displaying results from a search. Is it faster to use a SQL database and then convert the results to XML, or use a large XML file, or use many small XML files?
The information base will eventually be very big, so I am wondering what is the best way to store it if I'm always going to be using XSLT for my front end.

For me to search a 3.46MB XML file which has 36,345 nodelist using SAX took 2.645 secs.
my xml strcuture looks like this
<root>
<data>
<name>foo</name>
<desc>foo desc</desc>
<data/>
...
...
</root>
I'm searching for <name> value match.
Just FYI.


Spritle Software Blogs
Jayadev Pulaparty
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
Balaji,
A little question i have in this context. What are the exact driving conditions for employing SAX/XSLT/DOM as our approach for extracting the results? I know that DOM is very memory-exhaustive, but isn't it that XSLT also builds a DOM tree and then carrys out the transformation? To implement the SAX search mechanism to extract the required info(while breezing past the xml document)can become very tricky. Isn't that so?
Please clarify,
Thanks.
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
Originally posted by Jayadev Pulaparty:
Balaji,
A little question i have in this context. What are the exact driving conditions for employing SAX/XSLT/DOM as our approach for extracting the results? I know that DOM is very memory-exhaustive, but isn't it that XSLT also builds a DOM tree and then carrys out the transformation? To implement the SAX search mechanism to extract the required info(while breezing past the xml document)can become very tricky. Isn't that so?
Please clarify,
Thanks.

Thats a difficult question for me ,which myself trying to figure out for a long time.
At present i'm using SAX for VERY large XML documents and DOM for small document.At present i'm learning SAX API for searching XML,so will get back to you soon on my problems.
Posted by:Jaya:I know that DOM is very memory-exhaustive, but isn't it that XSLT also builds a DOM tree and then carrys out the transformation?
I'm not sure whether XALAN uses DOM tree for transforming XML, but i found FOP processor uses SAX Api for transforming XML in to PDF using xsl:fo. FOP inturn uses jars from Xerces,Xalan,batik etc., This document on XALAN may help you http://xml.apache.org/xalan-j/design/design2_0_0.html#overarch
They might be some article on this,would someone please share with us. ?

Thank you.
Regards
Balaji
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: large amount of information
 
Similar Threads
Sample Questions--Part A
DOM
Viktors 141 Sample Test: Question 29
XSL Page break
More questions.