OK, where do I begin with this one. Well, let’s start at the beginning.
A few weeks ago I posted that UGS had published a specification for the JT file format. This announcement was the fulfillment of a promise we made publicly early in 2006 to make the details of the JT format publicly available. The events that set into the motion that promise and its eventual fulfillment took place in the meetings of the JT Open group over the course of the previous year. The discussion on publication of the format centered on two issues:
1 – the corporate members of the group had a lot of data stored in the JT file format. They wanted a way to use that JT data as the official record of their projects, but couldn’t do so unless it met some very strict standards for long term data archival and retrieval. After reviewing the requirements, the easiest way to meet them was to make the spec available.
2 – the vendor members wanted to make JT more of a core of what they were doing, but couldn’t do to internal policies on adopting undocumented third part data formats. In this case, the answer was pretty clear as well: publish the spec.
Now, Alex over at 3DMojo thinks this is much ado about nothing. He raises two issues:
…users want the share the results of their efforts and they want to make sure they aren’t adopting an orphan file format. In other words, the format the bits are in doesn’t matter as long as the information is accessible and the IP that went into the design is available for the long-term.
Couldn’t agree more. Users do only care about their data and making sure they have long term access to it. The tricky part is that when you have the time horizons of an aerospace company (the B-52 will likely be in service for 100 years before its all said and done) you do have to think about things like “what if UGS isn’t around when I need this data?” or “what if there aren’t any apps left that read JT?” which naturally leads you to “boring” discussions about on disk formats. Maybe its geeky, but its the only way to solve the problem. After all, how many data formats from 20 years are easily retrievable today? Even 10 years ago might be hard. Having the detailed documentation of the format available to be stored along side the data itself is one piece of solving that problem.
Now, you may wonder why we didn’t just offer that panacea of long term data archival: an XML format. The short answer is: we do. All JT data can be directly and without loss be translated into PLM XML if that’s what a customer wants. However we heard pretty loud and clear that translation on that scale was not something that any of the members of the group wanted to spend any time on.Alex goes on to make a second point:
…UGS didn’t open source the JT file format.
Now, I know how you can open source an application, but I’m not sure what it means to open source a file format. I’m not sure its possible to do much more than we did to make what is at its core a binary format as open as accessible. Its all there in the doc.
If you want to use the spec to create your own JT creation or consumption filter, go ahead. You don’t owe us anything more than your email address so we can keep you up to date when the spec changes. If you don’t want to go to the trouble of understanding all the details of the format (or reading a 250+ page doc) then you can join JT Open and get an API that will let you access JT files programatically. Now for full disclosure joining JT Open does require more than an email address, but their is value their in the form of the API and the community.
So again, I don’t disagree with the conclusion:
Unless and until 3D file formats are open-source and royalty free, we’ll continue to need importers and translators.
But I fail to see how we are not hitting that mark what we’ve done. I know it is royalty free (check the license terms for yourself) and I’m not sure what else we can do to make the format info more accessible. I’m sure someone out there smarter than I is ready to tell me though ;-). Since our aim is to maintain our de facto position in the market, we are will take any and all suggestions…the comment thread is open.