"Right" way to mix SAX and DOM in app

Question

I'm writing a standalone desktop application that reads and stores data as XML files. Eventually, it might be converted to use some web services, but it's not a priority right now.
What I need to do is to use an XML file, which could be large, as kind of a database -- there are many entries, each with a unique identifier, and the application will query the file to find those it needs to match and returns those as objects I'm mapping.
At the moment, because this is a personal project and I'm using it to learn more technologies, I'm trying to (somewhat artificially) restrict myself to the pure Sun APIs. So far, my investigations have pointed to JAXP (by including Java EE 5 libraries) with StAX (including JAX-WS). Which raises two questions:
1) To do this "right", do I really need to bundle my app with the entire JaveEE+Metro stack?
2) Is there a better solution than StAX that's fully Java 5 compliant, even if it means stepping out of the Sun box? I haven't found many references to other solutions that are more recent than 2004. Is parsing XML on an app that has nothing to do with an appserver that uncommon?

Answer 1

More likely than not, I won't be abstracting to that degree. If the current structure isn't right, I'd update the app instead of storing that kind of information in more files.
I imagine at this point an example would be more effective. The app is itself more of an inventory browser that can jump around different searches dynamically. As an illustration, imagine that it's an inventory for DVDs. One central file will be your collection (with each entry containing a movie ID, date of purchase, etc). Another file would be more static, a list of DVDs themselves. These entries would contain information about the package itself -- how many discs? What's the title of the package? Which special features does it have? It would also point to an entry in yet another file which would have information about the film, containing biographies of the people listed under the movie credits.
Basically, I want a flatfile database that I can do joins on that are split up into different files. There are few files (here, one) that will be constantly updated by the user. The others could be modified if needed, but it's not going to be optimized for it. (For example, you could own a DVD that nobody's ever heard of, and put in the info yourself.) Periodically, one or more of the more static files is updated and will be downloaded into the app.
One of the advantages I see for this is that, in the future, I could with few changes turn this into more of a web service. Instead of pushing changes in those few files, the app would look to a web service for the data it would now find in files on the user's hard drive. But for now, it also has to be one standalone package.
To answer the question, the file that will most commonly be updated by the user is the one that I don't have problems loading into memory in full. It's the other data that it links to which I want to be able to search and load into objects dynamically. My current implementation is to run the file through SAX and grab the data as it sees it, but it's really ugly. That could very well be how I'm using it and not because I'm trying to shoehorn some functionality into a technique it doesn't fit, but I'd like to find that out. ;)