I’ve been reading and re-reading the excellent post by Franco Folini on Acrobat 3D.
Franco has, as always, written a clear description of Adobe’s strategy. This post isn’t in any way an attack on Franco’s point of view.
But, I do have two problems with all the fawning Adobe is getting in the CAD and PLM communities for Acrobat 3D. (You could see that coming a mile away, right?) The first problem is interesting; the second is fundamental.
My first issue is that I suspect a lot of the positive commentary about Adobe is a continuation of the CAD and PLM communities’ fascination with file formats, and more than that, the drama of file-format nuclear war. Franco talks about the “failure” of Autodesk’s DWF format. What, exactly, is “file-format failure?” And who cares, especially for an interchange format? To me, this seems like scene 586 of the standard CAD screenplay: let’s get some drama going about the purported impact of some new file format or file translation…let’s see if this’ll shake things up.
We all like a little drama with our 3D models. (Hey, it’s safer than caffeine.) And while this sort of discussion sells newspapers (and subscriptions to CAD newsletters and, yes, traffic to this blog as well as others), it’s not productive.
Worse is how the continuing file-format drama — that thing we really love to sink our teeth into — obscures the real issue: how should 3D data be delivered across the enterprise? Is it in the form of documents? Or is the data itself the right way to deliver this information?
And that’s my second objection to Acrobat 3D’s approach: it’s document-oriented. This is a conceptual flaw of ginormous proportions. And it’s the one that’s being missed by those who wage the nuclear wars over file formats.
Imagine a world without SQL databases…imagine that all electronic records in a company required instead a document for storage, communication and management. No problem for your paycheck. But what about your X-ray data at the doctor’s office? What about sending a transaction across a network? Are you gonna package that up into a document before sending it? What if you had to fill in “paper” columns on a ATM screen to get $100 out of the ATM machine?
In short, a document metaphor as the overriding container for the knowledge of the world is insufficient. Yet this is precisely Acrobat 3D’s basic modality: everything lives inside a PDF.
Think about sending PDFs to extract BOM information from an ERP system and combine that data with 3D design data (also now a PDF) to produce an animation for an end user as…guess what…still another PDF.
It’s unwieldy. And, excuse me for being blunt, it’s both short-sighted and wrong. There’s an old saying that if all you have is a hammer, then everything is a nail. Reducing 3D design data to a pound of nails doesn’t free this important resource to be shared and reused across the enterprise.
The alternative is 3D design data interchange that is data-based, not document-oriented.
<Seemage commercial>
The right answer is data interchange and communication that is not limited to simplistic metaphors, something that is designed as system, application and container independent: XML. If you want to integrate systems together today — and you don’t want to force those systems into specific interactions — XML is the right way to do it. And, of course, Seemage is XML-based.
</Seemage commercial>
So, for me, the CAD and PLM focus on file formats may be interesting to watch, but it’s not the real challenge. I hope that people will stop focusing on file formats — so easy to do and yet so ultimately uninteresting — and renew their interest in what 3D design data can do when communicated, shared and reused.