IE filepath bug.. no end of grief..

Phylobates · August 10th, 2005, 05:19 AM

Sorry that my very first post is a slight rant, but I thought I'd post it anyway if only to save some poor sole wasting hours of their time.. ( I'll try and keep it short.. )

<rant>

Basically I'm generating a CD based on XML, relying on the user's browser XSLT engine to take my XSLT stylesheets to transform the xml to xhtml for display, when I came across this little gem in IE...

In generating the navigation I need to traverse file directories but I found using :

<xsl:value select="document('../index.xml')/document/title" />

is different to ..

<xsl:variable name="mypath" ><xsl:text>../index.xml</xsl:text></variable>
<xsl:value select="document($mypath)/document/title" />

It gives exactly the same result in firefox and the other mozilla based browsers but in IE, the variable version looks for the index.xml in the parent directory of the calling xml document, rather than relative to the folder the xslt file is in... you get a different result depening if you use a variable for the path or hardcode it ... grr ..:(

Three hours I spent tracking that one down, and to make matters worse IE dos'nt fail gracefully when it can't find a file. Unlike Firefox and others which simply return an empty result, IE throws a parser error..

So the only way round this ( that I can think of ) is have the XSLT look for the index file in the wrong place with will work for IE, then catch the empty set that firefox will generate looking in the right place then have it look in the wrong place to make it work....

</endofrant >

Thanks for listening.

------------------------
Has anyone seen the plot ?

mhkay · August 10th, 2005, 12:55 PM

The XSLT spec is quite explicit that the base URI for the document() function is calculated differently depending on whether the first argument is a nodeset or a string. The function also allows you to specify the base URI via a second argument. Ranting because you failed to read the spec is unproductive...

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

Phylobates · August 11th, 2005, 07:30 AM

Apologies, it was'nt ment to be taken too seriously;), but bowing to superior wisdom, I don't understand...

Surley both 'sometext' (in quotes) and the variable passed are both strings, not node sets ? the '../index.xml' is but a string.. , in which case the base URI should be based on the XSLT containing the document() call

And given that Firefox and IE behave differently, which one got it right and which one also didn't read the spec

( BTW.. I did have a quick peruse of the spec, but I could'nt quite identify the bit where the difference in base URI occurs between string and node set, as "When the first argument to the document function is not a node-set, the first argument is converted to a string as if by a call to the string function." unless the "processing instruction occurs in an external entity" which in my simple example I did'nt think applied.

But wait ... Perhaps I should call the string() function on the variable before passing it to the document function, preventing any confusion by the XLST processor .. hmm will give it a try. )

:)

------------------------
Has anyone seen the plot ?

Phylobates · August 11th, 2005, 07:50 AM

Well there you go ! Your confusion thinking that I was passing a node set instead of strings was the big clue to the problem.

I'm guessing that IE thought that '../index.xml' was a node set rather than a sting, thus inserting a call to the string function...

Code:

<xsl:variable name="mypath">
<xsl:text>../index.xml</xsl:text></xsl:variable>
<xsl:value select="document(string($mypath))/document/title" />

yields exactly the same result as...

Code:

<xsl:value select="document('../index.xml')/document/title" />

without the string() call... it all goes the shape of a pear.

Well that simplfies the code somewhat... excellent.

Many thanks.

------------------------
Has anyone seen the plot ?

joefawcett · August 11th, 2005, 08:18 AM

Have you tried:

Code:

<xsl:variable name="mypath" select="'../index.xml'"/>

?

--

Joe (Microsoft MVP - XML)

Phylobates · August 11th, 2005, 10:55 AM

Checked that and yeap that works too!

In my specific instance I'm doing additional stuff in the variable construction, the example I gave was a simplified version to illustrate the issue I was having, so I'll still need the string() function.. but all useful info !

:)

------------------------
Has anyone seen the plot ?

mhkay · August 12th, 2005, 02:46 AM

Actually the situation is a little more complex than described. If you use

<xsl:variable name="x">index.xml</xsl:variable>

then the value of $x is actually a result-tree-fragment rather than a string, and technically you are therefore passing a node-set rather than a string. However, the base URI of the node is taken from the base URI of the stylesheet, not from the source document, in the same way as if you passed a string.

It seems from your evidence that Mozilla is getting this wrong.

And I was perhaps a little presumptious in telling you to go and read the spec, with hindsight I remember I spent hours trying to understand this aspect of the spec and eventually wrote to James Clark asking for clarification. I hope it's clearer in the 2.0 version (and in my book).

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

mhkay · August 12th, 2005, 02:55 AM

Sorry, to correct my response: it seems the Mozilla behaviour is correct, and the IE behaviour is wrong. The only case where a relative URI should be taken as relative to the source document is when the argument you supply to document() is a node in the source document.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference