XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

Can someone perhaps point me to material describing the detailed URI 
format of the baseURI string required by InputSource.setSystemId(String 
baseURI)? I didn't find much browsing around the web.

The reason I'm asking requires some background:
I worked on XOM extensions for a high-performance messaging environment 
using small XML messages. I started with dozens of messages/sec 
throughput, and after a lot of sweat have now reached thousands of 
messages/sec (even when turning on W3C XML Schema validation).

Following the mailing list discussion about the absence of base URIs 
when building from a stream, I switched some code from 
Builder.build(FileInputStream) to Builder.build(File file) to pickup a 
good baseURI. This seemingly innocent change killed performance. 
Before: 3000 msg/sec. After: 300 msg/sec.

Doing some profiling it turns out that the baseUri calculation in 
Builder.build(File) takes much more time than all of file I/O, parsing 
and validation combined. The reason is that Builder.build(File) use 
URLEncoder.encode(String.valueOf(char)) in a loop to compute the 
baseURI. To confirm that, try replacing the calculation with 
File.toURI().toString() or a combination of the code found in 
FileSource.setSystemID(File file) with URIUtil.toURI(...).

This eliminates the performance regression, but may perhaps not be 
quite correct (apart from the fact that java.net.URI requires JDK 1.4 
which is not a problem for me but may be for others). Hence the 
original question: Can someone perhaps point me to material describing 
the detailed URI format of the baseURI string required by 
InputSource.setSystemId(String baseURI)?

Here is a minimal snippet to reproduce this:

for (...) {
        //Document doc = builder.build(new File(fileName));
        Document doc = builder.build(new FileInputStream(fileName));
}

As an aside, the other thing i noticed is that URLEncoder.encode(char) 
replaces " " with "+" rather than "%20". This seems kind of weird in 
the context of file URLs, since file URLs never have space-separated 
name-value components. Plus, on MacOSX files containing spaces are 
legal.

Wolfgang.


-----------------------------------------------------------------------
Wolfgang Hoschek                  |   email: whoschek AT lbl.gov
Distributed Systems Department    |   phone: (415)-533-7610
Berkeley Laboratory               |   http://dsd.lbl.gov/~hoschek/
-----------------------------------------------------------------------