Elliotte Rusty Harold wrote: > 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.
that is well defined in XML 1.0 and that is why i have said that XMLPULL API has mode in which it incompatible with full XML 1.0 (validating or non validating) but allows small and efficient implementations that for example works well in J2ME environments (so in this context limited subset XML and not full XML is desirable and even required so API makes it possible). this is choice we made in API to support full spectrum of implementations from J2ME up to J2EE. > >> 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. i do not agree - current XMLPULL API _has_ XML 1.0 compliant mode (as it exposes XML infoset) just that there are different modes in API and implementations may be only supporting non full XML 1.0 compliant mode. therefore i would not say that specialized implementation compromise anything - we just made informed choices when creating implementations ... > >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. to make things absolutely clear: XMLPULL API can expose to the user full XML 1.0 infoset - there is no limitation in API that i know about ... > 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. users does not have to assume anything as everything is documented (in future we will try to make better job though of explaining difference between API and what exactly implementations are providing). thanks, alek --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
