Re: Parser Interface -- Summary of Change Requests
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@f... Microstar Software Ltd. dmeggins@m... http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format