OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX2: XMLReaderFactory

[ Lists Home | Date Index | Thread Index ]
  • From: jmbolles@ThoughtWorks.com
  • To: david@megginson.com
  • Date: Wed, 15 Mar 2000 14:09:45 -0800

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

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

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

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

Jack Bolles

                    Megginson            To:     xml-dev@xml.org                                             
                    <david@meggin        cc:                                                                 
                    son.com>             Subject:     SAX2: XMLReaderFactory                                 
                    Sent by:                                                                                 
                    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

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

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

Sounds OK?

All the best,


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/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS