Hi,
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"/>
</fo:block>
</fo:flow>
</fo:page-sequence>
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?
Regards,
Wendell
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. http://www.mulberrytech.com
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
======================================================================