At 06:52 PM 4/4/2013, you wrote:
It isn't a problem with the implementation, it is a formal aspect of
the specification as cited above.
I figured it probably was, I guess I'm also asking why you would want
to turn off the capability when it is safe? I know I've completed
writing to that file, so why is there a problem - other than some
where in developing the spec someone came up with a rule. I can live
with the rule, just would like to understand the logic.
Could you simply check back to make sure you haven't already created the file?
<xsl:if test="not(preceding::*[@conref=current()/@conref])">
<xsl:result-document href=.......
So, for every unique conref attribute you'll get only a single
invocation of <xsl:result-document>.
When I originally posted the question it was to answer the why and
also get some help in trying to track down where the problem was. I
thought my original situation was as I first posted in which I was
writing 2 different file names. I hadn't found the one file in the
3000 that was really causing the problem which was my follow up post
in which I had 2 references to the same section and was thus writing
the same file twice for that one topic file. I also knew that There
were several other files with exactly the same combination of
references. I needed to make sure I had a single file for all those
references as we will be maintaining these going forward.
Complicating the matter was that I was running within Kernow and it
was handling the logic to walk through the directory structure and
process the files. Its log output doesn't always align with the last
file processed. So based upon files that were around my error in the
list I was finding my initial situation and couldn't understand why
it was complaining - I had two unique names.
I hope this helps.
It does, thanks everyone. I know the what now, even though I don't
understand why the rule exists ;-)
..dan
---------------------------------------------------------------------------
Danny Vint
Panoramic Photography
http://www.dvint.com
voice: 619-938-3610
--~------------------------------------------------------------------
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>
--~--