RE: Images embedded in XML
4/8/01 4:54:50 AM, "Al B. Snell" <alaric@a...> wrote: >This is a bit of a myth... plain text is less of a common demoninator >than two's complement or unsigned binary integers, since plain text is >described in *terms* of this, and XML is far from a simple "lowest common >denominator" data format; it would take me a few minutes to write a set of >routines in C to serialise and unserialise data in network byte order, and >perhaps an hour at most to implement this for a self-describing >format. Compare that to how long it takes to implement an XML parser, and >the size and run time space/time requirements, and the size of the XML >documents compared to the "XDF" records... IMHO that's an extremely unfair comparison. I very much doubt that in a few minutes you could come up with a reliable, tested, general-purpose data serializer, as opposed to a quick application-specific hack. Most of the time spent writing an XML parser isn't spent on bare-metal coding; it's spent on the less geeky aspects of programming like testing, requirements analysis, API documentation and development (the API that's only for your own personal use is always the easiest to develop, since you already have it internalized), design for maintainability, and maintenance. It's like the way geeks always ridicule the (very well documented) statistic that if you divide the number of lines of code a programmer writes over the span of a project by the total time he or she spends on the project, you get about ten lines of code per day. The catch is that the typical programmer spends most of his time on activities other than writing lines of code (even though those activities, such as requirements analysis, may eventually contribute to writing code). The time to develop and produce a program is always a lot greater than the time to code it). Application-specific hacks are always more efficient than general-purpose libraries when the entire project is under the complete control of a lonergeek cowboy coder who gets to define all the requirements himself and who's going to be the only person ever to look at the code. In the real world, things are a little different. > >Since parsing XML is complex, XML's adoption will be limited by the >development rate of XML parsers... I have heard a few people say "Ah, I >can write an XML parser in 10 lines of Perl", but those parsers don't >process entity references or handle namespaces :-) But parsers that do all that are easily available to any competent Perl programmer, who doesn't have to write the parser, only use it. The only problems arise when the Perl code is supposed to run on some el-cheapo rented Web host whose admin doesn't even understand how to install Perl, IOW under extremely penny-wise and pound-foolish conditions. > >> Either you do >> without compatibility between systems or you sacrifice a bit of speed. > >Only a tiny smidgen... many CPUs can do network / host byte order >translation in a single instruction; compare that to the time taken for an >XML parser to locate a text node by stepping through to find delimeters, >then removing the whitespace and converting from UTF8-decimal to an >integer in host byte order... You're thinking in terms of saving CPU cycles. In the Real World, most of the time isn't spent executing (cheap) instructions; it's spent by (expensive) people trying to solve "impedance mismatches" between two organizations' notions of what their data should look like. Once again, XML has few advantages in systems that are entirely under the control of a lone coder. The advantages come into play when you have to exchange data with multiple organizations; sure writing low-level conversion routines to handle it is fun geektoy stuff, but you're ignoring the non-geeky stuff like maintaining and documenting all those conversion routines. And let's not forget the *social* aspects (the ultimate non-geeky stuff) of data interchange. When several unrelated organizations, or even departments within an organization, need to exchange data, there's an enormous advantage to using a data format that was created by a third party rather than by one of the players, namely that there's no rivalry over *which* player gets to create the format. Again, if one party could simply impose a format by fiat, everything would be cool, but in real life, if you don't get full "buy in" from all the players, you're going to see a lot of friction (usually in the form of "creative incompetence" where everybody's implementations differ in slight but important details) that will dissipate a lot of energy as heat. Yes, this falls into the realm of what hardcore geeks would call "touchy- feely" stuff, but the fact is that psychological/verbal/non- quantitative/stereotypically-female/"touchy-feely" considerations play important roles in any real-life human endeavor involving more than one person, and the fact that one might be more confortable with bits and chips than with human interactions doesn't change that reality.
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