Re: [Sax-devel] ues-attributes2/entity-resolver2/locator2 read-only?
Brought to you by:
dmegginson
From: Karl W. <ka...@wa...> - 2004-04-12 13:30:00
|
----- Original Message ----- From: "Michael Glavassevich" <mrg...@ca...> To: "Karl Waclawek" <ka...@wa...> Cc: <sax...@li...> Sent: Monday, April 12, 2004 12:33 AM > > If one can make an argument for read/write, one can make one for > > read-only as well. > > It says: "if the flag is unrecognized, or its value is *false* ... only > the EntityResolver method will be used". If this feature is truly > read-only, how could the value of the feature ever be false if its default > value is true when it is recognized? Good argument. Specifying a default really doesn't make sense when it is read-only. If anything, clarification is necessary. But read/write still doesn't make sense to me either. > > But the main issue is: what would read/write buy you? > > If you don't want EntityResolver2 methods called, then > > don't pass such a handler. > > Although EntityResolver2 extends EntityResolver, these interfaces really > seem to be mutually exclusive. The parser either calls > EntityResolver.resolveEntity(publicId,systemId) or > EntityResolver2.resolveEntity(name,publicId,baseURI,systemId) for > resolving external entities. Is it not possible to have EntityResolver2.resolveEntity() ignore the extra parameters and forwward the call to EntityResolver.resolveEntity()? > Having the feature read-write buys you control over which of these methods > the parser uses for resolving entities. I already have this control by setting the handler, which I can do even when parsing is active. > What if you use org.xml.sax.ext.DefaultHandler2 because it implements > LexicalHandler and DeclHandler? It also implements EntityResolver2 but > perhaps you don't care about DTDs and would rather not have the parser > waste cycles querying your resolver for external subsets. Perhaps you > cannot (and do not want to) use the new behaviour if your application is > stuck on JDK 1.3 or earlier without java.net.URI because you may not be > able to find an acceptable alternative for resolving a system id against a > base URI. I guess you'd just choose not to use DefaultHandler2, but why > should using this class be prohibitive? It's supposed to be a convenience > class. You can still use this class. Just override EntityResolver2.resolveEntity() to call the same implementation as EntityResolver.resolveEntity(). And yes, a few CPU cycles can be saved once per document. Not noticeable. > One approach for implementing an XMLFilter is to declare that the class > which implements this interface also implements EntityResolver, > ContentHandler, etc... org.xml.sax.helpers.XMLFilterImpl does this. > Additionally making the filter an implementer of EntityResolver2 may have > some side-effect that an external user of the filter might not want. > > I believe making use-entity-resolver2 read-only would eliminate some real > use cases. I wouldn't go that far. There may be slight convenience issues, but I haven't seen anything it prohibits me from doing. However, if you feel passionate about it, it really doesn't bother me if this feature were to be read/write, I just don't find it necessary. Karl |