[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Some notes on the binxml permathread (was: Re: Parsingefficien
Dear deviants, a few hours only into the thread and already we are re-hashing old ground. Here are some notes (foolishly) hoping to avoid covering too much littered and dead ground. - "Binary XML" is an oxymoron. There is no such thing, and most likely will never be. Whatever binarisation scheme you use you're binarising an infoset. - Debates as to whether it should "happen" or not are moot: it's already happened. You may not have seen it yet, but binary infosets are used in many areas and it's probably too late to stop them if you want to. ISO/MPEG, 3GPP, ARIB, DVB, DAB, TV Anytime... this is just a small sample of organisations I know off the top of my head to be investigating (with the intention to use) or using binary infosets, and then you have the list of companies. These uses are not meant to happen in closed systems either. Thus, more interesting questions are imho: Should we find a way of standardising it before we have an interop nightmare (and before so many people are interested in it that it becomes impossible to not produce bloat)? In which cases is it ok to use it? Can a binary infoset be considered an "encoding" of XML, or is it something completely different (MIME-wise)? Should binarisation be done by Textual Fanatics or left up to the object-serialisation-everything-is-typed people? ("yes", "whenever it solves an XML-related problem", "tough question", "the former of course") - On this topic, one frequently hears broad statements from list members of the type "It won't give you any speedup", "XML parsing is never the bottleneck", "gzip compression beats anything else/is good enough", etc. Where it concerns low- to medium- performance applications running on reasonably powerful boxes, those are true (apart from the "gzip beats anything" one of course). That, however leaves open high-performance apps, and lower-power devices. Two big areas. I would very much appreciate it if people believing that these statements hold in those two cases were to provide empirical data, because it very flatly contradicts mine. And of course those statements do not cover requirements relating to streaming, packaging, fragmenting, random access... - The "Don't use XML then" argument also comes up quite frequently. In some cases, it's right on -- XML should clearly only be used when there's a benefit in using it. In others it's quite hard to buy. If you have a workflow in which nine steps out of ten use XML and reap great benefits from it (many existing tools, open, proven, powerful, interoperable, low coupling, many developers, standard APIs...) but one in which it proves to be unusable, you basically have two options: . Reinvent it all. You throw away all the tools, all the knowledge, all the interop, all the reliability, all the goodies, etc. and recreate them all to be ad hoc to your system. Why? Because you are using XML for something "it wasn't designed for" and any other option will get Hans Blix on your ass. Yes, people do use this argument on occasion. . Keep it the way it is, but find a way to solve the issues you have in that one step. This can, in some cases, involve binary infosets. You lose nothing for the nine other steps, and binfosets can be made to quack like XML so that your workflow isn't disrupted. I'm probably forgetting a number of points, but hopefully these will help :) -- Robin Berjon <robin.berjon@e...> Research Engineer, Expway http://expway.fr/ 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
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
|