At 1:52 PM -0400 7/22/02, Aleksander Slominski wrote: >actually that is part of parser documentation, and for example >implementation XMLPULL API based on Xerces 2 XNI >will by default be XML 1.0 non validating so user will not need >to do anything (and trying to use it in "limited" mode and >incompatible with full XML 1.0 mode will be simply not supported)
Perhaps you are confusing validation with the reading of the internal DTD subset. They are related but are not the same thing. XML 1.0 specifically allows parsers not to validate. However, all parsers, validating or not, *must* read the internal DTD subset, use it to define internal entities and supply default values to attributes, and report any well-formedness errors detected therein. This is required, even of a non-validating parser. >> You have convinced me that pull >> parsing is a useful model in general, which I was extremely skeptical >> of before. However, I remain convinced that the existing parsers in >> Java and the XMLPULL API in particular are deeply flawed. Unless you >> are willing to reconsider the principles that underlie the design of >> XMLPULL, it will not become a suitable API for XML processing. > >u would say that current implementations are not meeting >your requirements ... No, I would say they are not meeting the requirements of XML 1.0. >> >i would like to ask that when making comments about XMLPULL API >> >to be precise if it is API that has flaws (this is serious problem!) >> >or particular implementation that needs fixing (that i think is >> >minor problem). >> > >> >> Noted. However, it seems to me that the flaws in API design and the >> flaws in implementation both stem from the same false preconceptions. >> In particular: >> >> 1. XML 1.0 correctness is negotiable >> 2. Size and speed are more important than a clean design >> >> Thus the flaws in the API and the implementations are very closely related. > >IMHO design of XMLPULL API is very clean and choices >were made to balance between easy to use API and >good performance _and_ small memory footprint and still >allow full XML 1.0 support - so API tries to do quite a lot! If that were accurate, we would not being having this conversation. XMLPULL as currently implemented does not provide full XML 1.0 support. The design choices you've made in the name of good performance _and_ small memory footprint have compromised full XML 1.0 support. >ultimately it is up to XMLPULL API users to decide if they >like API. I think that it's more than that. I do not expect API users to be experts in XML. I do not expect them to know every last nook and cranny of the XML 1.0 spec, just as I do not expect that users of java.net.Socket know every detail of the RFCs for TCP/IP. However, I do expect that the designers of the java.net.Socket class knew every detail of the RFCs for TCP/IP and designed the class appropriately so it can be used by non-experts. Similarly, I expect designers of XML APIs to know every last nook and cranny of the XML specs and to design their APIs so that they can be used by non-experts. I am distinctly concerned about bait-and-switch tactics of some APIs (XMLPULL is hardly unique here) which present XML as somehow easier or different than it really is. Users very well may choose an API based on which seems simplest for them, without considering or even knowing how to evaluate which API is most correct. Users will assume the API designer has done their homework and is offering them a correct model of XML. It is the responsibility of the API designers to see that users trust is not violated by correctly implementing the standards they claim to implement. -- +-----------------------+------------------------+-------------------+ | 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]
