[
Lists Home |
Date Index |
Thread Index
]
- From: David Megginson <ak117@freenet.carleton.ca>
- To: xml-dev Mailing List <xml-dev@ic.ac.uk>
- Date: Sat, 3 Jan 1998 20:32:22 -0500
[SAX is a proposal for a simple, event-based XML API, using
callbacks. This is one in a series of ten design questions that we
need to answer to implement the API.]
So far, all of my questions have related to the callback interface
(XmlApplication); should SAX also include a simple interface for the
parser/processor itself, like the following?
public interface XmlParser extends java.lang.Runnable {
public void setDocumentSystemID (String systemID);
public void setXmlApplication (XmlApplication app);
public void run ();
}
(We would also mandate a zero-argument constructor, but there is no
way to enforce that with the interface.) Implementations might also
provide additional convenience constructors to set the systemID and
app directly.
CONS
----
- this interface constrains the parser writers to use the same
invocation methods;
- it will be necessary to write separate frontends for some parsers to
implement this functionality;
- extending java.lang.Runnable is Java-specific, and the concept may
not translate well to other languages.
PROS
----
- it will be simple to substitute parsers dynamically;
- it will be simple to start a parser as a new thread;
- most users will not have to know the details of different parser
implementations.
MY RECOMMENDATION
-----------------
Yes (strongly).
In Java, this approach will be especially powerful, because
applications can allow users to choose their own parsers at run time
(even if the application writer has no knowledge of that parser).
Assume, for example, that the variable 'parserOfChoice' contains the
class name of a user's preferred parser:
Class parserClass = Class.forName(parserOfChoice);
XmlParser parser = (XmlParser)parserClass.newInstance();
parser.setDocumentSystemID("http://www.foo.com/test.xml");
parser.setXmlApplication(myApp);
parser.run();
Note that the zero-argument constructor is required for this sort of
approach.
It will also be trivial to start the parser as a thread:
Thread parserThread = new Thread(parser);
parserThread.start();
OTHER CONSIDERATIONS
--------------------
It might be useful to have corresponding getDocumentSystemID and
getXmlApplication methods, but since they are not absolutely
essential, it might not make sense to mandate them in the interface.
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)
|