Re: [xsl] Using for-each w/ page-sequence results in "NC105 ID already exists in this document" error

Subject: Re: [xsl] Using for-each w/ page-sequence results in "NC105 ID already exists in this document" error
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Wed, 19 Sep 2007 17:11:35 -0400

At 04:53 PM 9/19/2007, you wrote:
Am I correct in thinking that in order to get the page sequence to start
over for each instance of the Lesson element, that I need to have a
for-each statement before the page sequence?

Not necessarily, if I understand you correctly. Basically the reason for this is that anything you can do with a for-each, you can do equally well (and often better) with a template and apply-templates. So whether the page-sequence element is inside a template or inside a for-each instruction isn't actually any indication, in itself, of where there's a problem.

If so, how do I ensure the IDs are unique for every instance of the Lesson element?

You may or may not have a problem with generating a single page sequence with a unique identifier for every Lesson in the input. It sounds like you do, but we can't know this for sure, to say nothing of why this might be, without more information. (Best would be to see a reduced version of your code that duplicates the error, but that boils it down to a minimal case for legibility.)

However, I wouldn't take this tack just yet. Instead, I'd analyze the output to find which elements are getting duplicate identifiers. The best way to do this is to examine the FO result of your stylesheet before it is picked up by the XSL formatter, to be rendered as PDF. Do this by running your XSLT stylesheet on it without the formatter, using just an XSLT engine, and saving the FO results as an XML file. You can then examine this file directly and look at the IDs. Seeing where they duplicate will direct you to where in your stylesheet things are not coming out right. You could, for example, be assigning the IDs to elements inside the ToC as well as to the page sequences it points to.

As it is, the FO engine is telling you there's a problem, but not where it is. You need to locate it before you can trace it back to what's causing it.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread