xml-dev - Re: SAX2: XMLReaderFactory

[jmbolles@ThoughtWorks.com]

If createXMLReader() is meant to be a standard call that all can rely on,
then it doesn't make sense to allow this. If I set the system property
"org.xml.sax.driver", I would always expect it to be used if I called
createXMLReader().

I'd rather see a separate method, either implicitly -
createXMLReader(boolean useDefault)  - or explicitly -
createXMLReader(String[] args) - directing the use of environmental
properties.

As a bonus, the latter allows greater flexibility if you want to give the
factory intelligence about the XMLReader it returns, and is consistent with
the command line orientation mentioned in the javadoc comments of
XMLReaderFactory.createXMLReader():

     "Attempt to create an XML reader from a system property.

     This method uses the value of the system property "org.xml.sax.driver"
as the full name of a Java class
     and tries to instantiate that class as a SAX2 XMLReader.

     Note that many Java interpreters allow system properties to be
specified on the command line."

The current XMLReaderFactory can either ignore these methods, internally
calling createXMLReader(), or make them abstract if you want to go that way
(see below).

It also goes against normal java naming convention. Usually the interface
is called Foo, the abstract implementation is abstractFoo, and any default
implementation is DefaultFoo;

In other words, DefaultFoo extends AbstractFoo implements Foo; not Foo
extends DefaultFoo.

Regards,
Jack Bolles



                                                                                                             
                    David                                                                                    
                    Megginson            To:     xml-dev@xml.org                                             
                    <david@meggin        cc:                                                                 
                    son.com>             Subject:     SAX2: XMLReaderFactory                                 
                    Sent by:                                                                                 
                    owner-xml-dev                                                                            
                    @xml.org                                                                                 
                                                                                                             
                                                                                                             
                    03/14/00                                                                                 
                    02:28 PM                                                                                 
                                                                                                             
                                                                                                             




David Brownell writes:

 > > So what you want, I think, is simply a statement to the effect that
 > > it's OK to build your own XMLReaderFactory with the same class name
 > > and shadow the existing one?
 >
 > I want the "get the default parser" factory methods to permit using
 > environment-specific intelligence, rather than to preclude it as you
 > now do.  (I'm not sure what you mean by "shadow".)

I think we mean the same thing.

 > That's "just" a specification change, not a syntax change.

Here's what I'm going to do:

1. I will rename the current XMLReaderFactory to
   DefaultXMLReaderFactory.

2. I will create a new XMLReaderFactory that simply inherits from
   DefaultXMLReaderFactory, with a note that implementors are free to
   substitute their own class with the same interface for different
   requirements.

That means that an application can just use XMLReaderFactory to get
the implementation's behaviour (whatever it is), or can use
DefaultXMLReaderFactory to be certain that it's getting the current
behaviour.

Sounds OK?


All the best,


David



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************