> The fact that it is a parsed format is not as brilliant as=20 > the fact that it=20 > gets parsed for you. Yes, exactly. My knowledge of programming is extremely limited, so I don't know how to express certain concepts well. The fellow, Greg Ward, who developed this is a wonderfully approachable sort. He would probably be willing to talk with you over e-mail about your ideas for a system, and offer advice. You should try to get in touch with him. > Essentially, the format is not parsed=20 > by your program,=20 > but by the library. You just have to stitch the library=20 > functions into your=20 > program, deciding how to render the data as you load it. If=20 > something new=20 > gets added, you can still read the file without changing your=20 > code (maybe=20 > need a recompile with the new library?) Another big advantage of this is that different parties would see the data at different levels of complexity. For example, I'm a furniture guy, so I model all my furniture using NURBS. This is great for the fabricator guy, for he can then use that to feed to his CNC mill. But the facilities management guy and the architect guy don't need NURBS; they just need to see a chair, so maybe their systems are set up to parse my chair data and produce a 3D (or even 2D) simpler representation of that chair to keep their models 'lightweight' and to simplify their drawings. It becomes a true universal system them, with the data passing from party to party.=20 =20 > While this is a really good way to go about it, how do you create the=20 > formatted file? With a more complex model, wouldn't it be=20 > best to handle=20 > both the read and write operations via such a library? This question is above my head. You'll want to get in touch with Greg, and I'm certain that he would be willing to answer your questions/respond to your ideas. Jeffrey =20