Siemens PLM responds to Spatial's complaint on JT

by Jim Phelan

The following information is provided by the JT Open team at Siemens PLM Software:

Siemens PLM Software continues to publish the JT specification so that it is openly available to the PLM market and in September of 2009 was granted status by ISO as a Publically Available Specification (PAS). Here is a link to that announcement: http://bit.ly/3p9HN4

The currently published specification is for JT version 8.1 and will support any prior version of JT. The 9.5 revision of the specification is planned to be released in July 2010.

The Technische Universitat Darmstadt Department of Computer Integrated Design under the direction of Dr.-Ing. R. Anderl completed a validation of the JT File Format Reference and found it to be complete and accurate. Independently, a major automotive member of the JT Open Program conducted their own evaluation of the reference and also concluded the JT File Format Reference is a capable source for the development of applications to read and write JT files.

In addition to the published file format, Siemens PLM Software provides a toolkit to assist developers using the JT file format. Any company – including our competitors – is welcome to join the JT Open program where they will get access to the toolkit to read and write JT files.

We are now actively engaged with the global community in an effort to have the JT file format accepted as an ISO International Standard. The ISO work is being driven by the membership of the JT Open Program with the objective that JT continues to be open and published as a standard.

More information about the JT Open program can be found at www.jtopen.com .

Comments

[CADWatcher]

As far as I remember, there were JT 9.x files produced by UG NX and TeamCenter since (at least) november 2008. So saying the specifications are publicly available is ridiculous: public specification not in phase with actual format is just crap in my opinion.

It is similar to Dassault publishing 3dxml specifications and "omitting" to publish specification for compact binary format...

[Crying Shame]

Well said, cadwatcher. Siemens is misleading when it calls JT format an 'open' format. Even the said announcement dated October 2009 is over 9 months old. Since the time before it (as you have pointed out), Siemens has held on to all JT format information related to many 8.x versions after 8.1 and all 9.x versions and insists on giving it only through JTOpen program.

Jim, a format is either 'open' (the context is quite clear for this word in the present discussion) or its not. You cant have the cake and eat it too.

Spatial (Dassault) called it correctly by refusing to support this 'pseudo-open' stuff. Putting the 'ISO approval process' blanket on it does not hide the fact that JT format is a 'closed' one and as long as Siemens insists on everyone going through its JTOpen program, it shall remain so, despite the many press releases Siemens shall trot out.

I would even argue that the ISO folks must take recognition of this when voting to make JT an ISO format. The right thing to do is to abolish JTOpen program and set the format free of Siemens, while letting them define it and publish it.

[Ralph Grabowski]

It appears to me that Siemens is following the same route as Adobe: get an international body to certify PDF as a standard, so that Adobe can call it "open."

This is only half-open; the other half of openness is missing, because Siemens and Adobe decide what gets to be in the format.

JT and PDF are half-proprietary, half-open.

[Jean-Luc Medoc]

I am a student at the local technical university where I made my master degree in informatiks. For my thesis, i did thesis on 3d simulation that required me to read jt format data. The university uses a non-siemens cad system. This research was sponsor by another cad company that did not want to buy jtopen libraries. So, I tried to use the jt format information in the last 6 months to create a jt file reading program from UG NX 6 data, which was version 9.1 JT data.

It was impossible to do. There is some compression et encryption in the data. i asked on some forums for help, but no one could give me the infos. In my experience, jt is not an 'open' format. They hide a lot of the information needed to create even a simple reading program.

Ralph, you should ask siemens about this contradiction. i am sure they respond with the same as they say about the jt format itself.

[peter]

nearly mid August and we're still waiting for the promise of the v9.5 revision due 'in July' - thought just struck me, maybe they are working on the v10 release to ensure they keep the 'Open' format behind the latest version? They could then name it 'JT Open minus x' where x = the number of versions back they openly release.

[Hans]

End of August...

[Oliver]

It is ridiculous, after weeks of work we was able to manage to read 8.1 version files and now the same problems occur with v95. In nearly every critical point of the decripting process, the reference manual has bugs or hide the information how to get your hand on the data, so I spend hours and hours with pen and paper counting bits and bytes and tried to be able to read informations of an "open file format".
After I asked for the costs of a JT Open membership I understand why.

[Sol]

I started work on a JT 8.1 translator a while back and got stalled out -- I think it was a combination of difficulty dealing with the compression and more urgent tasks elsewhere. I wanted to take another look at it this week, so I first tried to download a newer version of the spec, just in case it was clearer.

Poking around it, I almost instantly ran into the issue that some of the fundamental objects appear to be different in 9.5. In particular, the first element of Base Node Data is an I32 "object ID" in 8.1 (rev B), but an I16 "version number" in 9.5 (rev A). Unless I'm really missing something here, these appear to be quite incompatible? At a quick test, it seems like the first file I've got here conforms to the 8.1 spec. I'm not finding any mention in the 9.5 text of the difference, which seems to suggest that you need both documents (and possibly others in between?) to build a working JT translator that can handle any version. But I hope I'm missing something, because that is completely insane...

I've long thought there should be a forum out there somewhere for developers to discuss this sort of thing, comparing notes about how the various file formats work in practice...

[Flo]

There is now a forum at http://jtspec.forumprofi.de in order to share and discuss experiences with the JT 9.5 Rev A version. This is an initial effort intended to help identify unclarities or possible errors to further drive both, the format and custom applications and parsers.

[Joe]

Can anyone tell me, where I can find JT files of version 9.5? I have searched through the internet, but I found only the version 6, 7, 8 and 9.0 (but not 9.5 wich is different from 9.0).
I am also looking for a JT file of version 8, containing the NULL codec.

[Arsanias]

JT Format ist the Most complete but also the most confusing format.

The developer has spend 99% of their energy into the compression algorithms but only 1% brain cells for logic, portability, transparency and continuity.

So in case somebody should have a translator for v8 but receives some v9 models, it would be a big issue. Other formats such a s OBJ or IGES will always be loaded. JT translator v8 cannot read even one vertex from a JT v10 file. What a shame.