Re: [xml-dev] basic qs - how is xml more flexible for exchanging data?

["cr88192" <cr88192@hotmail.com>]

----- Original Message ----- 
From: "Michael Kay" <mike@saxonica.com>
To: "'Anil Philip'" <goodnewsforyou@yahoo.com>; "'xml dev'" 
<xml-dev@lists.xml.org>
Sent: Friday, September 16, 2005 7:56 AM
Subject: RE: [xml-dev] basic qs - how is xml more flexible for exchanging 
data?


> My copy of the C language specification says that the language doesn't
> define how many bits there are in a character or integer, what character
> code is used, what order the fields in a struct are stored in, whether
> integers are twos complement, or in fact anything else about the physical
> representation of data. So how can this possibly define an interchange
> format that anyone can rely on?
>

this is true, though there are often "sanity limits" to all this.


one can often further specify, eg, that "int" is a 32 bit 2's complement 
integer in little-endian ordering, or one can come up with more descriptive 
type names('s32le', for example). in this way, struct-like representations 
are common in many file-format specifications (vs the ascii art and bnf-like 
notations found in some specs).

even absent this and other clarifications, one can often "rule of thumb" 
their way through it, eg:
for a fairly long time, 'char' has been informally defined as an octet (of 
undetermined sign);
on most recent computers, an int is 32 bits, and long is 32 bits "most of 
the time" (at least for the time being);
2's complement and ascii is near-ubiquitus;
most compilers don't rearange struct contents;
..

so, in general, with the code and some idea what the code ran on, one has a 
pretty good idea what is in the files. it is not like it is a world of 
"total" chaos...


agreed though, a higher-level representation is often preferable, or at 
least treating the file as a long stream of bytes to be read/written 
individually...

there do exist many specifications for many portable binary formats after 
all.