[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The Message I Accidentally Sent To Mike Champion Rather Than The List
Quoting Michael Champion <mike.champion@s...>: > > it's trivial to write something that compresses better > > Undoubtably true, but will the difference make a difference? Can you > make a > business > case that someone will get more happy users for the actual product by > writing > something > that compresses x% better than an off-the-shelf generic technology? We had that discussion before, I was just refuting a statement :-) > The > success of the HTTP/HTML is probably due to the economy gained by > ignoring > many of the nasty problems that previous hypertext proposals handled > "better". > And the he bankruptcy courts are clogged with companies that had a > "better" > solution to a problem that people didn't care about strongly enough to > actually pay to have solved. "Worse is better" may be lousy technology, > but > tends to be good business, and engineering is all about making > appropriate > tradeoffs between the two. I'd phrase that as "there is more to a system than pleasing the programmers" Commercial factors matter too, as does making the result provide meaningful features to the users. However, XML is very low level; users will not care about the format of the data files unless they're power users, or the data format's output are significantly larger than they have to be and cause data storage requirements / processing times to rise beyond acceptable limits. The results of a particularly nice data representation toolkit in giving developers more time to work on other things may indirectly affect the users, of course. But when people tell me that text formats are more popular than binary formats due to some idea of increased ease of implementation, I suggest they implement a (validating!) XML parser and take a look at the binary executables, images, zipfiles, and so on in their binary filesystems :-) Even in the text-manipulation-tool-rich Unix world, application data files are as often binary as textual. Gnucash has moved over to a gzipped-XML format, but there have been some complaints coming up now about load times; last time this was discussed it was decided that the XML format would probably have to go at some point in the future, to be replaced by something seekable; you shouldn't need the whole file in memory. Gzipped XML is interesting. They are often smaller than the equivelant binary encoding, but the equivelant binary encoding isn't representing the "body text" any differently to the XML (unless it's really an integer or something like that written out in decimal); people should compare gzipped XML against the gzipped binary file, not ungzipped binary against gzipped XML. Duh. The deflate algorithm used in gzip is incredibly complex to understand and is nontrivial to implement. It requires special tools to access. gzipped files are not human readable. Does everyone here actually know how deflate works? I can post a summary if you're interested in what you're actually using as part of your efficient, simple, understandable-by-anyone data interchange format :-) ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software
|
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
|