I apologize as I did not explain myself very well.
I did not run into the problem of duplicate IDs when I had all the page
sequences contained within a template. And I was able to successful output
with 1 problem, the Lesson page sequence would not repeat. That is when I
decided to try a for-each for the Lesson page sequence and is also when I
encountered the problem w/ duplicate IDs. If I don't use a for-each, I
don't have a problem w/ duplicate IDs but the page sequence does not
repeat.
Thanks for your help!
Sharon
"G. Ken Holman"
<gkholman(_at_)CraneSo
ftwrights.com> To
xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
09/20/2007 10:22 cc
AM
Subject
Re: [xsl] Using for-each w/
Please respond to page-sequence results in "NC105 ID
xsl-list(_at_)lists(_dot_)mu already exists in this
document"
lberrytech.com error
At 2007-09-20 09:56 -0400, Sharon_Harris(_at_)ultimatesoftware(_dot_)com wrote:
Thank you so much for replying.
Those should be ref-id= attributes and not id= attributes. Check
your XSL-FO instance to make sure <page-number-citation> is using
ref-id=.
Yes, I am using ref-id.
Before trying the for-each, I had all the page sequences contained within
a
template. I had 6 page sequences within that template that applied to 5
different elements (cover, disclaimer, toc, introduction, lessons,
evaluation). There are multiple instances of the Lesson element but the
Lesson page sequence did not start over for each instance, which is why I
tried using a for-each. I had the page sequences contained within the
following template.
My quick observation finds the prevalent (and execution wasteful) use
of "//" throughout your stylesheet. I suspect you may misunderstand
the application and utility of this construct. It is the number one
reason why many stylesheets execute slowly, and in this case, the
repetition inferred by "//" is likely causing the duplicate identifiers.
In another message you comment that you cannot see the generated
XSL-FO. You can always inspect your generated XSL-FO by running your
XML with your XSLT outside of the XSL-FO processor as a standalone
transformation.
Looking over the supplied code, I really cannot tell quickly where
things are going wrong.
I suggest again that you generate your XSL-FO standalone and inspect
the results and this should reveal all to you.
As for stylesheet writing techniques, there are limited use cases for
"//" and I tell my students to avoid using it unless they really wish
to traverse the *entire* source node tree looking for
constructs. This is rarely required. Many new users of XSLT think
that "//" is somehow a shortcut, but it is just plain inappropriate.
If I were to guess, I would suspect you are improperly using "//" to
generate multiple copies of XSL-FO constructs with identifiers. But
where that happens will not be known until you inspect the generated
XSL-FO.
I hope this helps.
. . . . . . . . . . Ken
--
Upcoming public training: UBL and code lists Oct 1/5; Madrid Spain
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds: publicly-available developer resources and training
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--