dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]Disadvantages of XML


From: Gopal.V
Subject: [DotGNU]Disadvantages of XML
Date: Tue, 1 Jan 2002 22:23:50 +0530
User-agent: Mutt/1.2.5i

Hi E'Body,
        There has been quite a bit of talk about XML here in DotGNU.
(water under the bridge !). I see XML as one of the important 
technologies out here. But XML comes with a lot of potential
problems.It's an admirable format for preserving the organization
of data. But the data here should be *TEXT* (ASCII/UTF-8/UCS-4...).
The infinite tree structure & flexibility of XML are important
aspects. But let me state some of the problems I see.

* The Size aspect
    - XML comes in all shapes and sizes
        - XML introduces a large number of tags and
          elements which add to the size (hard disk
          vendors are just going to *love* XML)
        - Gzip compresses XML very well, eg the ECMA
          spec of C# ie All.xml is about 6 Mb. With
          Gzip it comes to 420 kb. !
        - But can we make Gzipped XML a standard ?
         - Dia & Gnumeric have been using Gzipped
           xml for some time now.
    - XML specific compressions can be introduced
          ie pseudo-lossive compressions which take into
          consideration the white-space and similar redundant
          attributes of XML (comments ?)
        - Is XML going to clog our bandwidth in the future ?
          
* The Parser aspect
    - XML parsers are too generic to be efficent
          for a lean mean parser.
        - But they can easily be extended due to their
          generic nature
        - A Binary format parser eg a Java Class file
          parser is very efficent in comparison to an
          XML parser which uses a *LOT* of calloc/free
          pairs for the large number of string operations
          needed.(Nurse,hand me the memprof please ^ !)
    - Let's come back to XML, a well written LALR parser
          performs 2-3 times better on XML than an XML parser.
        - A DOM XML parser has to generate a DOM tree which
          is not a big deal for PC's but embedded systems may 
          be affected by this large memory usage.
    - Verification puts a sizable overhead on the already
      bloated XML parser. That could well be the nail on
      the coffin.
        - But for the new generation PC's an XML parser is not
      that much of a load. So I'll leave the parser alone on
      the desktop arena , but look at server side processing.
      
* The Presentation Aspect
        - How is XML converted to presentation ?
    - I tried XSL (which is not meant for presentation)
      with Mozilla (com.alexa.xslt) and CSS with
      the same. But the Recipe failed !
    - Custom programs for presentation took a lot of
      work and thanks to the XML parser are _very_
      unefficent & slow.
    - Converting XML to HTML for display is too poor
      an alternative for static pages.
    - Dynamic display on the client side has all the 
      problems "DynamicHTML" is facing now . ie vendor
      incompatibilites, "graceful-degradation" etc.....
    - Server translations are too heavy on the servers
      at least with the generic parsers we have.
      
* The DTD Aspect
    - The DTD is intellectual property (that gives me the
      creeps, coz that means it can be patented).
    - If a large company patents, say a document format
      DTD, they will defend it well. So we are left with
      a format that is useless even though you can see the
      source.(open source ,M$ style !)
    - Generic parsers will ensure that the format can be 
      parsed. But I wouldn't put it past M$ not to go and
      create MSXML which cannot be parsed in a normal parser.
      
* The Interoperabilty Issue
    - XML *is* designed for interoperability.
    - But have you ever tried working with a multilingual
      XML file ?.
    - Imagine a set of XML tags defined in UTF-8 (eg in 
      Korean) what use is that for interoperability.
      Can they be coded in encodings ? or can they be 
      coded only in ASCII ?. I would like to know.
    - XML needs an agreement (in ideas) between the two
      trasferer/transferee to be useful. ie one of them
      has to lead the way and the other has to follow.
      
    All this makes me wonder why I am such a fan of XML ?. Well XML is
practical (just like Java is fast), and it will get more useful as more
people start adopting it. Look at Dia,Gnumeric,Abiword and Jabber , 
these are excellent programs , I can see no fault with these guys for 
adopting XML. The bone I have to pick with is with those developers who 
refuse to see the *dark* side of XML. Hope every one takes a closer look
at XML and sees what it truly is . 

  "XML is a tradeoff between efficency,convenience and interoperabilty"

  And it delivers what it promises. nothing more ,nothing less.

Gopal.V
-- 
 The difference between insanity and genius is only measured by success
 //===<=>===\\
|| GNU RULEZ ||
 \\===<=>===//


reply via email to

[Prev in Thread] Current Thread [Next in Thread]