Inx file not completly 'clean'?

Question

One of my plugins has a conflict with an inx file. Some background info: I did have an old cs2 file, which I later opened/resaved in cs3. I then exported it to, so I thought, 'clean' inx file. So when I opened it in combination with this thirdparty incopy plugin, it was a clean indesign file with nothing out of the ordinary inside it. But something was still in the file which made the plugin behave strangely. Then I started a fresh cs3 file, copied the textfields/styles/colours from the old converted cs2 file onto it and exported this new file to inx and used that one with the plugin. Now it worked fine.
Could it be that even though I exported to inx, there still can be funny stuff inside it? I thought exporting to inx would result in a clean file, but:
- open/convert cs2 to cs3, export cs3 file to inx: still something inside the inx file which might conflict with a.o. a plugin
- new cs3 file, export cs3 file to inx: default clean file

Answer 1

Joel Cherney wrote:
What INX and IDML are actually intended to do is to write the entire file from ID version n that ID version n-1 can read.
This is oft-repeated, but it is not really  true. INX and IDML are designed for "interchange.". They are designed so that 3rd party developers (even users) can easily write applications that can read (and write) to these files, to exchange content with InDesign. Their primary purpose is not to be a backward-compatible format or a portability format between InDesign versions. They are formats designed to be public (can we say "open"?) from the get-go, and there's quite a lot of published Adobe documentation on how to parse these files.
It is true that Adobe recognized that INX could be used for this, and that it was probably much easier to have CS4 write INX files to the CS3 standard than it was to have CS4 write CS3-format INDD files. INDD is a complex database file format and code that deals with it is higher performance than with INX/IDML files, but it is not simple, and it is more prone to corruption.
We actually use INX and IDML files in our workflow to pull out information from layouts as part of managing print content that becomes web content (and other).
One thing about IDML/INX is that if you have corruption, you can edit the IDML/INX file to narrow down the source of the corruption and ultimately figure out what the problem is. This is a pain in the neck and may be boring and repetitive, but it is definitely doable (and scriptable).
The reason that opening a CS3 file in CS4 (or CS5) can help is that CS4 and CS5 have different bugs than CS3. And in some cases, they have better checks for corruption in the INDD file and may be more successfull in opening a corrupt file and managing its corruption (i.e. not further corrupting other data structures) than CS3. Though the bugs are different -- not all uniformly better. So when dealing with corruption, different approaches may be necessary.
Anyhow,  your comment are totally valid!
I just kind of want to sing out about INX/IDML's purposes, because I think too often people think of them as backwards formats, when that is not their job. Oh, IDML is also the format for InCopy assignments and snippets. And I think one other item I am momentarily forgetting...