XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

On Oct 28, 2004, at 9:56 AM, Elliotte Harold wrote:

> Wolfgang Hoschek wrote:
> > That's primarily to keep the number of methods in the API to a 
> > minimum. The underlying internal code can take InputStream as well 
> > (besides other formats). The BuilderPool can only take arguments that 
> > can be identified uniquely (for caching to work), so an InputStream 
> > won't work for BuilderPool, while it works for BuilderFactory.
>
> I don't see why that's so. Are you caching the built documents so that 
> if someone builds from the same File twice, they'll get back the same 
> Document object without rereading the file?

BuilderPool is caching a MSV Builder keyed off an identifier, in this 
case the file path being the identifier.

If you ask for a MSV Builder for the same file, you'll get a cached 
builder for that schema file, otherwise a Builder will be created with 
the schema compiled from the file, and then returned. The effect is 
that getMSVBuilder returns *instantly* on cache hit.

One could have a BuilderPool.getMSVBuilder(ResourceResolver resolver, 
String resourceName) to work around it but 
BuilderPool.getMSVBuilder(File) seems mostly sufficient.