Re: "Binary XML" proposals

[Al Snell <alaric@alaric-snell.com>]

On Tue, 10 Apr 2001, Christian Nentwich wrote:

> > Absent some good strong empirical evidence, neither processing
> > nor storage cost are a priori arguments for going binary.
> 
> That's a very PC centric statement. Some platforms can't handle
> compression algorithms or even parsing.

Indeed. Too many people say (about all sorts of things) "It's not worth
wasting programmer time on making it fast - just get it out the door quick
so we can start implementing it". "More haste, less speed" has never been
truer!

1) Not all tasks are scaleable, meaning you can't just throw more
computers at it to make it faster. A long pipeline of processes
communication with XML will have a latency that can only be combatted by
climbing an exponential curve of faster hardware - or fixing the software.

2) Faster things don't have to be more complex to code, if the designer is
careful. Speed through complexity (as demonstrated by x86 processors!) is
not the only way; sometimes the simplest things are fastest (as
demonstrated by RISC processors!).

3) Sometimes people want to use embedded processors... do you want the XML
fridge to cost an extra hundred dollars or an extra five dollars for that
networked processor providing the SOAP control interface (allowing you to 
check that the light is really off when the door is shut)?

4) If the tools a programmer is given is slow, then it can mean MORE work
for the programmer when his application turns out to have unacceptable
real-time performance (seen more with interactive desktop applications
than Web apps, but don't forget that the desktop app market exists and is
FAR FROM SMALL!), and profiling reveals it's spending all it's time inside
an XML parser.

> 
> Christian
> 

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