Thanks for helping.
I can see now why document-uri didn't work for me - I got how it
worked twisted around in my mind.
I haven't figured out how to solve the puzzle yet, but your email and
some careful reading has taught me a bit.
What I think I want to do is find a way to get the document() function
to resolve relative URI's based on the href of the current
<xsl:result-document>
I have noticed that <xsl:result-document> is resolving my relative URI
based on the main output file (as specified).
And that document() is resolving the relative URI based on the source
XSL file (I think as specified).
Because those two are resolving based on different things, I am stuck.
Is is possible to somehow test for the existence of a xml file that is
in the output path when the output path isn't directly known to the
xsl code?
For example.
<xsl:result-document href="01/section.html">
do common stuff
{{If there is a 01/moreinfo.xml then do extra stuff}}
</xsl:result-document>
Note: the 01/section.html file is getting created properly.
When I try to use
<xsl:if test="document('01/moreinfo.xml')">
do extra stuff
</xsl:if>
It doesn't work unless, for testing purposes, I copy my 01 directory
into the directory my source XSL file is at.
re: collection()
Hmmm, read through how that works. I don't have a good way to use a
catalog file (one doesn't exist). I can't use regular expression
because there is no parsable path from the source xsl file to the
output xml file.
New idea.
Maybe I can supply a param in my command line that I can use to let
the XSL know the path to output files.
I was hoping to make the transform logic to be completely in XSL though.
Thanks,
Fred
--~------------------------------------------------------------------
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>
--~--