Ohhhhh, that's where I misunderstood it. Since the doc I want to get the
base uri from is the one being processed, I was able to simply do:
document($filename, .)
Thanks much for clearing that up for me.
Eric
Erin Harris wrote:
>The spec says: "The base URI (see [3.2 Base URI]) of the node in the second
>argument node-set that is first in document order is used as the base URI
>for resolving the relative URI into an absolute URI.".
>
>So it looks like an actual node in an existing document is needed for the
>second parameter so it can find the document based on the URI for that
>node. It sounds like all you have is a string that was passed in which
>contains the path.
>
>The following seems to work where both doc1.xml and doc2.xml are in the
>same "docs" subdirectory. It finds doc2.xml based on where it found
>doc1.xml so the full path for doc2.xml does not need to be specified:
>
><xsl:variable name="doc1" select="document('docs\doc1.xml')"/>
><xsl:variable name="doc2" select="document('doc2.xml', $doc1)"/>
>
>Erin Harris
>
>
>
>
>
> "Eric J.
> Schwarzenbach"
> <Eric.Schwarzenba To
> [EMAIL PROTECTED]> xalan-j-users@xml.apache.org
> cc
> 10/25/2005 01:01
> PM Subject
> second parameter of document
> function broken?
>
>
>
>
>
>
>
>
>
>
>I'm finding frustration trying to use the second parameter of the
>document function. (I'm using xalan 2.7.0) It seems like it ought to be
>a simple, useful, and intuitive thing, but damned if I can get it to
>work, or find a good example of it anywhere, from Michael Kay's book to
>the internet.
>
>I've got an attribute from the XML I'm processing that gives me a
>filename, just a filename, because it's local relative to the document
>being processed. I've also got a parameter to the stylesheet (curPath)
>with the base URI from which to find the file. My xlst looks like:
>
><xsl:apply-templates select="document(@filename, $curPath )/*" />
>
>This results in:
>
>SystemId Unknown; Line #0; Column #0;
>org.apache.xml.utils.WrappedRuntimeException: Can not convert #STRING to
>a NodeList!
>
>So, okay, the documentation does indicate that this parameter should be
>a nodeset rather than the simple string one might expect. So I try the
>below (adding a message line to verify the parameter value):
>
><xsl:message>The path param is<xsl:value-of
>select="$curPath"/></xsl:message>
><xsl:apply-templates select="document(@filename,
>xalan:nodeset($curPath)/*" />
>
>file:///C:/work/code/project_a/src/java/com/wrycan/ntm/contenttools/volume_assembler.xsl
>;
>Line #15; Column #16; The path param
>isfile:/C:/project_a/xmlWork/NTM/SUBSYSTEM/
>file:///C:/work/code/project_a/src/java/com/wrycan/ntm/contenttools/volume_assembler.xsl
>;
>Line #17; Column #102; Can not load requested doc:
>C:\work\code\project_a\chapter_1.xml
> (The system cannot find the file specified)
>
>So still it's looking for the file in the current working directory (I'm
>launching java from a command prompt as C:\work\code\project_a), not the
>directory specified in the second document parameter. Am I doing
>something stupid here? Or am I right in thinking that the 2 argument
>version of the document function is broken?
>
>Incidentally I tried this using org.apache.xalan.xslt.Process from the
>command line rather than my own code to make sure it wasn't something in
>my java. Using jdk 1.5.0.
>
>I can get it to work just using string concatination and the one
>argument version of the function, but it seems stupid to have to do this
>when the function offers an argument explicitly for this purpose.
>
><xsl:apply-templates select="document(concat($curPath, @filename))/*"
>mode="content_asset">
>
>So I have a work-around, but I'd really like to resolve whether the
>other way is broken or if I'm doing something flawed.
>
>Thanks,
>
>Eric
>
>
>
>
>
