Re: ues-attributes2/entity-resolver2/locator2 read-only?

----- Original Message ----- 
From: "Michael Glavassevich" <[email protected]>
To: "Karl Waclawek" <[email protected]>
Cc: <[email protected]>
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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
List: sax-devel, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel