[cad-linux] Re: OT: Open data formats (continuation of previous thread)
- From: lee.harding@xxxxxxxxxxxx
- To: cad-linux@xxxxxxxxxxxxx
- Date: Tue, 24 Sep 2002 12:45:32 -0700
The oldest version of AutoCAD I've seen running (and this was several weeks
ago) was version 2.15, I think. Like your old tools, software _does_ continue
to work, even when there are superior options available. And that old tractor
(or Jeep) -- if it wasn't modified, could it burn unleaded gas without burning
up its valves? What happens when hydrogen or ethanol become the fuel of
choice? The point being, the context in which "work" is defined is
continuously changing.
Software _is_ different than anything else. There are similarities to other
more tangible objects, but they only go so far. My background isn't software,
it's mechanical engineering, and after 8 years at Autodesk I'm finally starting
to get the distinctions.
Your consideration of PDF files may do as well substituting ZIP, correct? I
can put much more diverse information into a ZIP file, and lock and unlock it
for protection too.
My understanding is that the antiquated TCP/IP stack powering the net doesn't
allow IP telephony or video to work in a reasonable way. IPv6 deprecates IPv4
(today's standard), solves some of those problems and is starting to make
headway. Don't expect the IPv4 stack to ever understand IPv6, by the way.
Regarding a unified format for CAD: Take a look at the abundance of proposed
standards for representing 3D graphics. None are successful. And, 3D graphics
is at best 10% of the problem with CAD. Multiply the problems with 3D graphics
by 10 (or perhaps take them to the 10th power) and you start to understand why
I'm pessimistic. The path to success in data exchange is focusing on tasks
rather than bulk information transfer, IMHO. We should work to define very,
very useful formats that solve particular task-oriented problems in the design
process. The formats should be small, and highly focused. That way we can
begin to layer them, and build our knowledge of what works and doesn't. This
approach won't give you a format that works for everything, but it should
(hopefully) start making formats themselves irrelevant.
> -----Original Message-----
> From: Jeffrey McGrew [mailto:JMcGrew@xxxxxxxxxxxxxx]
> Sent: September 24, 2002 11:14 AM
> To: cad-linux@xxxxxxxxxxxxx
> Subject: [cad-linux] Re: OT: Open data formats (continuation
> of previous
> thread)
>
>
>
> > 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
>
Other related posts:
