[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ModSAX (SAX 1.1) Proposal
Clark Evans wrote: > I think it would be better to start with Requirements, > then some Analysis instead of jumping straight to Design. > > So that I'm not stopping the show, here are > nice things that I'd like to see: > > 1. A mechanism to include multiple observers > in parallel. If this dosn't already work. I think in Michael Kay's SAXON package he has some multicast DocumentHandler object that does just this. All it does is delegate processing to a list of DocumentHandlers. > 2. A way to register said observers for particular > events, e.g., an "event mask". Since SAX is based upon a callback API rather than some abstract event type, I am not so sure this is at all necessary unless things move the way Bill la Forge suggested with using event objects. I am particularly not in favor of the event objects approach because it is an extra layer of indirection in handling the parsed data that I don't think adds anything positive to SAX. > 3. Complete capababilities management. > > 3.1. I'd rather not ask the SAX driver if it > supports events X,Y,Z,P,D,Q. I'd like > a more "package" oriented mechanism. What do you mean by package oriented. If you talking about having special possibly inherited DocumentHandlers for each type of add-on, then I am all for it. This way you could have a NamespaceDocumentHanlder which would present namespace handled content to the application in an appropriate form. Changing the ParserFactory class to add additional static methods for location a NamespaceParser or an ExpandEntityParser or whatever would be totally backwards compatible. Of course the obvious problem with this is the interface explosion problem which would be a direct contradication to SAX's goal of being simple. > 3.2 Versioning of these packages and events. > > 4. Event stack support. I have done something like this before and it is particularly useful, especially for error-reporting. Of course the big problem with this is that you need to create new event objects to put on this stack. This would slow down many of the fastest XML parsers five fold. > Some of these are a bit far-out, but it's hard > to know what the "specific goals" of SAX 1.1 are. Probably roughly the same, or else it would need to change its name, "Simple API for XML" (-: Tyler 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/ and on CD-ROM/ISBN 981-02-3594-1 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
|