OK, I'm not entirely sure what you mean here; as I understand it I am using a URI, albeit a relative one. The XSLT spec (remember I'm getting the same result with xsl:include since the resolution code is the same) specifies that relative URIs should be resolved as described in RFC2396. Here are some sample cases for clarity:
1) in stylesheet "http://localhost/test/test.xsl"; I have <xsl:include href="test2.xsl"/> Here this is resolved to http://localhost/test2.xsl, which is as expected (essentially, you strip off up to the previous '/' using the URI of the currently processed stylesheet to provide context). 2) in stylesheet "http://localhost/test/test.xsl"; I have <xsl:include href="http://localhost/includes/include.xsl"/> Here this is resolved to http://localhost/includes/include.xsl. This again is as expected; since the URI reference starts with a full protocol spec, we assume it is absolute and disregard context. 3) in stylesheet "http://localhost/test/test.xsl"; I have <xsl:include href="/includes/include.xsl"/> This is resolved to http://localhost/test//includes/blah.xsl. This is not as expected; this should be resolved as a relative URI that starts with a /; which means in simple terms I expect http://localhost/includes/blah.xsl. 4) in stylesheet "http://localhost/test/test.xsl"; I have <xsl:include href="../includes/include.xsl"/>. This is resolved to http://localhost/test/../includes/blah3.xsl. This is not as expected, it should be resolved to http://localhost/includes/blah3.xsl. (./ and ../ should be processed out of relative URI fragments). (In this case, the server may help you out, or it may not - e.g. if using IIS you can disable parent path support). The latter two cases are not according to the URI spec as I read it. Thanks, Mark > -----Original Message----- > From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]] > Sent: 03 February 2003 16:52 > To: [EMAIL PROTECTED] > Subject: Re: XalanC: bug in relative URI resolving or my brain? > > > > > > > Hi Mark, > > Have you tried using a URI? > > file:///somewhere/somethingorother.foo > > I'm not sure how the code reacts if parameters are not URIs. > > Dave > > > > > > "Mark Weaver" > > <[EMAIL PROTECTED] To: > "Xalan-Dev" <[EMAIL PROTECTED]> > > > cc: (bcc: > David N Bertoni/Cambridge/IBM) > Subject: XalanC: > bug in relative URI resolving or my brain? > 02/02/2003 10:13 > > PM > > Please respond > > to xalan-dev > > > > > > > Xalan-C 1.4 on w2k. > > At some point, I'm calling > XPathExecutionContext::parseXML("/somewhere/somethingorother.foo", > "http://localhost/blah/blah/blah.foo";). The URI is then resolved to > http://localhost/blah/blah/somewhere/somethingorother.foo. This seems > wrong > to me - RFC2396 has "5) If the path component begins with a slash > character > ("/"), then the reference is an absolute-path and we skip to step 7." in > "5.2. Resolving Relative References to Absolute Form". The same happens > for > other such includes (e.g. in stylesheets). > > Sorry if this has come up before. I've had a quick dig through bugzilla, > and can't find anything. Either way, let me know and i'll fix/tell my > users > to go away as appropriate... > > Thanks, > > Mark > > > >
