[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RFC: Simple XML Event-Based API for Java
David Megginson wrote: > After careful thought, I am fairly certain that I would be willing to > accept the following simple event-driven API for Ælfred. I don't see the point of the XmlProcessor first argument. What's wrong with having the implementation of XmlApplication store the XmlProcessor in the member variable? (This is what SP typically does.) > public void > startDocument (XmlProcessor processor, String pubid, URL sysid); What do the pubid and sysid arguments represent? The document entity? > public void > startProlog (XmlProcessor processor); > > public void > endProlog (XmlProcessor processor); Why do you need startProlog() and endProlog()? > public void > startElement (XmlProcessor processor, String elname, > Dictionary attributes); > > public void > endElement (XmlProcessor processor, String elname); > > public void > characters (XmlProcessor processor, char ch[], int start, int length); > > public void > processingInstruction (XmlProcessor processor, String target, String data); The one major omission I see here is absense of information about the location (URL, byte offset, line number etc) of the events. It would be very nice to be able to implement validation as just as an XmlApplication (that wraps around another XmlApp). In others to to run without validation you would use: processor.run(new MyXmlApplication()); and to run with validation you would use processor.run (new ValidateXmlApplication(new MyXmlApplication)); In order to make this work the application needs to be able to get information about the location of start/end tags and of data. This is also useful for all kinds of application-specific validation. This could be done by having the app ask the processor for the location of the last event in some non-standardized way, but that's kind of kludgy. On the other hand, maybe this is just too fancy for a "simple" API. > public void > error (XmlProcessor processor, String message, URL url, int line); I don't think having simply "String message" is going to internationalize well. It's also desirable to know exactly what character number/column number the error occurred at. Also XML distinguishes fatal errors (which the parser must not continue processing after) from other errors. On the whole I would be inclined to handle fatal errors as an exception, and not try to deal with non-fatal errors at all in this simple interface. > On the positive side, this interface would let you hang more than one > application off the same parse, which could be very interesting. I don't think this is a good idea. It adds complexity and it's likely to impose a performance cost, but it doesn't buy you anything, because you can achieve that functionality with a MultipleXmlApplication class that implements the XmlApplication interface, and provides addApplication and removeApplication methods, and then forwards each event to the applications that have been added to it. > The > userData property also gives users a chance to pass extra information > to the processor easily, if they wish. Surely there are cleaner ways to do this sort of thing. James 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
|