Re: [Q] Text vs Binary Files

From: Eric (egusenet_at_verizon.net)
Date: 05/27/04 

Date: Thu, 27 May 2004 10:40:10 -0400

Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> wrote:

> On Thu, 27 May 2004, Eric wrote:
> >
> > Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> wrote:
> > [Eric wrote]
> > > > -- should transportation to another OS become useful or needed,
> > > > the text files would be far easier to work with
> > >
> > > I would guess this is wrong, in general. Think of the difference
> > > between a DOS/Win32 text file, a MacOS text file, and a *nix text
> > > file (hint: linefeeds and carriage returns).
> >
> > Which is why I mentioned at the end using a solid XML parser to deal
> > with such issues transparently. I likely wouldn't consider using a text
> > file if something like XML and solid parsers weren't available and free.
>
> Ah, but what do you do when the XML standard changes? :)

Please correct me if I am wrong, but the design of XML already takes
this into account. In otherwords, the idea that it can and will change
is a part of the design - this is one reason why XML is such a nifty
technology.

> Misunderstood. By "the same systems," I meant the systems I just
> mentioned: DOS/Win32, Unix, and MacOS. Their binary data formats are
> identical.

What do you mean by 'their binary data formats are identical'?...this
would seem to imply that big/little endian issues are a thing of the
past...?

> > > > -- tolerant of basic data type size changes (enumerated types have
> > > > been known to change in size from one version of a compiler to
> > > > the next)
> > >
> > > It's about five minutes' work to write portable binary I/O functions
> > > in most languages
> >
> > Ah, but it's five minutes I don't want to spend,
>
> Versus five minutes trying to make your free XML parser compile?

Binaries of the better parsers are available, so this is a non-issue.
:-)

> > Plus, the potental for spending time attempting to figure out why the
> > @#$%@$ isn't being read properly isn't accounted for here.
>
> Of course not. I/O is trivial.

Once you track down the problem...however, it would not be uncommon to
think the problem lies elsewhere first and spend hours before finding
the trivial fix.

> It's your *algorithms* that are
> going to be broken; and they'd be broken no matter what output format
> you used.

With XML, the risk of this is far less, as long as you're not changing
the tag names or what they mean, if it really exists at all.

Relevant Pages

  • Re: SGML resources nowadays
    ... Features of VAX BASIC were ... If writing that XML parser today I'd do it in python or ruby. ... The 80% of SGML that people really want to use can be done in the ...
    (comp.text.sgml)
  • Re: REALLY simple xml reader
    ... *not valid XML* if the XML declaration isn't immediately at the start ... An XML parser doesn't care about bytes, ... Precision and complexity are orthogonal attributes. ...
    (comp.lang.python)
  • Re: JAVA SAX XML parser - GOTCHA!
    ... JAVA SAX XML parser - GOTCHA! ... It keeps its configuration files in XML format. ... XML files start with a header entry in UTF-8 that describes the text ...
    (bit.listserv.ibm-main)
  • Re: XML->sexpr ideas
    ... >> man's XML parser just so I could read a DTD just so I could get ... >> but the DTD for it looked like the best source of metadata about the ... do XML, ... it would have taken to figure out how to install cl-xml. ...
    (comp.lang.lisp)
  • Re: [PHP] Is there a way to use the strpos() for next string...
    ... I haven't got the PHP XML Parser to work, ... closing tag either because one tag have actual data as an attribute inside ... It is kind of frustrating to on not knowing what XML Parser will ... > haystack to start searching. ...
    (php.general)