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: Thu, 20 Sep 2007 11:51:51 -0400

The use of // constructs may or may not be related to the problem here (irrespective of the fact that it is processor intensive and often unnecessary). I don't think we're being helpful by focusing on it until we know what the actual problem is.

Both Ken and I have suggested examining the XSL-FO output directly, rather than simply guessing based on error messages. That's the only way to know for sure where there are problems, and hence the only way to develop a solution that is not prone to cause more problems (perhaps unseen ones).

So our choice here is to guess at changes Sharon can make to her XSLT that might make her problem go away, or to help her develop better diagnostic techniques so she can do this on her own.

Were I to make the guess, I'd focus on this bit:

<fo:page-sequence master-reference="Chapter-SequenceOddEven">
  <fo:static-content flow-name="HeaderEven"> ...  </fo:static-content>
  <fo:static-content flow-name="HeaderOdd"> ... </fo:static-content>
  <fo:static-content flow-name="Footer"> ... </fo:static-content>
  <fo:flow flow-name="Body">
    <fo:block xsl:use-attribute-sets="BodyText">
      <xsl:apply-templates select="//Lesson" mode="Activity"/>

where it is clear that a single page sequence contains the results of processing all the Lesson elements in the "Activity" mode.

If Sharon doesn't want this, the modification goes here. In order to generate a page sequence for each Lesson, she either wraps the entire page-sequence construct in an xsl:for-each (which will therefore generate a distinct page sequence for each of the nodes it selects), or (better) she moves it into the template matching Lesson in the "Activity" mode (so that each lesson, again, gets its own page sequence) -- which is what she says she had before the problem arose (and what was wrong with it?).

However, speculations and reverse-reasoning notwithstanding, this may or may not solve her problem with the duplicate IDs. Without seeing what IDs are duplicated where, it's just a guess.

This is why offering this fish is less useful than teaching her how to fish. This could be just as much of a red herring as the use of "//" may be (however much we advise against that in principle).

Sharon, if you don't know how to generate and inspect the XSL-FO code before the processor tries to format it, your next step is to figure out how to do this. Depending on what tools you are using, this may or may not be easy. If your current toolset doesn't do it, we can help you acquire and run a tool that does. This will prove more useful to you than any solution to any given problem.

So: what tools are you using? Can you run XSLT on an XML file and generate XML (or HTML)? Or are you equipped with only an XSL-FO formatter whose XSLT transformation engine is built in? If the latter, what is it (sometimes inspecting the intermediate result is easier than you think), and what platform are you running on?


At 10:47 AM 9/20/2007, you wrote:
I apologize as I did not explain myself very well....

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