Re: XML Not good for Big Files (vs Flat Files)


"Roedy Green" <my_email_is_posted_on_my_website@xxxxxxxxxxxxxx> wrote in message news:th9d32lu6ddhorh91ppir5tmuqi86are5e@xxxxxxxxxx
On Fri, 07 Apr 2006 17:34:30 +0100, bugbear
<bugbear@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote, quoted or indirectly quoted
someone who said :

That's great. Put tones of repeating tags inside the file and make it
huge and now everybody is saying how to make it small with
Gzip/Binary,...

Yep. Best of both worlds. The parser sees the nice
XML and the comms sees a small file. Your objection
to this is... ?

I have four objections:

1. The compression method is like putting a fat woman in a girdle. You
can do better if you start with someone without rolls of fat.

Hmm, I'd say it's more like having two tools, each one doing what it does very well (XML to represent tree-structured data, gzip to compress arbitrary data), rather than one tool that does both semi-weill (ASN.1 to represent the tree-structured data, and to compress it). You can also swap tools in and out (you can't read gzip? How about 7zip? rar? Starting from XML, I can compress to any format you want).


2. The file is requires fat code to parse. Not suited for handhelds.

3. The file is slow to parse and create.

Developer time might be more valuable than CPU-time though. If the claims are true that ASN.1 is a pain to work with, it might be better for the work with XML and take a slight performance hit but getting the code working and bug free sooner. As ASN.1 matures and more tools and APIs are available for it, this advantage XML has will weaken.


4. When you are done there is still no guarantee the file matches the
schema.

When you're dealing with malformed files, there's no guarantee with ASN.1 either. I could take a perfectly valid 50 megabyte ASN.1 file, flip the last bit[*], and then send it to you, and you'd probably have to decode the whole file before you find out that it's corrupted. You've complained too many people muck around with XML files using text editors, thus causing problems. Well, nothing stops people from mucking around with ASN.1 files using hex editors, or hell, even plain ASCII text editors if they wanted to. The argument for using specialized validating ASN.1 editors can just as well be made for specialized validating XML editors.

- Oliver

[*] Change "last bit" with some other bit if it turns out flipping the last bit in an ASN.1 file doesn't actually corrupt it.

.

Relevant Pages

  • Re: XML Style Sheet Designer
    ... >> sheets but FrontPage can be used to view and test result by loading the ... The XSL can be manually written in the FrontPage editor ... >> XML" as any well formed XML file can be read by dragging it into the body ... there are a number of XML and XSL editors around. ...
    (microsoft.public.frontpage.programming)
  • Re: XMLReader skip current element
    ... and in fact I'm not sure that XML editors have to either. ... you miss some sort of closing quote, comment closure, closing bracket, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: XML Style Sheet Designer
    ... > sheets but FrontPage can be used to view and test result by loading the ... The XSL can be manually written in the FrontPage editor ... > XML" as any well formed XML file can be read by dragging it into the body ... there are a number of XML and XSL editors around. ...
    (microsoft.public.frontpage.programming)
  • Re: XMLReader skip current element
    ... Most XML-based applications don't, ... and in fact I'm not sure that XML editors have to either. ... If you miss some sort of closing quote, comment closure, closing bracket, etc. the editor makes no attempt to recover from that. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Problems in transferring XML
    ... How can I compress XML using a compression algoritm? ... Is it after saving the XML string to a file and then zip it? ...
    (comp.text.xml)