[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Goals: XML Event Interface
I think that the time has come to deal with a question that we have postponed so far: the goal of a simple XML event-driven interface. Right now, there are two completely different ideas: 1. The interface will provide standardised low-level, pre-DOM functionality for parsers to implement, for programmers who do not want to incur the overhead of using the DOM; perhaps a DOM tree could be built using only these interfaces. 2. The interface will provide standardised high-level, post-DOM functionality for parsers to implement, for programmers who do not want to take the time to learn the XML concepts in the DOM; perhaps the events could be generated from a DOM tree. These two are actually quite incompatible: the first is an attempt to create a less abstract user model, while the second is an attempt to create a more abstract user model. It's only a (happy) co-incidence that we have managed a broad agreement so far. LOW-LEVEL INTERFACE ------------------- If we decided on (1), then I would consider making the interface the core interface for Ælfred, and I would probably want to expand it slightly to include enough functionality to build a basic level-1 DOM tree, by adding some or all of the following information: - an event for the doctype declaration - an isSpecified flag for attributes - ignorable whitespace (Ælfred should return this anyway) - comments (yech -- _WHY_ is that in the DOM???) This interface could use only JDK 1.0.2 features, since I have no intention of making Ælfred incompatible with existing browsers. HIGH-LEVEL INTERFACE -------------------- If we decided on (2), then I would simply produce an optional add-on for Ælfred, outside of its core interfaces (and probably in a separate package). I would probably make a pass-through class implementing (the new) XmlProcessor instead of having Ælfred implement it directly, so that the core Ælfred could still consist of only two class files. In this case, the simple interface would be slightly less efficient, and would include only very minimal functionality (as Tim suggests); for anything more, you would have to use each parser's native interface. You could not build a DOM tree using this interface. The question would remain open whether the simple interface could use JDK 1.1 or JDK 1.2 features. 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
|