> You're correct, DWF doesn't solve the problem of reusing very=20 > old designs -- that's a tough nut to crack. As I mentioned=20 > before, we really do need to change our native design formats=20 > to continue to improve our products. So, you should expect=20 > those changes to continue. And, the mathematics of large=20 > numbers means we can't continue to support all old software=20 > and continue to make new software. I understand the problem, though. =20 Well, I think this is more of a design issue. I know people that are = using ArchiCAD and DataCAD that can open work they did ten or even (in = DataCAD's case) twenty years ago. I understand that it's difficult to = have that kind of backwards-compatibility, but it's certainly not = impossible; it's just something that needs to be designed into the = system. I still use my grandpa's wrenches, which are a lot older than me, to fix = my car; but my dad's old ford tractor that was made in the thirties = requires all kinds of proprietary and specialized tools that Ford was = making back then. See, Ford thought that it would design the tractor so = that you had to buy the tools from Ford too, they were thinking it would = make them more money because tractors were in vogue and a big business = in the thirties. Now my dad has to custom-fabricate tools to fix the = tractor sometimes, due to the way it was made, because it's not like = ford is still selling those propriety tools. Now, granted, it's only a = tractor, but still; it's still a perfectly workable tractor for someone = who's not in farming and just wants something to push around dirt on = their property. It's lived a long life. It looks really cool. And when = you look at the total cost of energy, it makes more since = environmentally to use a old tractor than to use a new one if you're not = a professional farmer. Now, Lee, you say that most of my examples are allegory; you are right- = that is because, like I stated before, I don't see any reason that = computers and software need to be completely different from the other = things in my life. CD's I bought ten years ago still work without a = problem. My car is from 1968 and it works without a problem. Just = because Dodge is making better, more modern cars now doesn't need to = negate my older car. Heck, the engine that is in a lot of the Jeep = Cherokees and Dodge pickups, the 5.2L V-8, is based upon the engine = that's in my car, and the parts can even interchange! And what about = e-mail and the TCP/IP stack that forms the internet? It's been around = since the sixties or seventies, and has been improved and changed, and = it still works. It's about the design, not an inherent problem with = computers. It's just something you have to plan for.=20 > Being able to build upon previous works is a completely=20 > legitimate expectation. Human knowledge has been acquired=20 > layer by layer so far, and I don't see that process changing=20 > soon. The problem for CAD is that up until very recently=20 > there were only three categories of data formats: 1) Native,=20 > live data; 2) Exchange data(import/export); and 3) Archived=20 > data. None of which has the features you need. Would it be possible for there to be a format that can do all three? = Adobe recently moved Illustrator over to the PDF format, so it's always = working natively in PDF. That way, it is 'live' data, exchange data = (many programs from Adobe can open and edit a non-locked PDF, and by = buying Acrobat you can open them in Word and save them back to PDF = format), and archive data at the same time (because you can 'lock' the = PDF at will, and make it uneditable). Do you think that a similar format would be able to be made for the AEC = industry? Something XML or IFC based so that anyone can read it without = import/export issues? There are word processors that use XML or HTML as = a file format, so that #1 and #2 are combined into one, for anyone can = open them and change them without import/export issues. So you really = just need #3, a way to somewhat securely 'lock' or 'freeze' a file at a = point in time for archival purposes. What do you think about programs like Revit, where you don't have many = separate drawings or files but one big database of information that's = all the schedules, drawings, renderings, sheets... Would you = export/publish every item? Jeffrey McGrew