Duplicate IdRefs

[wendygberen]

FrameMaker 7.2p128 is generating duplicate cross reference Ids for different cross references. Is this a known issue? Is there a fix?

Here are the steps to reproduce:

1. In structured FrameMaker, add a cross reference to topicA in file1.fm

2. Add a cross reference to topicB in file2.fm.

3. Save the book as XML.

Compare file1.xml and file2.xml and notice that there is a duplicate Idref for different cross references:

File1.xml snippet:

<ListItem><Strong>RSS</Strong> feed filters for a task list. See <CrossReference
    Idref = "CHDBBCCB" format = "heading intro"/>.

File2.xml snippet:

<TableCell><Para><CrossReference Idref = "CHDBBCCB"
    format = "heading intro"/></Para></TableCell>
<TableCell><Para>Adds a <UserInput>&lt;Timestamp></UserInput> element
to the SOAP header of a message</Para></TableCell>

[Michael_Müller-Hillebrand]

Wendy,

The source of the problem is most probably something else: Someone copied a piece of text from file1 to file2 and the ID in file1 was already present. If an ID is already present the product uses that and does not create a new ID.

BTW, you should update to 7.2p158, see http://www.adobe.com/support/downloads/product.jsp?product=22&platform=Windows

Also, there is a great plug-in XRef Wizard by http://www.weststreetconsulting.com/ which helps you keep IDs unique throughout a book.

- Michael

[Russ Ward]

Yes, along with what Michael said... the key point to remember is that FrameMaker enforces ID uniqueness within a file, but not within a book. If you copy/paste an element with an ID into the same document, the ID is automatically removed on the new copy. If you copy it into another file, though, it is not removed (unless it already happens to be in that doc). This doesn't cause any problems for normal FM usage but it can cause hassles when saving a book as XML.

It is also possible that Frame autogenerated the same ID in both files when the respective cross-references were created, but this is unlikely. It is much more likely that content was copied from one file to another. FWIW, the same thing happens if you do a Save As... the new file will have all the same unique IDs as the original.

Russ

[wendygberen]

Hi Michael and Russ,

Thanks for the replies. The problem is definitely a FrameMaker glitch. In my 15+ years of using the product,  this was my first encounter with duplicate XRef Ids.  I'm well aware of the bad practice of copying/pasting sections and doing Save As. 

However, I worked around the problem by deleting the existing section/Xrefs and creating a new section with new XRefs.

I misspoke about my FM version -- I'm using  7.2 p158.

Thanks for the tip about the XRef Wizard plugin. I'll look into that. I need a utility that will check for duplicate Ids that I can add to my build procedure. Unfortunatly our latest product release shipped with the bad Xrefs in the doc.

Wendy

[Van Kurtz]

Russ,

I found this in the Frame 9 documentation for structured applications:

FrameMaker cannot test for whether an entered ID is used in a different document in a book,
especially since one document can be in more than one book. When the user validates a book,
however, FrameMaker reports conflicts between IDs across documents in the book.

This was in a section about applications in which the user is allowed to enter an ID value. Should it not apply to applications where FrameMaker creates the ID values?

If true, then Wendy only needs to update her book before exporting to XML.

Please enlighten if I have it incorrect.

Van

[Michael_Müller-Hillebrand]

Van,

As far as I have seen recently this is (only) wishful thinking.

- Michael

Am 15.10.2010 um 18:18 schrieb Van Kurtz:

I found this in the Frame 9 documentation for structured applications:

>> FrameMaker cannot test for whether an entered ID is used in a different document in a book,

>> especially since one document can be in more than one book. When the user validates a book,

>> however, FrameMaker reports conflicts between IDs across documents in the book.

This was in a section about applications in which the user is allowed to enter an ID value. Should it not apply to applications where FrameMaker creates the ID values?

If true, then Wendy only needs to update her book before exporting to XML.

Please enlighten if I have it incorrect.

[Russ Ward]

Michael, you wrote:

> As far as I have seen recently this is (only) wishful thinking.

Indeed! I didn't even know that was in the doc, but I can't see that it is anything but fiction. I've been using books riddled with duplicate (and triplicate, etc.) IDs for years and FM has never complained during a book update. Just to be sure, I just ran a little test where I set duplicate IDs across files and even created xrefs to each of them. FM thought it was just swell. I think, though, that the product should work that way the doc says. Seems like a bit of an oversight to me.

Russ

[Van Kurtz]

FWIW

If you look at the BookXRefs in a book mif file, you will see that the file name is also recorded. So, maybe coupling the file name with the ID value makes the combination unique across the book.

Oh, well,
Van

[wendygberen]

Thanks for the thoughts, Van.

The first thing that occurred to me was to update references in the book -- perhaps I had forgotten that step. But that had no effect on the generated Ids.

I generate the XML via an Ant script so I never view any validation errors/warnings I might be getting in FrameMaker (or at least I haven't looked at them for a long time). That's a good hint. I'll try a manual XML generation to see if I get any errors, or even better,  I'll look into my Ant script to see if I can display FM validation errors in my command window.

Wendy

[wendygberen]

Actually, in regard to my last reply-- what was I thinking?

When you validate in FrameMaker, you're only validating against the DTD,  not the FrameMaker internals, so you'd never see any errors for generated Ids.

And I can only imagine that the FrameMaker developers would not check for duplicates in a book, since generating a duplicate value is a rare occurrence (but it definitely happens).