Re: RELAX NG Marketing (was RE: Do Names Matt er?)
On Wed, Mar 27, 2002 at 12:29:33PM +0100, Nicolas LEHUEN wrote: > Like I wrote before, I don't think that trying to stuff as many features as > possible under the hood of the parser is a wise thing. I think we should > have a lean and mean parser API (SAX2) and lean and mean parsers (less than > 100 kb or JAR). Then, separated from the parser, you would have a lean and > mean XML tree API (DOM2 for compatibility, or dom4j for functionality), a > lean and mean XPath API (Jaxen), a lean and mean validation API (Sun MSV), a > lean and mean pipe building API, and so on and so forth. Nice rethoric, however: - it seems to only be centered around Java - SAX/SAX2 outside Java is a mess, especially for pure C - running a minimalist prime number algorithm on a Java machine seems anyway to use between 80 and 170MBytes of virtual memory usage see the Test1 report from http://www-106.ibm.com/developerworks/java/library/j-native.html So even if your jar is 100KB or even 1KB, I'm afraid you have trapped yourself into the bloat by the way of your "there is a single development infrastructure" premice, and much of the remaining arguments of your post don't make much sense. Unless I misunderstood, the Java performance report paper I point to, or the guy is very biased against Java (which look unlikeley considering it's an IBM developper work paper in the Java section). I will stick to C thank you, even if this mean that designing the code or API requires being a bit more careful. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@r... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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