Concept clash: document vs. data


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.

2 comments to Concept clash: document vs. data

  • Franco Folini  says:

    Talking about PDF, you raised an important issue: PDF is document based and this is a limitation. You believe that the document is a metaphor that doesn’t work well in a well structured environment as an enterprise. Few years ago I would agree with you 100%, or more. Now, after spending many years interacting with customers and engineers I know that most of the processes in small, medium and even in some large enterprises are not so well defined and well structured. In a poorly organized work environment a document, like a PDF, is a good metaphor. At least people know what to expect from a document and how to handle documents, even if they come in a digital format like PDF.
    Is the document-metaphor the optimal solution? Is this the way to go to maximize your department productivity? Is the document the future of data exchange? My answer to all those questions is: absolutely no! But we live, work, sell in a real world, not in an ideal one.
    I’m glad there are companies like your working to push the limits of productivity, to innovate. But don’t forget: if you are using XML, you are a pioneer.

    At Novedge we exchange data like purchase orders, reports, etc. with several companies, small, medium and large. Mostly, we exchange simple numeric data, nothing complex like 3D or 2D models. On our side we have a fully automated system to generate Pos, reports, etc. Do you know which formats we are currently using to use to comply with some of our suppliers ordering systems? Not XML, not even CSV, but PDF and Excel. Not everybody can be a pioneer…

  • Alex Neihaus  says:

    Hi, Franco.

    Thanks for the well-considered response to my post.

    While I understand what you are saying, I am not sure I completely agree that band-aids are the right response for businesses with poor processes. Nor do I agree that using XML for data interchange is in any way pioneering.

    On the XML front, most every application has implemented XML. Office 2007 is XML based, for example. You can even export your iTunes library in XML! In fact, you could argue that Adobe is as concerned about XML as any other competitive threat and that might be why they’ve just released the complete PDF specification to the open source community.

    It’s no surprise that people are still using document metaphors for data exchange…that’s what the world was.

    But today, implementing such a process as a net new process makes no sense. That’s why, under the covers, things like Office are going XML: they allow people to retain the familiarity of the document metaphor while managing interchange without the constraints of document-based exchange.

    Only Adobe is still insisting that document-based interchange makes sense. I understand why they would of course. What I don’t get it why anyone would buy it. Nobody but Adobe in the CAD world — and I mean nobody — is advocating document-based interchange. The contest is between XML and proprietary file formats. The fascination with file formats is the other thing I often whine about. But the point is that whether or not you care about file formats, only Acrobat advocates PDF as an interchange format.

Leave a reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.