[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


binxml video performance
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.