[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Can I predict the build order of nodes?


Subject: RE: [xsl] Can I predict the build order of nodes?
From: "Kevin Brown" <kevin@xxxxxxxxxxx>
Date: Sun, 14 Feb 2010 22:41:33 -0800

Ken and Micheal:

Thanks. Actually, that is what I thought and I just wanted the official word
... essential both are right, it is application dependent. 

I have not tried fully your ideas but they look perfect although since this
application is purely Microsoft we already know the order. We'll need to
test and make sure it works in both just in case things change as we would
want our XSLs independent of transformer.

One note though ... another oddity for this implementation (as it uses
Microsoft transform because of implementation requirements) ...

You recommended:

<xsl:param name="stylemasterfile" select="/winelist/stylemasterfile"/>

Which we agree with by the way. We would have no problem with this but
cannot figure out why the server implementation of Microsoft XSLT tries to
resolve the full path of the XML file in the document() command --
document($stylemasterfile)/styles. When we use the above method to set the
<param>. It tries to find "styles.xml" in the default Web Server directory
and not in a relative directory to the XSL.

This structure we used (below) does not and the server looks for
"styles.xml" relative to the XSL:

<xsl:param name="stylemasterfile">
      <xsl:value-of select="/winelist/stylemasterfile"/>
</xsl:param>

We tested a few alternatives and have changed to:

<xsl:param name="stylemasterfile"
select="string(/winelist/stylemasterfile)"/>

This works, the document() function in Microsoft's XSL Transform to think it
is relative and does not prepend with the Web Server path.

Maybe explainable behavior, I don't know, but we tried and couldn't use what
we you (and we) thought was correct. It seems Microsoft's transformer treats
these two methods differently. 

That isn't the least of our problems with Microsoft's transform (like it
fails if the file in document() does not exist instead of returning an empty
node set) but it is what we have to work with in this application.

Kevin Brown
RenderX


Current Thread
Keywords