Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
* configure.in: updated
* doc/libxslt-api.xml doc/libxslt-refs.xml libxslt/libxslt.syms
libxslt/xsltwin32config.h win32/libxslt.def.src doc/*.html:
regenerated
|
|
Addition to the removal from the header
31312989ab25faf81f9aa9e41d17e0f8f4fe21e7
|
|
Commit a2cd8a03 broke the --with-python build by moving includes from
INCLUDES to AM_CPPFLAGS. AM_CPPFLAGS gets ignored when a target-specific
*_CPPFLAGS variable exists, but at least some automake versions
automatically add "libxsltmod_la_CPPFLAGS = -shared" to python/Makefile.in
https://bugzilla.gnome.org/show_bug.cgi?id=684637
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=685626
it would assume the system linker for extracting the linker
script options, even if GNU ld is in use. Which breaks on Solaris.
|
|
This patch fixes minor issues in the autogen.sh script:
* Don't print "I am going to run ..." if NOCONFIGURE is set
* Print said message with $srcdir path
* Print said message once, not twice
* Print "Running ..." message once, not twice, and use quoting
|
|
Currently doc/Makefile.am use just build xslt processor, binary
detected from configure or just directly call command xsltproc.
This patch unify use to binary detected from configure script.
|
|
|
|
For nodes from different documents, especially for the document
node itself which would always get "idp0" as a result.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=688171
|
|
This reverts commit c159f4e6f19ffb32d89e4b3e094fd27a2f82b9ac.
As make check was exhibiting various added failures as a result.
|
|
When I configure/build libxslt outside of sources and then run libxslt
tests there are some false positives related to using absolute path
instead of relative.
|
|
|
|
See https://bugzilla.gnome.org/show_bug.cgi?id=685328
Also improve some xsl:key error messages.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=685330
Missing check for NULL
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=684564
|
|
Missing error file from the distribution due to a typo
|
|
From the header as they were never implemented
|
|
* configure.in doc/symbols.xml doc/xslt.html: updated for the release
* NEWS config.h.in doc/* */*.syms : regenerated
|
|
Remove spaces followed by tabs, and space and tabs at the end of lines
|
|
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=519926
Both Xalan and Saxon have a systemId function (in their respective
namespaces) to provide the URI of the file that is being transformed.
It would be nice to have that function in libxslt1.1 as well, because
then DocBook could use it[0].
[0] See line 250 et seq in
/usr/share/xml/docbook/stylesheet/nwalsh/common/stripns.xsl
|
|
It adds the append functionality to <redirect:write> element
equivalent of ESXLT:document which opens the local file in
append mode and remove the XML Declaration, allowing to potentially
stack multiple chunks
|
|
* Added missing $(srcdir)/ qualification to some "[ -s ... ]"
stderr-output reference file checks
* When printing log output for failed tests, quote the log variable, so
that diff output is formatted the way it should be (with newlines!)
and
is not all collapsed into one line
* Updated tests/REC/test-7.1.1-3.out with current output to get rid of a
spurious test failure
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=680938
Variables are forbidden for match or use values of keys
* libxslt/xsltutils.c libxslt/xsltutils.h: allows to add flags
to XPath expression compilation
* libxslt/keys.c: add the XML_XPATH_NOVAR if defined (recent libxml2)
* libxslt/pattern.c: add a missing xpath.h include to make sure the
defintiion is found there too
|
|
Raised by Phil Shafer <phil@juniper.net>
|
|
A prefix of 'xmlns' is actually allowed. It should simply be ignored
if a namespace is given. Without a namespace the lookup by prefix will
fail anyway.
What the spec doesn't allow is an attribute name of 'xmlns' which will
now be rejected.
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=587360
Correct handling of 'xml' and 'xmlns' namespaces in xsl:element and
xsl:attribute.
|
|
|
|
Add test cases for the EXSLT func bug
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=675917
The string wasn't 0 terminated
|
|
The patch 'Various "make distcheck" and other fixes' removes a line
in configure EXTRA_LIBS=... LIBXML_LIBS...
-EXTRA_LIBS="$EXTRA_LIBS $LIBXML_LIBS $M_LIBS"
This is not save as libxslt/Makefile.am define only
|EXTRA_LIBS| as dependency:
|libxslt_la_LIBADD= $(EXTRA_LIBS)|
If platform does not support unresolved dependencies library cannot be linked.
Even with support regression tests fail in python test due unresolved "xml"-symbols .
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=626855
Dates with timezones but no time components are not normalized correctly
Using xsltproc v1.1.26:
$ xsltproc --version
Using libxml 20706, libxslt 10126 and libexslt 815
xsltproc was compiled against libxml 20704, libxslt 10126 and libexslt
815
libxslt 10126 was compiled against libxml 20704
libexslt 815 was compiled against libxml 20704
Dates that have timezone offsets specified but no time components, for
example
"1970-01-01+01:00", are not normalized correctly; the timezone part is
truncated:
date:seconds("1970-01-01") = 0
date:seconds("1970-01-01+01:00") = 0 (not -3600 as expected)
Alters the conditions under which exsltDateNormalize() returns
without normalizing, and adds test cases demonstrating the new behaviour.
|
|
Second part of bug #680920.
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=680920
If the first child of a func:function template is xslt:text, it will be
removed by xsltParseTemplateContent. So xsltParseTemplateContent should
be called before setting func->content to the first child.
|
|
For https://bugzilla.gnome.org/show_bug.cgi?id=569703
The libexslt implementation of str:replace fails to conform to its
specification on several counts:
a) the current version returns a string; it's supposed to
return a nodeset.
b) the current version treats the replacements as strings;
it's supposed to treat them as nodes.
c) the current version can modify replacement text; it's
supposed to only modify text from the original string.
d) the current version ignores the requirement to perform
substitutions in descending order of search string length.
Steps to reproduce:
a) the returning of a string rather than a nodeset can be seen
by simply inspecting the code.
b) the code explicity converts replacement nodes to strings;
this can be seen by inspection.
d) the failure to perform substitutions in descending order
of search string length can be seen in the lack of any
sorting in the source code.
c) the problem of modifying text not belonging to the original
string can be seen in the following stylesheet, which can
be simply applied to itself to produce output.
<xsl:stylesheet version="1.0"
extension-element-prefixes="str exsl"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exsl="http://exslt.org/common"
xmlns:str="http://exslt.org/strings"
>
<xsl:variable name="Text">
Price is $1.10
</xsl:variable>
<xsl:template match="/">
<xsl:apply-templates select="exsl:node-set($Text)/text()"/>
</xsl:template>
<xsl:template match="text()">
<xsl:variable name="Replace">
<FromXml>
<from>$</from>
<from>\</from>
</FromXml>
<ToTex>
<to>\$</to>
<to>$\backslash$</to>
</ToTex>
</xsl:variable>
<xsl:value-of
select="str:replace(.,exsl:node-set($Replace)/FromXml/from,exsl:node-set($Replace)/ToTex/to)"/>
</xsl:template>
</xsl:stylesheet>
Actual results:
The output is:
<?xml version="1.0"?>
Price is $\backslash$$1.10
Expected results:
The output should be:
<?xml version="1.0"?>
Price is \$1.10
Does this happen every time?
yes.
Other information:
str:replace specification is at:
http://www.exslt.org/str/functions/replace/str.replace.html
|
|
|
|
For https://code.google.com/p/chromium/issues/detail?id=140368
|
|
Raised in chromium, but also affecting xsltproc
Also updated AUTHORS to list Chris and other contributors
|
|
Hence matching behaviour of xmlSaveOption XML_SAVE_FORMAT off.
This affects only one of the regression tests
|
|
Leading to possible compilation issue if this isn't in libxml2
|
|
If an XSL stylesheet is from memory (e.g. xmlParseMemory), then xpath
expressions referencing "document('')" will never return a match.
When getting down into it, I understand the logic "document() is resolved
relative to the XSL's location, reading from memory has no location, therefore
buzz off", but the XSL spec seems to address this:
http://www.w3.org/TR/xslt#document
"Note that a zero-length URI reference is a reference to the document relative
to which the URI reference is being resolved; thus document("") refers to the
root node of the stylesheet; the tree representation of the stylesheet is
exactly the same as if the XML document containing the stylesheet was the
initial source document."
The fact that the behavior differs in this case between fromFile & fromMemory
definitely caught me off guard, and IMHO fixing that scenario is worth the
one-off-ness of the fix.
|
|
Similar to the one in libxml2, don't assume threads id are scalars
|
|
Around behaviour and compile flags for localtime and EXSLT date support
|
|
When running xsltproc with the --xinclude option and if the included file
contains parse errors, then xsltproc exits with a success return code (0)
rather than an error code. This is despite the fact that parser error
messages are printed out.
* xsltproc/xsltproc.c: check xinclude processing function return code,
fail with error 6 if it went wrong.
|
|
|
|
|
|
Bug #677901
|