XOM API for Processing XML with Java

[John Cowan <jcowan AT reutershealth.com>]

Elliotte Rusty Harold scripsit:

> I'm thinking about this. It's possible XOM will add something like 
> this. However, if I do it would have to be more careful not to 
> override the features and properties that the Builder wants set a 
> certain way. For instance, I think your patch would allow the user to 
> turn off loading of the external DTD subset.

Why not?  Granted, such a parser will not pass the test suite, but
it may have utility in appropriate circumstances.  If you are trying
to process documents from a variety of sources that come in over the
transom with possible external subsets, which you do *not* wish to
depend on, then turning off external subset loading is very sensible.
You may fail to get the default attributes that the author expected,
but the documents will at least be processable.

> But I am seriously considering adding a feature/property interface to 
> the Builder class that would allow setting and getting individual 
> features, while filtering out requests to reset features and 
> properties XOM depends on such as entity-resolution.  

It is not XOM that depends on this property, but the test suite.  If the
programmer in his wisdom or unwisdom decides not to do entity resolution,
why should he be overridden?

> This would mean in the future I could use a 
> different non-SAX parser/API such as StAX or XNI if that seemed 
> useful.

This I agree is a Good Thing, but it can be achieved by providing
alternatives to Builder.

> More immediately, it would help XOM enforce the use of Xerces, which 
> I'm seriously considering. 

I do most strongly urge you *not* to do this.  One of the great virtues
of SAX is that it's straightforward to write SAX parsers that accept
formats other than XML, and then allow the rest of the application
to treat the input as XML.  There are already some very interesting
SAX parsers out there: one that accepts WIN.INI format, for example.
It would be easy to convert parts of Jing into a SAX parser for DTDs or
for RELAX NG compact syntax.  I have myself written a SAX parser that
understands phpwiki syntax and reports it as XHTML.  Because SAX is
interface-based, making such parsers hot-pluggable is trivial.

Such facilities should be available to the XOM programmer as well as to
the pure SAX programmer.  By all means make Xerces the default, but not
the only possible source of input.

> becoming obvious to me that most SAX parsers are seriously broken; 

In some circumstances, speed is simply more important than conformance
to the last detail of the XML Rec.  XOM should not make the use of fast
buggy parsers impossible.

-- 
Where the wombat has walked,            John Cowan <jcowan AT reutershealth.com>
it will inevitably walk again.          http://www.ccil.org/~cowan