(no subject)

From: Marshall Burns (Ennex  Corporation)
To: Michael Brindley
Cc: RP-ML
Date: Sunday, December 10, 1995
Dear Mike,
     You wrote:
 > Of course, a tagged data format would handle all of this in its sleep.
 ...
 >      I hereby publically request ... use a tagged data format.
     I can think of several things you might mean by "tagged data format." Could you say specifically the sort of technique you are referring to?

Date: Sun, 10 Dec 95 23:07:41 PST
     Well, the basic idea behind a tagged data format is that the data includes a tag (label, identifier) which identifies the content. Traditionally, data on computers have relied on the file name to identify the contents.  This has often taken the form of  content.ext  where content identifies the area which the data in the file refers to and ext defines the form of the data.  An example would be the file 'sales95.wk1'.  The first part of the name tells you that the file has sales figures for the year 1995, while the last part tells you that the file is a spreadsheet file in Lotus 1-2-3 format.  Now what happens if the name is changed (perhaps by accident)?  The data is still intact, but you can't identify it.  If the data is tagged, it has an identifier as part of the data, so a person or program can identify the contents and make sense of them.  Now, what happens if you wish to bundle some other data together with the sales spreadsheet so that they will stay together (are at least difficult to seperate)?  With a tagged data format, you can put a wrapper around the different types of data, encapsulating them into one file.  So you can make a file that holds the sales spreadsheet, all the charts and slides you made for your presentation to the Board of Directors, a picture of you being congratulated by the President of the  company for your record setting year, a report analyzing why you did so well and suggesting how to apply those principals to other parts of the company, and so on.  
     Now, you send this packet to a friend in another division.  She  wanted a copy of some of your slides and your sales figures. The spreadsheet program reads in the spreadsheat data and  ignores all the rest of the stuff (the different types of data are clearly labelled, so the program can easily extract the information it wants while ignoring the rest).  And a graphics program reads in the slides.  But wait, there's more!  You find out that your friend read the analysis report and found some good pointers to apply to her situation.
     So, minimally a tagged data format would clearly identify the data it contains, preferably in the first few bytes of the file. The STL file format is not a tagged data format; it does not   identify the data in any way.  The GIF format is tagged; it has the tag 'GIF87' or 'GIF89' near the beggining of the file.
     The reasons for identifying the overall chunk of data apply equally well to internal subdivisions of the data.  One useful tag might be a version number so that new features can be added (the numbers in the GIF tags are basically version numbers, they refer to the year the standard or revision was made).  For a rapid prototyping file format, individual solid volumes could be specified (and identified as object or support) and colors or other attributes could be assigned to the individual solid volumes.  
     Does that explain the kind of thing I'm talking about?  For more information, you might try the documentation for one such  scheme:  Appendix A of 'Amiga ROM Kernal Reference Manual: Devices (Third Edition)' by Commodore-Amiga, Inc., 1991, published by Addison-Wesley, ISBN 0-201-56755-X.

Date: Mon, 11 Dec 95 22:35:28 PST
Dear RP'ers,
     I received some private email about my recent post about tagged image formats, which pointed out the need for some addenda:
     1. the tagging makes it easy for software to skip data it does not care about, know about, or understand.
     2. the reference I gave, is perhaps not the most accessible  (Appendix A of 'Amiga ROM Kernal Reference Manual:  Devices (Third Edition)' by Commodore-Amiga, Inc., 1991,  published by Addison-Wesley, ISBN 0-201-56755-X).
     It is an excellent reference for the subject of tagged data formats and happens to be one I have at hand.  However, another reference was suggested: ASCII CLI (common layer interface) format for representing layered RP data.  This has the advantage of being topical and available on the WWW.  (You should ignore the binary form for CLI as it is not tagged.  From my reading of a couple of years ago, I also have a conceptual objection to CLI's binary part, but that's another topic).