Re: [xslt] Version Differences

On Sat, Jun 24, 2006 at 06:09:45PM +0200, Tim Van Holder wrote:
> Glenn R. Martin wrote:
> > Failure (Ubuntu Dapper): 
> > grmartin lain:~/Development/MV/Documents/Framework Manual$  xsltproc -o
> > manual.html ../DocBook\ Kit/Customized\ Temp lates/html.xsl file.xml
> > warning: failed to load external entity
> > "../docbook-xsl-current/html/docbook.xsl"
> > compilation error: file ../DocBook Kit/Customized Templates/html.xsl
> > line 5 element import
> > xsl:import : unable to load ../docbook-xsl-current/html/docbook.xsl
> > 
> > Working (MacOS X/Darwin 10.4):
> > gilliam:~/Desktop/MoltenVisuals/Documents/Framework Manual glennmartin$
> > xsltproc -o manual.html ../DocBook\ Kit/Customized\ Templates/html.xsl
> > file.xml
> > Stripping NS from DocBook 5/NG document.
> > Processing stripped document.
> > 
> > Here is line lines 1-7 of the complaining XSL file:
> > <?xml version='1.0'?>
> > <xsl:stylesheet 
> >     xmlns:xsl=""; version="1.0">
> > 
> > <xsl:import href="../docbook-xsl-current/html/docbook.xsl"/>
> > 
> > <xsl:preserve-space elements="programlisting screen synopsis" />
> Well, my _guess_ would be that the semantics of "../" in includes was
> changed to be relative to the file doing the including, not the current
> directory of the process (or vice versa).  Such a change would have to

  The semantic of xsl:include is defined in the XSLT spec, it's an URI
reference pointing to RFC 2396. That mean you compute against a base URI.
The base URI would come from the document relative file name you're passing
on the command line and somehow maybe the conversion from that file path
to an URI has changed between versions. Of course having spaces or / in
filenames makes the conversion more hazardeous
  Seeing exactly what is happening would require a *complete* example
not your shalel output, because sorry I can't use a debugger on your shell
output. Now you can use a debugger on xsltproc to see what is happening
there is you don't want to provide a reproduceable example as requested twice
now. We take patches too usually...

> be in the ChangeLog of libxslt or of its Ubuntu package (depending on
> whether it's plain libxslt behaviour or ubuntu-local changes).

  Most likely a change done in libxml2 when the base is computed for
the document. You won't find anything in libxslt, or in the package changelog
at best in libxml2 internal ChangeLog.


Daniel Veillard      | Red Hat
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]