Subject: RE: Writing out to and reading back from an XML file
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Sun, 1 Aug 2004 19:28:51 +0100
|
It's not clear how you are "writing out" the file.
If you're using XSLT 2.0 xsl:result-document, the spec is quite clear that
it's an error to try and read and write the same resource in a single
transformation. The reason is that XSLT doesn't define the sequence in which
operations are performed. A processor could try and read the file before it
has been written.
More to the point, I don't see why you are trying to do this. With the help
of the xx:node-set() extension in XSLT 1.0, you can create a temporary tree
in memory and use it more than once. You don't have to write it out in
serial form to filestore, and then reread and reparse it.
This expression:
string(namespace::$uri)
should give you an XPath syntax error. I can't correct it for you because I
have no idea what you thought it might mean.
Michael Kay
> -----Original Message-----
> From: Chris Loschen [mailto:closchen@xxxxxxxxxxxxxxxxxx]
> Sent: 01 August 2004 19:07
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Writing out to and reading back from an XML file
>
> Hi again all,
>
> I posted this the other day, but made the mistake of burying
> the question
> down inside an email on
> another subject. Of course, it's also a summer weekend...
> Nevertheless, I
> still can't figure out a
> usable workaround, and I'd appreciate any insights anyone might have.
>
> Here's the situation: I have a very large file which I need
> to parse piece
> by piece, so I'm looping through
> <BillHeader> and <Bill> (many times) and finally
> <BillTrailer> elements. In
> each case, the XSLT is run
> on a single <BillHeader>, <Bill>, or <BillTrailer> rather than on the
> entire XML document, which could be
> several hundred megabytes. So far, so good, but as it turns out, the
> <BillTrailer> output needs to replicate
> most of what's in the <BillHeader> output. The solution I'm
> trying to use
> is to write out the <BillHeader>
> normally, but also to an XML document which can then get
> called back in
> when we get to the <BillTrailer>.
>
> The file is getting written out more or less as expected, and
> has the good
> data, but then the later process
> can't find the file again. The cause appears to be that my
> filesystem has
> spaces in the names (d--n that
> Windows!) so the file isn't getting written out to c:\Documents and
> Settings\ etc. but to c:\Documents%20and%20Settings
> etc. -- I have a complete tree built up on my C drive with all of the
> spaces replaced with %20s. Then the
> later process looks in the current directory and the file isn't there.
>
> I've tried to get the URI of the current directory as a
> string so I could
> then replace the spaces with %20s and
> use that as the base URI of the document() function, but
> wasn't able to
> make that work -- here's the
> code I tried:
>
> <xsl:variable name="header"><!-- not working -->
> <!--<xsl:variable name="base">
> <xsl:variable name="uri">
> <xsl:value-of select="document('')/invoice"/>
> </xsl:variable>
> <xsl:call-template name="translate-space">
> <xsl:with-param name="base"
> select="string(namespace::$uri)"/>
> </xsl:call-template>
> </xsl:variable>
> <xsl:variable name="file">
> <xsl:value-of
> select="concat($base,'/BillHeader.xml')"/>
> </xsl:variable>
> <xsl:value-of select="document($file)"/>-->
> </xsl:variable>
>
> <xsl:template name="translate-space">
> <xsl:param name="base"/>
> <xsl:choose>
> <xsl:when test="contains($base,' ')">
> <xsl:call-template name="translate-space">
> <xsl:with-param name="base"
> select="concat(substring-before($base,'
> '),'%20',substring-after($base,' '))"/>
> </xsl:call-template>
> </xsl:when>
> <xsl:otherwise>
> <xsl:value-of select="$base"/>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
>
> I was getting ClassCast exceptions, probably (I'm not sure)
> from the place
> where I try to cast the namespace as a string
> and then it still couldn't find the document. I also tried
> setting up a
> shortcut to the other file from the current directory but
> that didn't work either -- the file still wasn't found.
>
> So, I think I understand what's happening, but I don't have a
> way around it
> -- any suggestions out there? Thanks!
>
>
> Yours,
>
> Chris Loschen
> closchen@xxxxxxxxxxxxxxxxxx
> 781-718-3017 (cell)
|