TC wrote:
>> The whole crap of "human readable" is bogus. None of it is human readable.
> Yes and no. Depends on what you want to do. 

You miss my point.  Punched cards are human readable. ASCII stored on a hard 
disk is not.  To read ASCII stored on a hard disk, you need software that 
interprets the bit paterns and puts them on the screen as glyphs from a 
particular font.

> <Civ4ArtDefines xmlns="x-schema:CIV4ArtDefinesSchema.xml">
> <MovieArtInfos>
> <MovieArtInfo>
> <Type>ART_DEF_MOVIE_INTRO</Type>
> <Path>Assets/Art/Movies/Intros/intro.bik</Path>
> </MovieArtInfo>

Can Path and Type come in any order? What are the valid values for Type? How 
many movieartinfo blocks can you have in one movieartinfos.

See?  Not human readable enough.

> Given your definition povray SDL is not human readable, too. You need at 
> least a text editor ;-)

Yes. So the "human readable" doesn't mean that. It means "readable with 
ubiquitous tools."   The problem with using something like ASN.1 is not that 
it isn't "human readable", but that the tools to turn it into "human 
readable" aren't ubiquitous.  Of course, if you work in an industry where 
standards are based on ASN.1, then the tools *are* ubiquitous, so it's as 
human readable as any other format.

> BTW: Your post made me realize how much our field of view becomes narrowed 
> down to our line of work. For me it's websites and small utility-programs 
> that can be cooked up in a few days. So nowadays in my work I usually have 
> sufficient computing power and hdd-space galore. But if you want to transfer 
> data via SMS, XML is NOT a good way of doing things, of course. ;-)

Yeah.  Unfortunately, people start putting it in inappropriate places, or 
they think their home-brew POS parser is actually usable.

One advantage of XML over lots of other stuff is that there are no length 
counts, so you can futz with a plain text editor to make it work.

> Don't getme wrong. I am no fan of XML. But I have seen worse. And you are 
> right about the general lack of documentation for data-file-formats. But 
> even if you have the docs, you still need to write code to actually read and 
> parse the files - with XML (and thanks to the extensive XML-support in many 
> programming languages) I find it comparatively easy to read,write and modify 
> third-party data-files which are done in XML. 

As long as the other side actually follows the standard and parses stuff 
according to the spec, instead of a half-assed 
open-source-works-for-me-I-don't-care-about-you hackware library.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message