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

[email protected] wrote on 04/12/2004 09:29:39 AM:

> 
> ----- Original Message ----- 
> From: "Michael Glavassevich" <[email protected]>
> To: "Karl Waclawek" <[email protected]>
> Cc: <[email protected]>
> Sent: Monday, April 12, 2004 12:33 AM

<snip/>

> > > 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()?

Only if your application is able to resolve the systemId against the 
baseURI. The systemId parameter passed to EntityResolver.resolveEntity has 
been absolutized by the parser. The systemID parameter passed to 
EntityResolver2.resolveEntity may be relative, pushing the burden of 
absolutizing it to the application. This is fine if there's a public API 
available like java.net.URI, but if one is isn't available I doubt the 
average user would be eager to write a parser for RFC 2396. The SAX parser 
already needs to know how to resolve URIs for EntityResolver. If the 
absolutized system id were passed to EntityResolver2.resolveEntity, in 
addition to the literal system id and base URI, applications would not 
have to be responsible for resolving system ids.

> > 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().

Sure if you can resolve the system id yourself. See my previous comment.

> And yes, a few CPU cycles can be saved once per document. Not 
noticeable.
 
<snip/>
 
> 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

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]