After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 125614 - output files and paths for version from CVS-20031027
output files and paths for version from CVS-20031027
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
unspecified
Other All
: Normal major
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks: 124539
 
 
Reported: 2003-10-27 17:32 UTC by Roumen Petrov
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix for tests/multiple/Makefile.am (709 bytes, patch)
2003-11-05 11:22 UTC, Roumen Petrov
none Details | Review

Description Roumen Petrov 2003-10-27 17:32:18 UTC
Test env.:
.../xsltproc --version
Using libxml 20600, libxslt 10033 and libexslt 722
xsltproc was compiled against libxml 20600, libxslt 10033 and libexslt 722
libxslt 10033 was compiled against libxml 20600
libexslt 722 was compiled against libxml 20600


A copy of dict.* files (from CVS 20031027 tests/multiple/) put in:
./xml/dict.dtd
./xml/dict.xml
./xsl/dict.xsl

Test command:
$ mkdir run
$ cd run
$ .../xsltproc ../xsl/dict.xsl ../xml/dict.xml

Output files are:
./xsl/out/titlepage.html
./run/out/letter*.html

Might titlepage.html sould be in ./run/out/, not in dir. where is xsl file ?
Comment 1 Daniel Veillard 2003-11-04 09:15:28 UTC
Could you explain *why* you think 
"Might titlepage.html sould be in ./run/out/, not in dir. where is xsl
file ?"
More precisely, can you point me to any specification that would state
why the output should not be computed by an URI-Reference from the
base of the stylesheet which is what the function does.

  In general, please do your part of the job of explaining why this
is broken, and not just send bug reports of the form
  "I think this should do thing differently" 
without even taking the time to justify your point, which is sometimes
acceptable when the problem can be trivially derived from the
understanding of the underlying specification, but when it is not the
case, it is your duty to explain why and what spec the behaviour
break.
   The only part I could found which would relate to your 
point is in http://exslt.org/exsl/elements/document/index.html
though the stylesheet uses the xt: extension for this not the
exslt one. More precisely that paragraph
-------------------------------
 For each document that is output, there is an absolute URI that can,
in the appropriate circumstances, be used to access that document.
Call this the output URI of the document. The output URI of the main
result document is system-dependent, typically specified when the XSLT
processor is invoked. When the href attribute of a subsidiary document
is an absolute URI, then that absolute URI serves as the output URI.
When the href attribute of a subsidiary document is a relative URI,
the relative URI is resolved into an absolute URI only if and when the
subsidiary document is output. The output URI of the document with
which the subsidiary document is associated (ie the output URI of its
parent in the tree of documents) is used as the base URI. The
resulting absolute URI is used as the output URI of the subsidiary
document.

NOTE: The output URI of a document is not dependent on the base URI of
the root node of the document.
------------------------------- 

  But this is not part of the XSLT spec.

Daniel
Comment 2 Daniel Veillard 2003-11-04 13:05:53 UTC
That said, I found the bug, the precompilation of the document element
was computing the URI-reference agaisnt the base inherited which was
the stylesheet one. Since href is not an URI reference per the EXSLT
documentation I just removed that and this fixes the problem,

  thanks for raising it,

Daniel
Comment 3 Roumen Petrov 2003-11-05 11:19:49 UTC
O.K. thanks.

Before bug to be closed  I would like to attach patch for
tests/multiple/Makefile.am (fixes problem when build != source). This
is because before to know right plase for output files I cannot write
correct patch (Note that this bug is marked as blocking for #124539).
Comment 4 Roumen Petrov 2003-11-05 11:22:14 UTC
Created attachment 21211 [details] [review]
fix for tests/multiple/Makefile.am
Comment 5 Daniel Veillard 2003-11-05 11:39:38 UTC
Okay, applied,

  thanks,

Daniel