-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Thu, 03 Nov 2005 08:49:42 -0500 "Nathan L. Adams" <[EMAIL PROTECTED]> > wrote: > | 6. Ciaran is completely biased against XML (or anything that isn't > | stored as a simple flat file) ;) > > It's not bias. I give XML exactly what it deserves. SGML is a giant > fire breathing stomping monster useful for crushing Tokyo. XML is the > spawn of said giant fire breathing stomping monster that's had its > claws and teeth removed, its jaws glued shut, its legs chained together > and its tail nailed to the ground. And we're not trying to destroy any > large cities here... >
<rant> You're just missing the fact that a flat file (or whatever it is you're clinging to; for the purpose of this rant, I shall refer to your simple data format as "flat file") has trade-offs, just like XML's trade off is parsing overhead. XML was designed to solve certain problems; portability of data, separation and portability of presentation from the data, etc. Complexity in the parser is the trade-off. Flat files can be great in certain situations. Flat files do indeed make the parsing trivial. However SIMPLE CODE ISN'T ALWAYS THE MOST IMPORTANT REQUIREMENT. In the case of this GLEP, the most important requirement is getting the proper migration info to the users in the best possible way. So what are the trade-offs of the 'flat file'? If you store a migration guide as a 'flat file', its not going to be very readable. I would certainly rather read info in GuideXML than some garbage output by einfo or the like (and I'm talking about the same exact data, just a different presentation). You're being daft if you say that your average terminal output is easier to read and understand than the same data in proper GuideXML format. OK, you say, you have a point there. But, you say, my flat file allows me to write a 'presentation' proggy in relatively few lines of trivial code. Yes, but now you have to write a new presentation program for every type of presentation you want to do. Or worse you would imbed the presentation in the data itself and make a new copy of the data every time you want to present it differently. But, you say, don't you have to do that with XML (i.e. a new style sheet definition for each presentation)? Sure, but I don't have to re-write firefox in the process... So the point is that, yes, XML has a down side. But plain text, CSV files, whatever have their downsides too. And the point of this GLEP shouldn't be to push any XML-bashing agenda, it should be to present the user with the migration guide in the best possible way. GuideXML is the standard for Gentoo docs for some damn good reasons! </rant> Nathan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDaqt52QTTR4CNEQARAoQ1AJ42ItHkJ37eFUY8rSoGpN/dVoKIFACeJi7b KW6/pzn8VEKi3hO0Gqomsms= =cSQh -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
