Why a 1.0 configuration is not enough and a property is required

[Elliotte Rusty Harold <el...@metalab.unc.edu>]

At 6:05 PM -0800 11/21/03, Arnaud Le Hors wrote:
>Andy Clark wrote:
>>  However, it
>>  would be nice to have a setting that allows people
>>  to make Xerces strictly enforce a specific version
>>  over another.
>>
>
>If somebody really wants this he/she can always have his/her own 
>configuration I suppose. But I don't see any use case for this so I 
>wouldn't spend resources on this.


The custom configuration neatly solves my needs. However, last night 
I realized why it doesn't solve everyone's. Consider this:

Currently when the Java class loader loads the Builder class it sets 
the XMLParserConfiguration property to point at XOM's custom 1.0 only 
configuration. This guarantees that XOM will get the 1.0 features it 
requires. Good.

However, because System properties are global it also ensures that 
all other uses of Xerces within the same VM are also going to pick up 
XOM's configuration. They may not want this. They may want a 1.1 
savvy parser, or they may even want a different configuration for 
completely different reasons having nothing to do with the difference 
between 1.0 and 1.1.

The configuration needs to set on per-parser basis. Each XMLReader 
object should be able to set its own configuration independent of the 
configurations used for other XMLReaders. Currently, I don't see any 
way to do this from SAX. Perhaps there's a way to do this from XNI, 
but even if there is, this requires asking authors to tie their code 
to Xerces specifically rather than programming to the generic SAX 
interface. For more discussion of why this is a bad thing see Item 31 
of Effective XML, Program to Standard APIs, 
http://www.cafeconleche.org/books/effectivexml/chapters/31.html

The simplest way I've though of to allow individual XMLReaders to 
have their own configuration is by setting a SAX property. For 
example,

XMLReader parser = XMLReaderFactory.createXMLReader();
parser.setProperty(
   "http://apache.org/xerces/properties/ParserConfigurationClass",
   "com.elharo.xml.MyParserConfiguration");

This is much more granular than the existing all or nothing scheme. I 
think this would be useful to anybody who needs a custom parser 
configuration for any reason. It would not interfere with the 
existing API at all. The only complexity increase would be a few more 
paragraphs in the Xerces features and properties page.

The one doubt I have about this is whether it's possible to change 
the parser configuration after the parser has been instantiated. If 
it is, then this is straight-forward to implement.If it's not, then 
more thought would need to be applied to how to make that possible, 
and it wouldn't be such an easy fix. But I still think it's an 
important one. Per-VM parser configuration just isn't granular enough.

-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml            
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org