From melamy@earthlink.net Thu Aug 12 07:16:55 2004 From: melamy@earthlink.net To: test-drb@ccmp.vtda.org Subject: archive file format exmaple Date: Thu, 12 Aug 2004 07:16:55 +0000 Message-ID: <17365377.1092313015393.JavaMail.root@scooter.psp.pas.earthlink.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8349344323251187075==" --===============8349344323251187075== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable the keyword arrangement was just a waking thought this morning and is not cas= t in codecrete. Required fields is definitely a good thing as long as the info is really nece= ssary. The only data that was in the media section was data that was specific to to = media such as fill bytes, address marks, etc. Also, I kept a sub block arrangement because a single datablock was supposed = to represent a complete data entity such as a file, boot routine, OS itself f= or example. In order to retrieve any block of data, one only had to find a "d= atablock" and then concatanate the dataitems. best regards, Steve Thatcher -----Original Message----- From: Jules Richardson Sent: Aug 12, 2004 7:50 AM To: cctalk(a)classiccmp.org Subject: Re: archive file format exmaple On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote: > here is a "crude" example of what I was talking about.=20 > [snip] That looks good. How's about moving things like author into the definitions section? I'm not sure that it belongs at the top level, but more in the section containing archive info (description, creation date etc.) I'd suggest making certain fields mandatory in what you've called the definitions section. People tend to be lazy, which means the temptation is there to create an archive and not bother to include much of the information, thinking that they'll know what it is a few years down the line. We've all be caught out by that one! (author, date, description are good candidates for mandatory fields; there'll be others too) I'm not so sure about having the actual data within the archive element; I'd rather have it afterwards. Data in your datamap section still points to chunks of data, using whatever scheme is understood by the storage/compression system used by the archive. But then the possibility is there for using an encoding method that doesn't mix with XML data if needs be. It also makes it easy to scan the archive section by eye as it's not mixed up with huge chunks of encoded media data. Actually, you could probably build collections of media archives (say for some common platform) all within the same file that way, without breaking the format - the data in the datamap section of the first archive section just points to other archives within the same file. That's kinda neat. eg. (simplifying a little for example purposes): ... as before ... ... as before ... ... .... .... .. that way anything following the archive section doesn't have to be XML data even, providing the definition within the datamap section for the encoding/compression scheme used by the archive can reach it. It might be zipped data, other archive definitions, whatever. cheers, Jules --===============8349344323251187075==--