At 10:26 PM +0200 7/22/02, Stefan Haustein wrote: >as said earlier, I had started in kXML 1 with event objects >and polymorphism. It just turned out to be not to very useful >when actually using the API, since the different event types >do not have very much in common. Instead, unneccessary >overhead and code bloat was caused in applications >that are using the parser.
You're bringing up a different issue, which is whether the design of XMLPULL is clean and object oriented. As you know, I think it's not. However, this is completely orthogonal to the question of whether XMLPULL and its implementations correctly support XML 1.0. You could fix all the OO problems and still not correctly implement XML 1.0; and you could fix all the errors in XML parsing and still not have clean, OO interfaces to the parser. Both are problems with the existing API. Both would be helped by competition from independent efforts to develop a pull parser. >You can easily verify this by converting the simple >XML-RPC parser example available at http://kxml.org in the >samples section to an imaginatory event object based >pull parser of your choice. One example would prove little. You need a broad range of problems to see how well the API fits the uses to which XML is put. Right now I'm working on what I think will be the first correct tree-based API for processing XML. (More about that on September 17 in New York.) As part of the testing I'm rewriting every single example in Processing XML with Java to see how well the API works. That's shown me a number of ugly areas in my API that I've had to redesign. When I eventually throw this out to the public, I'll then have to consider all the use cases everyone else comes up with and see if any of those indicate a need for redesign. One thing I have not done yet, and will not do until the API is stable, is any optimization. To quote Donald Knuth, "Premature optimization is the root of all evil." Once I am convinced the API is correct and complete, then and only then will I do profiling to discover where the speed and space problems are. At that point, I'll fix them. Before I can do this, I have to make the code right. Making the code fast before you make it right rarely makes it any faster and almost never makes it right. > If the XMLPULL design is flawed >as you claim, it should be easy to sketch a better >API that does not just sound more OO but also justifies >the extra object by making application code using the >parser better readable. > I'm certain it is; and I may yet do this one day, though right now I'm busy with tree-based APIs. The most important issue is to stop having so much awareness of state in the parser. XmlPullParser has way too many methods that only work some of the time, and it's up to the client programmer to figure out which methods work when and where. Very ugly. A clean API would both make the application code using the parser more readable and make it easier to write that code in the first place. -- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML in a Nutshell, 2nd Edition (O'Reilly, 2002) | | http://www.cafeconleche.org/books/xian2/ | | http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.cafeconleche.org/ | +----------------------------------+---------------------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
