xml-dev - Re: Parser Interface -- Summary of Change Requests

[David Megginson <ak117@freenet.carleton.ca>]

Don Park writes:

 >     public InputStream
 > getEntityByteStream (String systemID)
 >     throws Exception;
 > 
 >     public InputStream
 > getEntityCharStream (String systemID)
 >     throws Exception;
 >
 > The parser implementation should invoke getEntityCharStream first to see if
 > the there is decoded data available.  If not, it should invoke
 > getEntityByteStream to get the raw data.
 > 
 > If both methods return null, then default URL based code is used.

I like the general idea, though there are implementation problems.
Many languages (including Java 1.0.2) have no concept of a character
stream at all, and in Java 1.1, you would have to use

  public Reader getEntityCharStream (String systemID)
    throws Exception;

 > >   This seems like a generally good idea (as will as a simple and
 > >   backwards-compatible change), and I am willing to implement it.
 > >   The only complication is that we'll have to define the default
 > >   state -- is the parser always required to return a default handler
 > >   if the user has not explicitly set one, or should it return null?
 > 
 > It would be up to the SAX implementation.  It might provide default
 > implementation depending on configuration.  For example, FooSaxDriver might
 > have setInputType() method which would install a default EntityHandler for
 > fetching XML document from a database.

This might make life a little trickier for programmers using SAX --
what do others think?


 > BTW, You left out my other suggestion which was
 > 
 > >>>>>>>>>>>>>>>>>>>>>>>>
 > In addition, I would like to have following two methods added to the Parser
 > API for driver-specific operations:
 > 
 >     public Object getDriverProperty(String name);
 >     public Object setDriverProperty(String name, Object value);
 > 
 > Property names should be prefixed with some unique values to avoid confusing
 > other drivers.  Note that above methods can be invoked without knowing which
 > driver is actually being used.  For example:
 > 
 >     parser.setDriverProperty("SuperDriver.lowercaseElements", Boolean.TRUE);
 >     parser.setDriverProperty("HungryDriver.cacheSize", new Integer(100000));
 > <<<<<<<<<<<<<<<<<<<<<<<<
 > 
 > Above two methods allow driver-specific code without actually having to
 > import anything.

Sorry about the omission.  I'd be interested in hearing other
reactions to this suggestion -- I'm worried that it would result in
SAX implementations that are non-conformant XML processors (as in your
first example), or that are incompatible with each other.  Remember
that SAX defines only a minimum level of compatibility among XML
processors.


All the best,


David

-- 
David Megginson                 ak117@freenet.carleton.ca
Microstar Software Ltd.         dmeggins@microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)