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
[EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
