Comments on: XML and Global Warming http://www.alexandre-gomes.com/?p=33 Technology, programming, ideas and innovation are my preferred subjects. Working professionally on programming gives me plenty of new topics to write about, still my brain keeps popping out ideas in the most unexpected places. Wed, 25 Aug 2010 13:40:29 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: unknown http://www.alexandre-gomes.com/?p=33&cpage=1#comment-46 unknown Sat, 18 Feb 2006 12:58:57 +0000 http://www.alexandre-gomes.com/?p=33#comment-46 Hello, I think we shouldn't sacrifice use/readability for performance. On the other hand, space can be saved by using an XML-compression-algo. Hello,

I think we shouldn’t sacrifice use/readability for
performance. On the other hand, space can be saved by using an XML-compression-algo.

]]> By: alexmipego http://www.alexandre-gomes.com/?p=33&cpage=1#comment-35 alexmipego Mon, 06 Feb 2006 22:09:48 +0000 http://www.alexandre-gomes.com/?p=33#comment-35 I do understand and enjoy the benefits of XML/HTML, but storing and processing it carries a lot of wasted space and makes you to parse each and single tab/space/newline, even if you're to ignore them, each time you read the file. The argument if gzip is partially true if you're talking about apache, but AFAIK IIS doesn't support this out-the-box. No matter that, thats time you're wasting to compress and decompress the file, and a file with tabs/spaces, no matter how well compressed, can't be smaller than the original without them - in the better scenario it would be just equal. Parsers, no matter how good, tend to live with those topics, redundancy for instance, that something you don't need and would impact the overall performance. Think of this: When you do deploy an application do you ship it with debug info? No? Why? Because you trust it won't be needed and the user won't use it anyway. When you generate a XML file you take care to generate always with a correct format, so why to make it ship those redundant things that are only usefull when validating? I do understand and enjoy the benefits of
XML/HTML, but storing and processing it carries a lot of wasted space and makes you to parse each and single tab/space/newline, even if you’re to ignore them, each time you read the
file.

The argument if gzip is partially true if you’re talking about apache, but AFAIK IIS doesn’t support this out-the-box. No matter that, thats time you’re wasting to compress and
decompress the file, and a file with tabs/spaces, no matter how well compressed, can’t be smaller than the original without them – in the better scenario it would be just equal.

Parsers, no
matter how good, tend to live with those topics, redundancy for instance, that something you don’t need and would impact the overall performance.

Think of this: When you do deploy an
application do you ship it with debug info? No? Why? Because you trust it won’t be needed and the user won’t use it anyway. When you generate a XML file you take care to generate always with a
correct format, so why to make it ship those redundant things that are only usefull when validating?

]]> By: Jason Clinton http://www.alexandre-gomes.com/?p=33&cpage=1#comment-34 Jason Clinton Mon, 06 Feb 2006 20:19:46 +0000 http://www.alexandre-gomes.com/?p=33#comment-34 I agree with argument #1. Except that the power of XML/HTML has always been that white space is irrelevant. This is a refreshing difference which liberates us from the flame wars over tab sizes and indentation preferences. Argument #2 is pretty much completely obliterated by HTTP servers with gzip support. Redundancies just get compressed out. Argument #3 is partially true but mostly irrelevant since there are sophisticated and efficient parser libraries in existence. I agree with argument #1. Except
that the power of XML/HTML has always been that white space is irrelevant. This is a refreshing difference which liberates us from the flame wars over tab sizes and indentation
preferences.

Argument #2 is pretty much completely obliterated by HTTP servers with gzip support. Redundancies just get compressed out.

Argument #3 is partially true but mostly
irrelevant since there are sophisticated and efficient parser libraries in existence.

]]>