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

[email protected] wrote on 04/11/2004 09:48:20 PM:

> ----- Original Message ----- 
> From: "Michael Glavassevich" <[email protected]>
> To: <[email protected]>
> Cc: "Karl Waclawek" <[email protected]>; "Elliotte Rusty Harold" 
> <[email protected]>
> Sent: Sunday, April 11, 2004 3:33 PM
> 
> 
> > Elliotte Rusty Harold <[email protected]> wrote on 04/09/2004 
> > 08:48:03 AM:
> > 
> > > Perhaps this should be an option for parsers that wish to allow this 

> > > to be set. However, some parsers may not wish to make this an option 

> > > and prefer to make it a read-only property instead.
> > 
> > Based on the current javadoc for EntityResolver2, I believe this 
already 
> > is an option. It states: "If a SAX application requires the customized 

> > handling which this interface defines for external entities, it must 
> > ensure that it uses an XMLReader with the 
> > http://xml.org/sax/features/use-entity-resolver2 feature flag set to 
true 
> > (which is its default value when the feature is recognized). If that 
flag 
> > is unrecognized, or its value is false, or the resolver does not 
implement 
> > this interface, then only the EntityResolver method will be used." 
That 
> > sounds like read-write to me. A parser which recognizes the feature 
but 
> > doesn't support setting it to false should throw a 
> > SAXNotSupportedException.
> 
> If read/write was really the intended message, why did it not just say:
>  "must ensure that it sets the ... feature flag to true" instead of 
making
> the value dependent on the XMLReader instance with:
> "must ensure that it uses an XMLReader with the ... feature flag setto 
true".
> 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? 

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

Having the feature read-write buys you control over which of these methods 
the parser uses for resolving entities.

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.

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.
 
> 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]