Re: [xslt] This mailing list will be retired by the end of Oct 2022
On Oct 22, 2022, at 12:55, Christoph M. Becker wrote: > > Is there any alternative to be notified about new releases? As far as I > know, Gitlab doesn't offer that, and on the Github mirror, there are > only tags, and subscribing to tags is not supported either. There's the GNOME ftp-release-list which will probably stay available: https://mail.gnome.org/mailman/listinfo/ftp-release-list I plan to announce libxml2 and libxslt releases on XML-DEV as well: http://www.xml.org/xml-dev Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] This mailing list will be retired by the end of Oct 2022
According to [1], GNOME's Mailman platform is being decommissioned which probably means that this mailing list will go away soon. Nick [1] https://mail.gnome.org/archives/foundation-list/2022-October/msg2.html ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Release of libxslt 1.1.37
Version 1.1.37 of libxslt is available at: https://download.gnome.org/sources/libxslt/1.1/ ### Improvements - Don't use deprecated libxml2 macros - Don't mess with xmlDefaultSAXHandler ### Build system - Require automake-1.16.3 or later - Remove generated files from distribution - Add missing compile definition for static builds to Autotools (Mike Dalessio) Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Use character entities to represent non-ASCII characters
On 22/08/2022 17:59, Paul Kinnucan wrote: Is there a was with libxslt to override the output encoding specified by the stylesheet? It should work to poke into the xsltStylesheet struct after parsing: xmlFree(style->encoding); style->encoding = xmlStrdup((xmlChar *) "HTML"); Nic ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Use character entities to represent non-ASCII characters
On 22/08/2022 16:46, Paul Kinnucan wrote: Specifying HTML as the output type does not cause libxslt to generate ASCII with character entities for non-ASCII characters. It works for me: $ cat t.xsl http://www.w3.org/1999/XSL/Transform;> £ $ xsltproc t.xsl t.xsl Note that the output *encoding* must be set to "HTML". Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Use character entities to represent non-ASCII characters
On 19/08/2022 19:41, Paul Kinnucan via xslt wrote: I am trying to use libxslt to transform an XML file that contains non-ASCII characters to an HTML file. Other xslt processors, such as JAXP and Xalan, replace non-ASCII characters with their character entity equivalents, e.g., £ -> However, libxslt simply outputs the UTF-8 rendition of the non-ASCII character. Is there a way to get libxslt to output the equivalent character entity instead? If the output encoding is UTF-8, there's no reason not to output non-ASCII characters as UTF-8 (unless you're talking about non-ASCII characters in URI attribute values). Setting the output encoding to "HTML" should do what you want: This is non-standard, though. You can also set the output encoding to "ASCII", but this will produce numeric character references like "". Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Release of libxslt 1.1.36
Version 1.1.36 of libxslt is available at: https://download.gnome.org/sources/libxslt/1.1/ This release mostly improves the build system. Special thanks to David Seifert! ### Removals and deprecations - Remove SVN keyword anchors - Remove CVS and SVN-related code - Remove README.cvs-commits - Remove ChangeLog - Remove xsltwin32config.h ### Improvements - Simplify xsltexports.h and exsltexports.h - Don't overlink executables with gcrypt - Fix quadratic behavior with variables and parameters - Remove case labels with XPointer location types - Add configure~ to .gitignore - Stop calling deprecated libxml2 functions ### Portability - Use portable python shebangs (David Seifert) - Remove useless __CYGWIN__ checks - Remove cruft from win32config.h - crypto.c: Silence a compiler warning on Windows (Chun-wei Fan) ### Build system - Add missing compile definition for static builds to CMake - Avoid obsolescent `test -a` constructs (David Seifert) - Only link libxml2 statically in purely static build - Set AC_CONFIG_MACRO_DIR - Allow AM_MAINTAINER_MODE to be disabled - Streamline and fix documentation installation - Don't try to recreate COPYING symlink - Remove special configuration for certain maintainers - configure.ac: produce tar.xz only (GNOME policy) (David Seifert) - Detect libm using libtool's macros (David Seifert) - configure.ac: disable static libraries by default (David Seifert) - python/Makefile.am: nest python docs in $(docdir) (David Seifert) - python/Makefile.am: rely on global AM_INIT_AUTOMAKE (David Seifert) - configure.ac: remove useless AC_SUBST (David Seifert) - Use AM_PATH_PYTHON/PKG_CHECK_MODULES for python bindings (David Seifert) - Change libxml2 Python config - Don't check for standard C89 library functions - Don't check for standard C89 headers - Remove --with-html-dir option - Also check for glibtoolize in autogen.sh - Rework documentation build system - Remove old website - CMake: Relax check for enabling crypto support on Windows (Chun-wei Fan) - Remove obsolete AC_HEADER_STDC autoconf macro (Vadim Zeitlin) - Remove special configuration for old maintainers ### Test suite, CI - Remove test involving XPointer range-to function - Test recursion in EXSLT dynamic functions - Add CI job for static build ### Documentation - Move tutorial images Thanks to all contributors! Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Issues using parameters with namespaces
On 28/02/2022 22:07, George Joseph wrote: Actually "//*[name()='dm:device']" works as well so maybe that's what I'll do. This seems like the best work-around. Is there any reason why path parameters with namespaces haven't been supported? Would a pull request to add the namespaces in xsltNewTransformContext be considered? How parameters are passed isn't covered by the standard, so it's up to the implementation to come up with something. It seems natural to allow XPath expressions, but it's not clear how to handle namespaces. Simply taking the namespace defitinions from the root element of the root stylesheet should do what most people expect, but it is somewhat fragile. 1. Passing parameters from the command line Supporting namespaces in a clean way would probably require a separate channel to register namespaces just for parameter evaluation. Even Saxon doesn't seem to support custom namespaces in parameter expressions: "The static context for this XPath expression includes only the standard namespaces conventionally bound to the prefixes xs, fn, xsi, and saxon." [1] 2. Passing parameters using the API The most flexible approach is probably an API to set parameters directly, similar to Saxon's XsltTransformer [2]. This would even allow to pass nodes from external documents as parameters. But if you want to combine that with XPath expressions, you'd have to evaluate them yourself. Nick [1] https://www.saxonica.com/documentation11/index.html#!using-xsl/commandline [2] https://www.saxonica.com/documentation11/index.html#!javadoc/net.sf.saxon.s9api/XsltTransformer@setParameter ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Issues using parameters with namespaces
On 28/02/2022 20:54, George Joseph via xslt wrote: I think it works because xsltProcessUserParamInternal only sets xpctxt->namespaces = NULL but it doesn't clear xpctxt->nsHash which is where xmlXPathRegisterNs puts the namespaces to be registered. Right, the XPath engine uses both ->namespaces and ->nsHash. Can you give me a hint? I've had absolutely no luck is trying to pass a path as a string and getting it to result in something other than "The 'select' expression did not evaluate to a node set" even in an absurdly simple example. I'm passing the path double quoted "'/dm:device'" and have tried various combinations of "select=" and "with-param". Even Google is failing me so any help would be appreciated. I meant that you should only use string or integer literals in parameter values and no other XPath expressions at all. This means to rework your stylesheets, of course. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Issues using parameters with namespaces
On 28/02/2022 18:50, George Joseph via xslt wrote: I've been having a heck of a time trying to pass a parameter to xsltApplyStylesheet that has namespaces in the xpath expression. This use case is simply not supported. Finally I did find a workaround by calling xsltNewTransformContext() then iterating over the nsDefs in the stylesheet document and calling xmlXPathRegisterNs on ctxt->xpathCtxt for each nsDef. I'm a bit puzzled that this worked at all. See the code here: https://gitlab.gnome.org/GNOME/libxslt/-/blob/master/libxslt/variables.c#L1581 But the expression is compiled before resetting the namespaces, so I guess that's why. I would have thought this would have been done automatically though. Did I miss something or is there a better way to do this? No, I'd recommend that you only use string and integer params. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [xml] Support libxml2 and libxslt on Open Collective
On 23/02/2022 23:39, Eberhard wrote: Dumb question. How do I contribute in dollars? I get Euros and no option to change. E Everything should be set to USD now. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Support libxml2 and libxslt on Open Collective
Hello, You can now support libxml2 and libxslt financially on Open Collective: https://opencollective.com/libxml2 All donations go through the Open Source Collective, a non-profit organization providing financial and legal infrastructure for thousands of open source projects. https://www.oscollective.org/ If you prefer, you can also support me directly. Just get in touch by email. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Release of libxslt 1.1.35
Version 1.1.35 of libxslt is available at: https://download.gnome.org/sources/libxslt/1.1/ Note that conflict resolution for templates was fixed to match the spec. When there are multiple matching templates with the same priority, libxslt now uses the template that occurs last in the stylesheet. This can potentially break stylesheets that rely on the old, badly predictable and non-conformant behavior. The solution is to reorder affected templates. Security - [CVE-2021-30560] Fix use-after-free in xsltApplyTemplates - Fix memory leak in xsltDocumentElem (David King) - Fix memory leak in xsltCompileIdKeyPattern (David King) - Fix double-free with stylesheets containing entity nodes Fixed regressions - Fix performance regression with predicates in patterns - Fix regression in xsltComputeSortResult Bug fixes - Fix conflict resolution for templates with same priority - Fix xsl:number generating invalid UTF-8 - Support attribute value templates in xsl:sort lang attributes - Don't pass first in twice - Fix quadratic runtime with text and - Don't allow empty EXSLT durations Improvements: - Add xsltproc --huge Argument via libxml XML_PARSE_HUGE (William N. Braswell, Jr.) Tests, code quality, fuzzing: - Remove .travis.yml - Fix some misleading indentation (David King) - Use actual types for templates in struct _xsltStylesheet - Add CI for CMake on MSVC (Markus Rickert) - Check for null pointer before calling freelocale - Add CI test for Python 3 - Don't set maxDepth in XPath contexts - Transfer XPath limits to XPtr context - Stop using maxParserDepth XPath limit - Make long-to-double cast explicit in date.c - Disable LeakSanitizer - Run clang CI tests with -Wimplicit-int-conversion - Fix implicit-int-conversion warning in exslt/crypto.c - Fix clang -Wimplicit-int-conversion warning (David Kilzer) - Fix clang -Wconditional-uninitialized warning in libxslt/numbers.c (David Kilzer) - Fix -Wshadow warnings in libexslt/dynamic.c (David Kilzer) - Also search parent dir for source XML when fuzzing Build system, portability: - Add CMake build files (Markus Rickert) - Initial support for Python 3 (Suleyman Poyraz) - Call ANSI versions of WinAPI functions explicitly - Remove redundant flags from pkg-config files - Suppress automake warning in tests/XSLTMark - Fix linking libexslt dynamic library when using MinGW (Vadim Zeitlin) - Added platform specific path separators (Dmitriy Korovkin) - win32: allow passing *FLAGS on command line - Fix export of xsltExtMarker on Windows (David Kilzer) - Fix redundant includes already in libexslt.h (David Kilzer) - Minor fixes to configure.js - Fix variable syntax in Python configuration - Add new EXSLT string tests to EXTRA_DIST - Fix xml2-config check in configure script - win32: Add configuration for profiler (Chun-wei Fan) - Check whether 'xml2-config --dynamic' is supported Documentation: - Add Makefile rule to regenerate xsltproc.html - Update links - Remove MAINTAINERS - Upload documentation to GitLab Pages - Add documentation in devhelp format - Add --enable-rebuild-docs configure option - Fix libexslt header summaries - Fix validity of tutorial XML (David King) - Use DocBook URL for tutorial DTD (David King) - Update libxslt.doap - Add missing options to xsltproc man page Thanks to all contributors. Special thanks to Markus Rickert for adding CMake support! Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Performance issue
On 10/02/2022 13:59, Geoffroy Arnoud via xslt wrote: We are facing a performance issue on a processing using Python lxml. The xslt used is at the end of this message. I tried the XSLT file with several inputs and libxslt versions and couldn't see any slowdown. Please post a complete, reproducible test case, preferably on the bug tracker: https://gitlab.gnome.org/GNOME/libxslt/-/issues Otherwise, it's impossible to help you. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Extension Function Implementation
You have to create and register a "result value tree" by calling xsltCreateRVT
and xsltRegisterLocalRVT, then add the nodes you want to return to that tree.
Have a look at functions like exsltStrTokenizeFunction to see how it works:
https://gitlab.gnome.org/GNOME/libxslt/-/blob/master/libexslt/strings.c
Hope that helps,
Nick
On 05/10/2021 12:30, Андрей Олешкевич via xslt wrote:
I am trying to create an xslt extension function for libxslt (c++). My
extension function takes a string as input, then this string is parsed by xml
parser, and the function returns this parsed xml. I return value by this
expression:
void fnParse(xmlXPathParserContextPtr ctx, int nargs) { ...
xmlXPathReturnNodeSet(ctx, xmlXPathNodeSetCreate(node)); }
But I have found that libxslt does not free node memory after use. It free
xmlNodeSet, but not free the node which is stored in this nodeset. Perhaps I
missed something important. What is the correct way to return an XML node in
the extension function?
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Stepping down
I never really asked for it but in the last years I became de-facto maintainer of both libxml2 and libxslt. Luckily, I was able to fund my involvement through Chrome VRP bug bounties and OSS-Fuzz integration rewards. Big thanks to Google for these outstanding programs. Unfortunately, returns from security research are diminishing quickly and I see no way to obtain a minimal level of funding anymore. So I'm stepping down as contributor and maintainer. Thanks to everyone who reported bugs and contributed patches! Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Override of attributes from attribute set
> On Dec 12, 2019, at 15:39 , Bob Kline wrote: > So the only remaining puzzle is: why is there nothing in the bug tracker > (would have saved a bunch of time and work)? Did this really get discovered > and fixed without a ticket? The bug was reported on the mailing list https://mail.gnome.org/archives/xslt/2019-February/msg0.html and fixed here: https://gitlab.gnome.org/GNOME/libxslt/commit/65f59eb13dc8cceff89534fdb691881a1811738f Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Any chance of a new release?
On 16/10/2019 22:49, Alexey Neyman wrote: Is there a chance for the 1.1.31 release any time soon? It's been more than two years since the last release, and there has been a number of bugfixes accumulated on master. The latest release is 1.1.33 from January 2019: ftp://xmlsoft.org/libxml2/ Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Private libraries incorrectly passed to command line when linking dynamically
On 26/06/2019 13:51, Hugh McMaster via xslt wrote: In xslt-config, Debian patches the source to add a new switch, --static, which combines with --libs to output the dependencies required for static linking. Private dependencies are not passed to the command line when --libs is invoked as normal. This breaks users who are linking with a static libxslt library. The switch should probably be changed to `--dynamic` when linking dynamically. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Private libraries incorrectly passed to command line when linking dynamically
These patches seem to rely on your patched version of xml2-config, so we should get your xml2-config changes upstreamed first. Nick On 26/06/2019 13:51, Hugh McMaster via xslt wrote: Hi, libxslt.pc, libexslt.pc and xslt-config all incorrectly pass private library dependencies (such as libm and libgcrypt) to the command line when linking dynamically. This causes un-necessary dependencies to be created. For many years, Debian has patched libxslt to avoid this problem. In libxslt's pkg-config files, M_LIBS and LIBGCRYPT_LIBS are moved to the Libs.private field, where they will only be passed to the command line if --static is passed to pkg-config. In xslt-config, Debian patches the source to add a new switch, --static, which combines with --libs to output the dependencies required for static linking. Private dependencies are not passed to the command line when --libs is invoked as normal. This problem was identified as still present when patching upstream PHP 7.4 to use libxslt's pkg-config files. Patches are available in a merge request #3 on Gitlab [1]. Regards, Hugh ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Undefined symbols on Solaris
On 14/02/2019 14:43, Libor Bukata via xslt wrote: during the compilation of libxstl-1.1.33 I encountered the following linkage error on Solaris. CCLD xsltproc ld: warning: file /builds/lbukata/29251802.libxslt.ST/components/libxslt/build/i86/libxslt/.libs/libxslt.so: linked to ../libxslt/.libs/libxslt.so: attempted multiple inclusion of file Undefined first referenced symbol in file xsltCopyTree../libxslt/.libs/libxslt.so xsltDefaultTrace../libxslt/.libs/libxslt.so ld: fatal: symbol referencing errors It seems that xsltCopyTree and xsltDefaultTrace symbols defined in transform.c are required to build xsltproc binary. Both symbols are static and only used in transform.c. I suspect there's something else going on. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Solving the release situation of libxslt-1.1.33
On 22/11/2018 19:14, Daniel Veillard via xslt wrote: Let's test that RC2 and push the final release at the same time as the next release of libxml2, at the end of the next week, then we can go back to a more normal mode of release !!! Built and tested succesfully on: - Windows 10 - MingW64, gcc 7.2.0, both 64 and 32 bits. The EXSLT crypto:rc4 tests still fail, but I have a fix for that. A small problem turned up when testing the 32-bit build [1] but this is a long-standing issue. - MSVC 14.11 - macOS 10.14 with stock command-line developer tools Nick [1] https://gitlab.gnome.org/GNOME/libxslt/issues/7 ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Solving the release situation of libxslt-1.1.33
On 23/11/2018 08:14, Daniel Veillard wrote: Can you update the changelog (I think the source file is doc/xslt.html) and make sure that NEWS is actually regenerated (it's currently still at version 1.1.29)? The generated HTML files in doc/EXSLT are out of date, too. Hum, weird indeed, I wonder what is going on there ... I think it's related to having generated files under version control. See https://bugzilla.gnome.org/show_bug.cgi?id=789908 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Solving the release situation of libxslt-1.1.33
On 22/11/2018 19:14, Daniel Veillard via xslt wrote: So I just tagged RC2 of 1.1.33 in git and pushed the signed tarball and rpms to the usual place: ftp://xmlsoft.org/libxslt/ Can you update the changelog (I think the source file is doc/xslt.html) and make sure that NEWS is actually regenerated (it's currently still at version 1.1.29)? The generated HTML files in doc/EXSLT are out of date, too. It would also be nice if you could push all changes made for the release candidate to the master branch. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Still issues with functions
On Sep 26, 2018, at 20:17 , Nikolai Weibull via xslt wrote: > I have no suggestion as to why this is happening, but I assume it has > something to do with the latest modifications of the handling of functions > and result trees fragments and such. Yes, in one of my previous commits, I made an assumption that turned out to be wrong. The issue should be fixed now: https://gitlab.gnome.org/GNOME/libxslt/commit/5e16672db1188accbde737f0add01213ffed107e Thanks for the report and sorry for the inconvenience. The memory management of result tree fragments in func:results is hairy stuff. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [PATCH] really declare dllexport/dllimport for Cygwin
Thanks, patch applied here: https://gitlab.gnome.org/GNOME/libxslt/commit/6abf3c481cf12ecd2b0a8fc5f2903e15d8904673 On 29/05/2018 11:59, Michael Haubenwallner wrote: Cygwin does not define _WIN32, but still requires dllexport/dllimport tags for when applications use the --disable-auto-import linker flag, probably set by the gl_WOE32_DLL autoconf macro in woe32-dll.m4 file. --- libexslt/exsltexports.h | 4 ++-- libxslt/xsltexports.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libexslt/exsltexports.h b/libexslt/exsltexports.h index bead915c..21c49a4a 100644 --- a/libexslt/exsltexports.h +++ b/libexslt/exsltexports.h @@ -111,8 +111,8 @@ #endif #endif -/* Cygwin platform, GNU compiler */ -#if defined(_WIN32) && defined(__CYGWIN__) +/* Cygwin platform (does not define _WIN32), GNU compiler */ +#if defined(__CYGWIN__) #undef EXSLTPUBFUN #undef EXSLTPUBVAR #undef EXSLTCALL diff --git a/libxslt/xsltexports.h b/libxslt/xsltexports.h index 825c122e..37b43bf2 100644 --- a/libxslt/xsltexports.h +++ b/libxslt/xsltexports.h @@ -113,8 +113,8 @@ #endif #endif -/* Cygwin platform, GNU compiler */ -#if defined(_WIN32) && defined(__CYGWIN__) +/* Cygwin platform (does not define _WIN32), GNU compiler */ +#if defined(__CYGWIN__) #undef XSLTPUBFUN #undef XSLTPUBVAR #undef XSLTCALL ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Libxlst doesn't successfully build/install in a flatpak environment?
On 16/08/2018 01:44, Adrian Lucrèce Céleste wrote: Also tried building from master, and got a similar looking issue: Full log: https://gist.github.com/AdrianKoshka/853b648be33f30b504f8ec76bac9f793 For some reason the declaration of xmlBufferDetach isn't found: strings.c:414:32: warning: implicit declaration of function ‘xmlBufferDetach’ [-Wimplicit-function-declaration] xmlXPathReturnString(ctxt, xmlBufferDetach(buf)); ../libexslt/.libs/libexslt.so: undefined reference to `xmlBufferDetach' I have no idea why this happens. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Libxlst doesn't successfully build/install in a flatpak environment?
On 15/08/2018 03:23, Adrian Lucrèce Céleste wrote: A full build log can be found here: https://gist.github.com/AdrianKoshka/4802b4c99a4bb2430128ba24b94e078c This compilation error should have been fixed with this commit: https://gitlab.gnome.org/GNOME/libxslt/commit/5415e64dc25534d22f5f70dd44f454b5f6a55ec6 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] stylesheet causes segfault in libxslt
On 23/07/2018 16:38, Martin Gieseking wrote: I just stumbled over a segfault produced by one of my conversion scripts after updating from libxslt 1.1.28 to 1.1.32. The issue is caused by access of already freed heap memory in function xsltInitCtxtKey. After a bit of debugging and bisecting it turned out that the issue was probably introduced by https://github.com/GNOME/libxslt/commit/470b17346163ba3deceb29eb4149ae140b595cdd. Should be fixed with https://gitlab.gnome.org/GNOME/libxslt/commit/7d81bd62d5788a9e2931c20a3d0a6be7e703c608 Also see https://gitlab.gnome.org/GNOME/libxslt/issues/2 Thanks for the report. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] xsltproc xalan:write problem
On 28/02/2018 16:01, Aaron Gray wrote: I needed the 'select' in order to allow XPath generation of filenames rather than them being a set constant filename with 'href'. The `href` attribute of xsl:document and exsl:document is interpreted as attribute value template. Strings in curly braces are evaluated as XPath expressions, for example Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] xsltproc xalan:write problem
On 28/02/2018 11:15, Thomas Schraitle wrote: I would like to point you to another alternative: the exsl:document[1] extension element. It does the same and is also supported by libxslt. libxslt also supports xsl:document (in the standard XSLT namespace) from XSLT 1.1: https://www.w3.org/TR/xslt11/#multiple-output Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Time for some releases
On 21/01/2018 07:22, Daniel Veillard wrote: I think it's time for a new set of releases, I failed to push in the last 2 months and a number of patches have accumulated since november, so I think entering freeze on Mon or Tuesday, then having rc2 around end of week for a release early around 29-30 Jan would make sense, unless there is something pending, There's nothing pending from my side. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Pull request : xsltproc --fileparam
On 17/01/2018 15:47, Vincent Lefevre wrote: I'd say that this is unusual, but why not? Is there a limit given by the standards? The standard leaves handling of parameters entirely to the XSLT processor. Moreover, $() is lossy as it strips the trailing \n characters. Not if $() is inside double quotes which prevent Field Splitting. Field splitting is a different thing. You're right. I was thinking about embedded newlines although you clearly mentioned trailing newlines. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Pull request : xsltproc --fileparam
On 17/01/2018 18:11, Edouard Tisserant wrote: Mainly to be able to import files/string that contain a random mix of double and simple quotes. xsltproc --stringparam paramname "a\"b'c" I have no idea why xsltproc disallows mixing of single and double quotes in stringparams. This makes no sense to me and should definitely be changed. It worked fine (just a bit slow) on Firefox's Transformiix. JS xslt interface allows passing freely any types as parameters, including huge strings and even node sets. The C API and most language bindings should allow this as well. (what about a --xmlfileparam for xsltproc ?) I'd suggest to pass a filename as normal parameter and use the `document` function to read the XML document. I'd like to get the parser working on libxslt too. Unfortunately, it relies on exslt:regex. I'll try implement exslt:regex on my repo... stay tuned ;) This sounds useful, but the big question is which regex flavor to use. The EXSLT spec vaguely mentions "Javascript regular expression syntax" without a specific version or standard document. IMO, it makes more sense to reuse the regex implementation of libxml2 which seems to be based on XML Schema and should be more aligned with XPath 2.0. Any known previous attempt ? Not that I know of recently, although there might have been attempts in the past. Any recommendation before I start ? Looks like a tab/space hell in there... What should be the rule ? Yes, it's a wild mix of tabs and spaces. Personally, I prefer spaces. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Pull request : xsltproc --fileparam
On 17/01/2018 13:58, Vincent Lefevre wrote: On 2018-01-17 13:34:07 +0100, Nick Wellnhofer wrote: Why don't you simply use something like --stringparam fileparam "$(cat test.txt)" What if the text is too long for the command line? I'd argue that xsl:param wasn't meant to handle multi-KB strings. Moreover, $() is lossy as it strips the trailing \n characters. Not if $() is inside double quotes which prevent Field Splitting. The best solution is probably to implement an extension function similar to `unparsed-text` from XSLT 2.0. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Pull request : xsltproc --fileparam
On 15/01/2018 22:50, Edouard Tisserant wrote: I added a --fileparam switch to xsltproc command line to enable loading file content as stylesheet parameter string literal. It also enhance --stringparam as a side effect. I hope you'll find this useful. $ xsltproc --param param "2+3" --stringparam stringparam "2+3" --fileparam fileparam test.txt test.xsl test.xml 52+3Hello World Why don't you simply use something like --stringparam fileparam "$(cat test.txt)" Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Rework locale feature tests
On 09/01/2018 12:47, Vojtech Fried wrote:
I think there never was a configure option for locale support. It certainly
isn't a feature that was removed.
I would have to check for unix, but for windows, there was a support for turning locales
off (via configure.js). And it was removed in the commit "Rework locale feature
tests".
For Windows, that's possible. I was thinking about UNIX.
A custom sort function overrides the internal sort function. It shouldn't
matter whether libxslt is compiled with locale support or not.
My sorting function (slightly modified version of libxslt/examples/
xsltICUSort.c) internally calls xsltComputeSortResult, which uses a locale if
set. Maybe my sorting function could deal with it (e.g. it could have its own
version of xsltComputeSortResult), but the easiest way was to turn locale
support off completely. I do not need it, since I do the sort myself.
I see. I'd suggest to use your own version of xsltComputeSortResult from
libxslt/xsltutils.c and remove the following lines:
if (comp->locale != (xsltLocale)0) {
xmlChar *str = res->stringval;
res->stringval = (xmlChar *) xsltStrxfrm(comp->locale, str);
xmlFree(str);
}
Nick
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Rework locale feature tests
On 15/12/2017 12:43, Vojtech Fried wrote: I have tried to update my libxml & libxslt used in my project. One problem I see is with sorting and locales. I used to use (a modified version of) xsltICUSort.c (in xslt/examples) to do sorting. (I can send you my version, if you are interested, but it is a long time since I did the changes and I do not remember the details) If I remember right it required to turn the locale support off. This is no longer possible. I think there never was a configure option for locale support. It certainly isn't a feature that was removed. I tried the new implementation of sort, but I get different results in my project tests. E.g. sort without lang works in a different way. Sort with lang handles upper/lower case sorting in a different way. Maybe the behavior of the underlying ICU library changed? And I have a vague memory, that you have to have system support for the locales for them to actually work, which is not what I want, I want the sort to work on any system in any configuration. A custom sort function overrides the internal sort function. It shouldn't matter whether libxslt is compiled with locale support or not. Is using an external sorting function still a supported feature? Would you consider reintroducing the possibility to turn off locale support? External sort functions are still supported. It's possible that something broke in libxslt but we'd need more details. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] xslt-1.1.32: compiler warnings (build completes, make check 'fails')
On 12/11/2017 17:02, Michael Felt wrote: + CPPFLAGS="-I/opt/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5"\ ../src/libxslt-1.1.32/configure\ Running configure directly in the source directory should make most test errors disappear. ## Running general tests bug-146 result 1,6d0 < < < CURR_ID_3=""> < < < 0a1,4 > ../../../src/libxslt-1.1.32/tests/general/bug-146.xsl:1: parser error : Unsupported encoding windows-1251 > > ^ > cannot parse ../../../src/libxslt-1.1.32/tests/general/bug-146.xsl Probably caused by building libxml2 without iconv. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Candidate release 2 of libxslt-1.1.31
On 02/10/2017 14:58, Daniel Veillard wrote: I pushed the RC2 of libxslt-1.1.31, the only difference is that patch on the regression tests output. Assuming no issue I will likely push 1.1.31 tomorrow or early Wed, I made another change to fix the MSVC build: https://git.gnome.org/browse/libxslt/commit/?id=cfca98095171695979cb6d2b89b705562b43448a Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Candidate release 1 of libxslt-1.1.31
On 28/09/2017 21:28, Daniel Veillard wrote: Seems to work here though I had a spurious error message in the regression testing about undefined variables... that could be a side effect of libxml2 update though, something to double-check before rc2. Fixed: https://git.gnome.org/browse/libxslt/commit/?id=42f5378a0a8dee89a51aefc5a05446d3a99ec756 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [PATCH] New-line terminate error message that missed this convention
On 12/05/2017 16:10, Jan Pokorný wrote: That could confuse library users that set their own error handler, because there are already cases in libxslt that push a single message in chunks (the same way as libxml2 does) and the user may be interested in performing the message reconstruction on its own. Applied here: https://git.gnome.org/browse/libxslt/commit/?id=896caefc40111ac225a36500fe464f5d18a955c8 Thanks for the patch, Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] new release
On 28/04/2017 12:07, Frederik Bosch | Genkgo wrote: Is there any new release planned? I see there were quite some changes after 1.1.29. Daniel Veillard originally announced time-based releases for libxml2 and libxslt in April 2016: https://mail.gnome.org/archives/xml/2016-April/msg00014.html Unfortunately, this plan wasn't followed through. Daniel, if there's anything I can do to help getting a new release out, please let me know. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [PATCH] Link libraries with libm
On 10/02/2017 14:25, Jussi Kukkonen wrote: --- a/libxslt/Makefile.am +++ b/libxslt/Makefile.am @@ -62,7 +62,7 @@ else LIBXSLT_VERSION_SCRIPT = endif -libxslt_la_LIBADD = $(LIBXML_LIBS) $(EXTRA_LIBS) +libxslt_la_LIBADD = $(LIBXML_LIBS) $(M_LIBS) $(EXTRA_LIBS) I'd put M_LIBS after EXTRA_LIBS here. Apart from that, go ahead and push. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] libxslt-1.1.29 failed to compile on Solaris Sparc / Inte
On 02/12/2016 10:42, Fabrice Manfroi wrote: I'm trying to build the last libxslt 1.1.2 on Solaris 10 Sparc with solaris studio 12.3 but it fails with the following link errors: It seems there is a problem with the ./libxslt.syms and the Sun linker. I made a small patch (in attachement) in order to temporary fix the problem for my needs, but I hope that someone can point me to a better way to adress this issue. I made some fixes to the scripts and source files used to generate libxslt.syms and recreated it. Can you try again with the master branch? Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] python-config not found during configure - is this 'bad'?
On 02/11/2016 11:28, Michael Felt wrote: adding xslt now: again, a small thing I expect - getting this message: ../../src/libxslt-1.1.29/install-sh: ../../src/libxslt-1.1.29/doc/html/index.sgml does not exist. Yes, this is harmless. I'll remove the corresponding command from the Makefile. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XSLT compilation is slow for big XSLTs
Hi Christian, I tried to close your Github pull request by mentioning it in the commit message but it didn't work. Can you please close the pull request yourself? Nick On 14/09/2015 14:50, Christian Ceelen wrote: Thanks a lot Nick! ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XSLT compilation is slow for big XSLTs
On 07/09/2015 09:47, Christian Ceelen wrote: Did anyone find the time to look into this or test this? I just pushed a slightly modified version of your pull request to master: https://git.gnome.org/browse/libxslt/commit/?id=aed0cca049bdd89043d38af931adccf24acbe6f1 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XSLT compilation is slow for big XSLTs
On 31/08/2015 07:25, Daniel Veillard wrote: That looks mostly fine, but how do one download an unified patch from github without having to clone the whole damn thing ? There is nothing in the UI to download from the patch: Simply run git fetch https://github.com/cceelen/libxslt.git optimize-compilation-for-many-named-templates:optimize-compilation-for-many-named-templates And you have the pull request in a local branch. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XSLT compilation is slow for big XSLTs
On 27/08/2015 17:23, Christian Ceelen wrote: Ok. I will get through this. I tried to change the imports.c code before. But it broke the execution. It doesn't find the templates correctly. I am not sure for what reason. Do i miss something while filling the hash table? The code that populates the hash table looks fine. Can you show the changes to imports.c that didn't work? Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XSLT compilation is slow for big XSLTs
On 19/08/2015 10:47, Christian Ceelen wrote: At the moment i do not have a deep understanding of the libXSLT code. My current guess is, that this point at which the template name is validated to be unique in the stylesheet. The current algorithm seems to be walking linearly through the list of all already created templates and is comparing the name with each. Given that the compilation process is walking through all templates this loop means that we have an O(n^2) algorithm (with n being the number of template instances in the stylesheet to compile). The huge number of templates in my XSLTs are just so far over the edge, that the compilation takes 35s. I ran a test in which i skipped the loop. This reduced the compilation time to below 2.5 s. Would anyone let me know if i have understood the code? What can i do to improve the code that would get easily accepted and released? I am open to any kind of suggestions on what to do to speed this validation step up with a data structure or mechanism already existing ? Yes, template names are verified by searching a linked list which is O(n^2). Template lookup by name uses the same list: https://github.com/GNOME/libxslt/blob/master/libxslt/imports.c#L375 It shouldn't be too hard to change the code to use an xmlHashTable: https://github.com/GNOME/libxml2/blob/master/include/libxml/hash.h Simply add a the hash table to struct _xsltStylesheet https://github.com/GNOME/libxslt/blob/master/libxslt/xsltInternals.h#L1509 add some initialization and cleanup, then use xmlHashAddEntry2 and xmlHashLookup2 with the template's name and namespace URI. This should make name verification O(n) overall and lookup of a single template by name O(1). What is now the developer or working repository for libxslt? I found the git repository on git.gnome.org http://git.gnome.org, the GNOME/libxslt on github, plus several forks which seem to be working repos. Can you point me please to the repo against which i should use for further investigation or patches? The official repo is the one at git.gnome.org: https://git.gnome.org/browse/libxslt/ Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [xml] libxslt does not check extension function existence at creating stylesheet time
On 14/05/2015 16:03, ajay bhadauria wrote: Hello, We are compiling stylesheet which has dependent xslt files through import. These dependent xslt files have extension functions. We noticed at stylesheet creation time , libxslt does not check on the existence of the extension functions. However, at validation time when we apply the stylesheet , we get the error indicating that the extension function is not found. We register the extension functions through xsltRegisterExtModuleFunction() providing the correct namespace and callbacks. Could you please help us 1. Why it does not complain extension function during stylesheet creation ? In order to allow Forwards-Compatible Processing: http://www.w3.org/TR/xslt#forwards 2. Why it is not finding function at validation time ? It's hard to tell without a reproducible test case. Please show us your code and the exact error message. Also note that I moved this discussion to the libxslt mailing list (xslt@gnome.org). Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Memory issues after PHP 5.5 upgrade
On 18/04/2015 00:14, Lance Hutcheson wrote: I have inherited an PHP application that makes extensive use of XML and XSLT. After upgrading PHP from 5.4.xx to 5.5.23, the memory usage of transformations using XSLTProcessor::transformToDoc have gone through the roof. I have debugged the PHP and XSL as much as I can even though nothing in the code itself changed - just upgraded PHP. In an example transformation involving an XML file that is 2.9MB in size, the PHP/Apache process prior to the transformToDoc call shows 390MB of memory usage and immediately following the transformToDoc call, the process shows to be consuming 2.4GB of memory. (The PHP function memory_get_usage() returns 6461888, so PHP doesn't hit its memory_limit.) I don't have any hard numbers from the PHP 5.4 setup, but there were no memory spikes like this. With larger XML documents, we are seeing a single Apache process consume 50+GB of memory. This looks more like a PHP issue to me. Maybe you should try to post it on a PHP list or bug tracker first. If you think this issue is related to libxslt and not PHP, please provide a minimal, reproducible example. Also tell us which libxslt and libxml2 version your PHP 5.4 and 5.5 installations use. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Strange problem
On 17/02/2014 14:52, Tobias Hoffmann wrote: Hi, with debian testing, esp. libxslt1.1_1.1.28-2_i386, using xsltproc bug.xsl in.xml results in rootas/!-- c --dbs/!-- f --e/root instead of the expected original ordering. Confirmed with Ubuntu 13.10, i386. Issuing valgrind xsltproc bug.xsl in.xml makes the bug disappear: rootas/b!-- c --ds/e!-- f --/root Valgrind does not report any error, though. Also confirmed. Analyzing the differences in these two build processes, I found that ./configure LDFLAGS=-pie is enough to trigger the problem. It's also sufficient to compile/link xsltproc with it. Same here. I don't really know how to proceed from here. Maybe someone with more knowledge of libxslt has some idea, what the root cause could be? I suspect that -pie is just another trigger, just as valgrind suppresses the buggy behavior... When I linked against the latest version of libxml2 from Git, the error disappeared (also with -pie). Seems that the commit Fix XPath node comparison bug fixed the issue: https://git.gnome.org/browse/libxml2/commit/?id=fcd458318916809edc4fc4cd1ce2d5ba9aed4665 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [PATCH 0/3] Fix NULL deref through valuePop retval
On Dec 18, 2013, at 23:20 , Jan Pokorný jpoko...@redhat.com wrote:
I found a segfault arising from either lack of fail fast principle
(does it make sense to try further if the template is evidently
wrong, e.g., because of referencing undefined variables?) or because
of allowing for NULL pointer dereferences -- in my case those were
related to valuePop() return values.
Thanks for the report. Checking the return value of valuePop() is not really
necessary because the libxml2 XPath engine tries to guarantee that every XPath
function can pop ‘nargs’ valid, non-NULL values off the stack:
https://git.gnome.org/browse/libxml2/tree/xpath.c#n13530
In your case this doesn’t work because of this check here:
https://git.gnome.org/browse/libxml2/tree/xpath.c#n2829
if (ctxt-valueNr = ctxt-valueFrame) {
xmlXPatherror(ctxt, __FILE__, __LINE__, XPATH_STACK_ERROR);
return (NULL);
}
The call frames are borked because of the non-existing variable.
I think this should be fixed in libxml2. The following patch works for me but
I’ll have to give the whole thing a closer look.
It still might be a good idea to check the return values of valuePop() as a
safety measure.
Nick
diff --git a/xpath.c b/xpath.c
index 1f56b96..6b2cce5 100644
--- a/xpath.c
+++ b/xpath.c
@@ -13524,9 +13524,11 @@ xmlXPathCompOpEval(xmlXPathParserContextPtr ctxt, xmlXP
int frame;
frame = xmlXPathSetFrame(ctxt);
-if (op-ch1 != -1)
+if (op-ch1 != -1) {
total +=
xmlXPathCompOpEval(ctxt, comp-steps[op-ch1]);
+CHECK_ERROR0;
+}
if (ctxt-valueNr op-value) {
xmlGenericError(xmlGenericErrorContext,
xmlXPathCompOpEval: parameter error\n);
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] xsl:key, key() [+current()]- LibXSLT disagrees with fellow processors [vol.2]
On 13/12/2013 00:53, Jan Pokorný wrote: first, there's a references recap I found for this topic: - original mail I've borrowed the subject from [1] - bugzilla.gnome.org bug [2] - thread on xsl-list ML [3], which may explain why Saxon behaves as it does (and hence differs from current behavior of libxslt in this aspect) This is a long-standing bug in libxslt. I just fixed it with commit ce5a0dd6: https://git.gnome.org/browse/libxslt/commit/?id=ce5a0dd6a70efdb214aba12fefc6bbf8c201b838 Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] xsl:key, key() [+current()]- LibXSLT disagrees with fellow processors [vol.2]
On 13/12/2013 16:04, Jan Pokorný wrote: Another think I've noticed is that currently the master has the problem with bug-182 in the test suite (which was the case also prior to this recent commit). Interestingly, my system-wide copy of xsltproc (libxslt-1.1.28-1.fc18.x86_64) does not produce a correct result either: ?xml version=1.0? bodyptext()[2]: text 1 /ppb[2]: b 2 /p/body I could not find any reference in Gnome Bugzilla, should I file a new bug for this? To make this test pass, you'll need a version of libxml2 from Git which includes this bug fix: https://git.gnome.org/browse/libxml2/commit/?id=b4bcba23f64b71105514875f165a63d4cc720609 This is a somewhat unfortunate situation. If it causes too much confusion, I'll back out this test case. Your system-wide copy of xsltproc fails because this issue was only recently fixed (only in Git). Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] str:split, str:tokenize and empty tokens
On 25/10/2012 15:34, Daniel Veillard wrote: On Tue, Oct 23, 2012 at 05:00:31PM +0200, Nick Wellnhofer wrote: This seems wrong to me, and I couldn't find anything in the EXSLT spec that mandates this behavior. Thoughts? Do other implementations do the same, if yes too bad, work around it, if no and EXSLT doesn't mandate that behaviour, feel free to fix :-) I tried to check Saxon and Xalan, but they don't seem to support str:split. But I had a look at the implementations in plain XSLT on the EXSLT website: http://www.exslt.org/str/functions/split/str.split.template.xsl http://www.exslt.org/str/functions/split/str.split.function.xsl They both remove empty tokens intentionally. So we should keep the current behavior. The fn:tokenize function in XPath 2.0 keeps empty tokens btw: http://www.w3.org/TR/xpath-functions/#func-tokenize Zero-length strings will also occur in the result sequence if a separator occurs at the end of the $input string, or if two adjacent substrings match the supplied $pattern. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] libxslt test run outside of srcdir (possible patch)
On 12/10/2012 11:18, Petr Sumbera wrote: Please see attached patch which tries to fix it. Well, some of these are not very nice but finally I have clean test run... :-) These changes look particularly ugly: @@ -217,6 +217,10 @@ cp err.$$name $$err ; \ fi ; \ else \ + grep '../docs/' $$out /dev/null \ + sed 's|/docs|/general|' result.$$name | \ + sed 's|$(srcdir)|../docs|' result.$$name.tmp \ + mv result.$$name.tmp result.$$name; \ diff $$out result.$$name; \ if [ -s $$err ] ; then \ diff $$err err.$$name; \ It might be better to first canonicalize the docs path: real_docs_path=`cd $(srcdir)/../docs pwd` And then replace $real_docs_path with ../docs in the result file. I'm not sure if this works, though. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] calling EXSLT function str:replace() without transform context raises memory error in 1.1.27
On 28/09/2012 15:33, Stefan Behnel wrote: Hi, a side effect of this commit: http://git.gnome.org/browse/libxslt/commit/?id=0602c535e9c34efca22dba1b1b7465e0618e7bfc is that the str:replace() function is no longer usable without a transform context. I take it from the bug report that it is not supposed to be used from plain XPath but only from XSLT according to the EXSLT specification. However, the previous implementation used to work in XPath and is still registered on an xmlXPathContext by the exsltStrXpathCtxtRegister() function. When called from plain XPath, it results in a memory error in line 526 (exsltStrReturnString()) of strings.c because xsltCreateRVT() returns NULL as an error indicator due to a NULL transform context being passed in, which was the return value from xsltXPathGetTransformContext() a bit further up (and the code doesn't validate that). I see two ways to deal with this. Either fix the error handling in exsltStrReturnString() and deliberately break backwards compatibility by removing the function from exsltStrXpathCtxtRegister(), or rewrite the new function in a way that makes it work in both contexts, i.e. from both XSLT and plain XPath. I have no idea if the latter is possible, but it would certainly be the friendlier solution. One of the problems of the old str:replace implementation was that it returned a string whereas it should return a node set. From what I understand, the nodes in the node set have to be added to a RVT, so they will be garbage collected later. I don't see a way to do that without a transform context. The str:tokenize and str:split function do the same thing btw, although it seems that they don't raise an error, but simply return an empty node set when used without a transform context. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Release candidate 1 of libxslt-1.1.27
On 07/09/2012 07:47, Daniel Richard G. wrote: * Updated tests/REC/test-7.1.1-3.out with current output to get rid of a spurious test failure This test fails because the tested feature (xsl:exclude-result-prefixes attribute) isn't implemented. I think it's better to disable the test completetly than to pretend the output is correct. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Release candidate 1 of libxslt-1.1.27
On 05/09/2012 15:59, Daniel Veillard wrote:
I tagged the git and pushed a tarball of the rc1 to:
ftp://xmlsoft.org/libxslt/
Please give it a try, I will probably commit some pending patches,
and then push a final release next week,
Here are my remaining patches rebased against master.
0001-Null-terminate-result-string-of-cry-rc4_decrypt
Fix for bug #675917
0002-Test-for-bug-680920
Another test case for bug #680920
0003-Add-new-tests-to-EXTRA_DIST
0004-Reserved-namespaces-in-xsl-element-and-xsl-attribute
Better version of my patch for bug #587360. Also fixes xsl:element.
0005-Fix-handling-of-names-in-xsl-attribute
Another patch to fix the handling of names in xsl:attribute if I
understand the spec correctly.
Nick
From a8e8fd6be707477f44aabafbc5ec5424894baaae Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Tue, 31 Jul 2012 21:27:51 +0200
Subject: [PATCH 1/5] Null-terminate result string of cry:rc4_decrypt
Bug #675917
---
libexslt/crypto.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libexslt/crypto.c b/libexslt/crypto.c
index e2700d6..42ac6c5 100644
--- a/libexslt/crypto.c
+++ b/libexslt/crypto.c
@@ -752,7 +752,7 @@ exsltCryptoRc4DecryptFunction (xmlXPathParserContextPtr
ctxt, int nargs) {
ret_len = exsltCryptoHex2Bin (str, str_len, bin, bin_len);
/* decrypt the binary blob */
-ret = xmlMallocAtomic (ret_len);
+ret = xmlMallocAtomic (ret_len + 1);
if (ret == NULL) {
xsltTransformError(tctxt, NULL, tctxt-inst,
exsltCryptoRc4EncryptFunction: Failed to allocate result\n);
@@ -761,6 +761,7 @@ exsltCryptoRc4DecryptFunction (xmlXPathParserContextPtr
ctxt, int nargs) {
goto done;
}
PLATFORM_RC4_DECRYPT (ctxt, padkey, bin, ret_len, ret, ret_len);
+ret[ret_len] = 0;
xmlXPathReturnString (ctxt, ret);
--
1.7.10.4
From dd79fd86d160446fbda262f4cb86b9ace75b3ba1 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Tue, 31 Jul 2012 23:32:05 +0200
Subject: [PATCH 2/5] Test for bug #680920
---
tests/docs/bug-178.xml|1 +
tests/general/Makefile.am |1 +
tests/general/bug-178.out |2 ++
tests/general/bug-178.xsl | 18 ++
4 files changed, 22 insertions(+)
create mode 100644 tests/docs/bug-178.xml
create mode 100644 tests/general/bug-178.out
create mode 100644 tests/general/bug-178.xsl
diff --git a/tests/docs/bug-178.xml b/tests/docs/bug-178.xml
new file mode 100644
index 000..69d62f2
--- /dev/null
+++ b/tests/docs/bug-178.xml
@@ -0,0 +1 @@
+doc/
diff --git a/tests/general/Makefile.am b/tests/general/Makefile.am
index f7fdea9..523183b 100644
--- a/tests/general/Makefile.am
+++ b/tests/general/Makefile.am
@@ -181,6 +181,7 @@ EXTRA_DIST = \
bug-171.out bug-171.xsl \
bug-172.out bug-172.xsl \
bug-173.out bug-173.xsl \
+bug-178.out bug-178.xsl \
character.out character.xsl \
character2.out character2.xsl \
itemschoose.out itemschoose.xsl \
diff --git a/tests/general/bug-178.out b/tests/general/bug-178.out
new file mode 100644
index 000..e829790
--- /dev/null
+++ b/tests/general/bug-178.out
@@ -0,0 +1,2 @@
+?xml version=1.0?
+result/
diff --git a/tests/general/bug-178.xsl b/tests/general/bug-178.xsl
new file mode 100644
index 000..aab57a4
--- /dev/null
+++ b/tests/general/bug-178.xsl
@@ -0,0 +1,18 @@
+xsl:stylesheet
+ xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+ xmlns:func = http://exslt.org/functions;
+ version=1.0 extension-element-prefixes=func
+
+func:function name=func:uaf
+ xsl:text/
+ func:result/
+/func:function
+
+xsl:template match=/
+result
+ xsl:value-of select=func:uaf()/
+/result
+/xsl:template
+
+/xsl:stylesheet
+
--
1.7.10.4
From 749a2afb5dc3bf66c2d3c5f7dc4fdef12b2dee46 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Wed, 15 Aug 2012 23:10:16 +0200
Subject: [PATCH 3/5] Add new tests to EXTRA_DIST
---
tests/general/Makefile.am |3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/general/Makefile.am b/tests/general/Makefile.am
index 523183b..c9b2036 100644
--- a/tests/general/Makefile.am
+++ b/tests/general/Makefile.am
@@ -181,6 +181,9 @@ EXTRA_DIST = \
bug-171.out bug-171.xsl \
bug-172.out bug-172.xsl \
bug-173.out bug-173.xsl \
+bug-174.out bug-174.xsl bug-174.err \
+bug-175.out bug-175.xsl bug-175.err \
+bug-176.out bug-176.xsl \
bug-178.out bug-178.xsl \
character.out character.xsl \
character2.out character2.xsl \
--
1.7.10.4
From eb79f0a35f082fe662854a37ecca8d8d7f52d231 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Wed, 15 Aug 2012 23:50:22 +0200
Subject: [PATCH 4/5] Reserved namespaces in xsl:element and xsl:attribute
Correct handling of 'xml' and 'xmlns' namespaces in xsl:element and
xsl:attribute. Fixes bug #587360.
---
libxslt/attributes.c | 14 -
libxslt
Re: [xslt] Rewrite of str:replace
On 09/08/2012 12:33, Daniel Veillard wrote:
On Wed, Aug 01, 2012 at 12:33:01AM +0200, Nick Wellnhofer wrote:
Daniel, if you like, I can send you all my changes as single patches.
Hi Nick,
let's apply the patches one by one in git preferably for clarity :-)
I'm not very good at pulling things from github, but if you send
a mail with all patches attached I can easilly process that :-)
Yes, I meant separate patches created with git-format-patch. I attached
all of my changes, rebased against master.
BTW I'm tempted to push a release beginning of september
along with the libxml2 update :) so if people have pending
patches now is a good thing (please also try to rebase patches to
libxslt GNOME git head if you made them against git :-)
After fixing bug #680920, Nicolas Gregoire came up with another crash
bug. I'll try to fix it before the release. See
https://bugzilla.gnome.org/show_bug.cgi?id=680920
Nick
From 67b97f2a178690e2fb29327d99cf270e2393cca5 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Tue, 31 Jul 2012 20:42:48 +0200
Subject: [PATCH 1/4] Fix bug #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.
---
libexslt/functions.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libexslt/functions.c b/libexslt/functions.c
index 13fd06e..0ea72be 100644
--- a/libexslt/functions.c
+++ b/libexslt/functions.c
@@ -489,6 +489,8 @@ exsltFuncFunctionComp (xsltStylesheetPtr style, xmlNodePtr
inst) {
}
xmlFree(prefix);
+xsltParseTemplateContent(style, inst);
+
/*
* Create function data
*/
@@ -500,8 +502,6 @@ exsltFuncFunctionComp (xsltStylesheetPtr style, xmlNodePtr
inst) {
func-nargs++;
}
-xsltParseTemplateContent(style, inst);
-
/*
* Register the function data such that it can be retrieved
* by exslFuncFunctionFunction
--
1.7.10.4
From f8ee319712081fdc0b9fba7d3687e32712bb2a94 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Tue, 31 Jul 2012 21:27:51 +0200
Subject: [PATCH 2/4] Null-terminate result string of cry:rc4_decrypt
Bug #675917
---
libexslt/crypto.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libexslt/crypto.c b/libexslt/crypto.c
index e2700d6..42ac6c5 100644
--- a/libexslt/crypto.c
+++ b/libexslt/crypto.c
@@ -752,7 +752,7 @@ exsltCryptoRc4DecryptFunction (xmlXPathParserContextPtr
ctxt, int nargs) {
ret_len = exsltCryptoHex2Bin (str, str_len, bin, bin_len);
/* decrypt the binary blob */
-ret = xmlMallocAtomic (ret_len);
+ret = xmlMallocAtomic (ret_len + 1);
if (ret == NULL) {
xsltTransformError(tctxt, NULL, tctxt-inst,
exsltCryptoRc4EncryptFunction: Failed to allocate result\n);
@@ -761,6 +761,7 @@ exsltCryptoRc4DecryptFunction (xmlXPathParserContextPtr
ctxt, int nargs) {
goto done;
}
PLATFORM_RC4_DECRYPT (ctxt, padkey, bin, ret_len, ret, ret_len);
+ret[ret_len] = 0;
xmlXPathReturnString (ctxt, ret);
--
1.7.10.4
From deffc00c76f509f3da44b72f51752103bb395ca5 Mon Sep 17 00:00:00 2001
From: Nick Wellnhofer wellnho...@aevum.de
Date: Tue, 31 Jul 2012 23:32:05 +0200
Subject: [PATCH 3/4] Test for bug #680920
---
tests/docs/bug-173.xml|1 +
tests/general/Makefile.am |1 +
tests/general/bug-173.out |2 ++
tests/general/bug-173.xsl | 18 ++
4 files changed, 22 insertions(+)
create mode 100644 tests/docs/bug-173.xml
create mode 100644 tests/general/bug-173.out
create mode 100644 tests/general/bug-173.xsl
diff --git a/tests/docs/bug-173.xml b/tests/docs/bug-173.xml
new file mode 100644
index 000..69d62f2
--- /dev/null
+++ b/tests/docs/bug-173.xml
@@ -0,0 +1 @@
+doc/
diff --git a/tests/general/Makefile.am b/tests/general/Makefile.am
index b6c738b..f7fdea9 100644
--- a/tests/general/Makefile.am
+++ b/tests/general/Makefile.am
@@ -180,6 +180,7 @@ EXTRA_DIST = \
bug-170.out bug-170.xsl \
bug-171.out bug-171.xsl \
bug-172.out bug-172.xsl \
+bug-173.out bug-173.xsl \
character.out character.xsl \
character2.out character2.xsl \
itemschoose.out itemschoose.xsl \
diff --git a/tests/general/bug-173.out b/tests/general/bug-173.out
new file mode 100644
index 000..e829790
--- /dev/null
+++ b/tests/general/bug-173.out
@@ -0,0 +1,2 @@
+?xml version=1.0?
+result/
diff --git a/tests/general/bug-173.xsl b/tests/general/bug-173.xsl
new file mode 100644
index 000..aab57a4
--- /dev/null
+++ b/tests/general/bug-173.xsl
@@ -0,0 +1,18 @@
+xsl:stylesheet
+ xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+ xmlns:func = http://exslt.org/functions;
+ version=1.0 extension-element-prefixes=func
+
+func:function name=func:uaf
+ xsl:text/
+ func:result/
+/func:function
+
+xsl:template match
Re: [xslt] An Invalid xpath expression xsl:template/@match node is ignored
On 31/07/2012 17:46, Nicolas Delaby wrote: Dear libxslt maintainers, I discover that performing a transformation with a invalid xpath expression in a template match attribute doesn't prevent the transformation to perform and lead to compromise the transformation logic. Instead, I would expect to have a proper failure like `could not compile match expression` The way I read it, this behavior doesn't violate the specification. Section 17 Conformance says: A conforming XSLT processor must signal any errors except for those that this document specifically allows an XSLT processor not to signal. A conforming XSLT processor may but need not recover from any errors that it signals. libxslt does signal the error and tries to recover by ignoring the template. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Upcoming release
I fixed two bugs reported by Nicolas Gregoire in this branch on Github: https://github.com/nwellnhof/libxslt/commits/misc_bugs Nick On 07/05/2012 08:15, Daniel Veillard wrote: Hello everybody, I'm way behind in making a release, but I will use most of this week to work on making the next libxml2 (and possibly libxslt) release(s). I will go over bugs in GNOME bugzilla and try to find patches lying there, if you have some and see no movement in the next couple of days, make sure they are provided as attachment and marked as patches. You can also send to the list if bugzilla is a problem, thanks, Daniel ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] An Invalid xpath expression xsl:template/@match node is ignored
On 31/07/2012 20:28, Nicolas Delaby wrote: Hi Nick, Thanks for your answer I see the point. But if I change a bit my stylesheet to put the invalid xpath expression in a xsl:apply-templates/@select , it does try to continue the transformation. [...] xsl:apply-templates select=sub_node1||sub_node2 / [...] $ xsltproc xpath-typo.xsl document.xml XPath error : Invalid expression sub_node1||sub_node2 ^ compilation error: file xpath-typo.xsl line 6 element apply-templates XSLT-apply-templates: could not compile select expression 'sub_node1||sub_node2' error: file xpath-typo.xsl line 10 element template xsltCompilePattern : NULL pattern Why it stops here ? I guess the compiler can not recover from this error, so it doesn't have other choice than stopping. But may be there is another explanation ? Yes, in this case the invalid expression is actually evaluated. IMHO, I do not like this strategy to recover from errors automatically. Apart from my personal opinion :), the only way to know if something goes wrong is to read stderr right ? Or is there is something more explicit ? I agree that it would be more user-friendly to abort the transformation if an invalid expression is encountered anywhere in the stylesheet. But this is more of a wishlist item than a real bug. Feel free to file a report on bugzilla.gnome.org. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
[xslt] Rewrite of str:replace
I just found an old patch of mine. It makes the str:replace extension function standard-conformant. See https://bugzilla.gnome.org/show_bug.cgi?id=569703. I committed it on top of my other fixes on Github. Daniel, if you like, I can send you all my changes as single patches. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Isn't it time to make libxslt multi-threaded?
On 26/07/2012 15:46, Дмитрий Грибов wrote: I've attached a perl script with core logic before, you must have missed it. Here, script is on the dropbox as well https://dl.dropbox.com/u/71178399/Threaded%20XSLT%20transformation.pl now. If I understand the nature of XSLT processing it is, on the core logic level, traversing over the source three. Nodes may be traversed intependently, thanks to XSLT static semi-vatiables. So you (in the pure spheric computer) just fork a new thread on each child, and parent only waits it's return. In fact you are not forking, but giving work to threads, but it does not change much. Yes, due to the functional nature of XSLT, xsl:for-each and xsl:apply-templates can be parallelized automatically. It would make for an interesting project, but I doubt you'll find someone who wants to implement this on top of libxslt. I think that most users of libxslt don't need lower latency for processing of a single stylesheet. You wrote that you process a huge and dedicated xml. Do you by chance load a large XML file with the document function? That's the only situation where I ran into performance problems in the past, because the parsed XML file won't be cached across transformations. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org https://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] string(node-set)
On 18/04/2012 17:18, Phil Shafer wrote: Short of a loop, what's the easiest way to turn a node set into a string of all the members of that node set? str:concat from the EXSLT strings module should do what you want: http://www.exslt.org/str/functions/concat/index.html Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Hi, how to limit the duration of an XSLT transformation ?
On 12/01/2011 11:03, Alexandre Bique wrote: I don't understand how to abort the transformation and if it can be safe? How do I cancel a running xsl transformation ? Is there public/private API like xsltAbortTransformation() ? How can I be sure that the current stack and all the context allocated memory will be freed ? I think the only safe way to do this is to start the XSLT transformation in an external process. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Compiling LibXSLT on Win32 using MinGW
On 06/09/2010 20:08, Michael Ludwig wrote: Passing the include directories as incdir instead of include to configure.js does not produce a working Makefile either, which isn't surprising: incdir is where to install the headers (by default in $prefix/include/). The documentation says so, but if you have a look at Makefile.mingw it's INCPREFIX that's added to CFLAGS. You could also try to edit the Makefile by hand after configuration and add your include path to one of the CFLAGS lines. Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Compiling LibXSLT on Win32 using MinGW
On 02/09/2010 01:25, Michael Ludwig wrote: Preliminary note: This is a sibling to another post of mine on the ActivePerl (Perl for Windows) mailing list, which is here: Compiling XML::LibXSLT and prereqs using MinGW http://code.activestate.com/lists/activeperl/21495/ I'm trying to compile LibXSLT on Win32 (XP Pro) using MinGW, but I'm going wrong somehow. I downloaded the latest sources (libxml2 2.7.7 and libxslt 1.1.26) from ftp://xmlsoft.org/libxslt/ and unpacked them to the following setup: C:\Opt\Src\libxslt - LibXSLT C:\Opt\Src\libxslt\win32- Win32 build env C:\Opt\Src\libxslt\win32\configure.js - configure script C:\Opt\Src\libxml2 - LibXML2 C:\Opt\Src\libxml2\include - added to INCLUDE C:\Opt\Src\libxml2\include\libxml\xmlversion.h - one included header This is what I'm doing: dmake clean dmake distclean configure.js compiler=mingw ^- using MinGW prefix=C:\Opt\Lib\LibXSLT ^ - target dir include=C:\Opt\Src\libxml2\include ^ - libxml2 headers lib=D:\ActivePerl512\site\lib\auto\XML\LibXML - LibXML.dll I have to edit the Makefile to adapt the subst makro for dmake. Not difficult. But then, the error that stops me: gcc.exe -DWIN32 -D_WINDOWS -D_MBCS -I.. -I..\libxslt -IC:\Opt\Lib\LibXSLT\include -D_DEBUG -g -DLIBXML_STATIC -DLIBXSLT_STATIC -DLIBEXSLT_STATIC -c -o int.xslt. mingw\attributes.o ..\libxslt\attributes.c In file included from ..\libxslt\libxslt.h:16, from ..\libxslt\attributes.c:13: ../config.h:92:31: libxml/xmlversion.h: No such file or directory Note the -IC:\Opt\Lib\LibXSLT\include flag. There's nothing there and I didn't instruct dmake to look there, at least not consciously. Instead, I told it to look in include=C:\Opt\Src\libxml2\include, but it doesn't do that. Is the build script configure.js broken or supposed to work? Just asking because the Makefile it generated didn't seem 100 % up to par. It is supposed to work at least with MSVC. Can you try to pass 'incdir' instead of 'include' to configure.js? Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Close brace in literal terminates expression in attribute value template
On 29/06/10 13:31, Nick Wellnhofer wrote:
I also can't confirm this bug with the latest version of libxslt. The
code in attrvt.c for precompiled attribute value templates handles
string literals correctly. But the code in templates.c that processes
AVTs directly doesn't:
$ cat avt-bug.xsl
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:template match=/
xsl:element name={substring('abc}', 1, 3)}/
/xsl:template
/xsl:stylesheet
$ xsltproc avt-bug.xsl avt-bug.xsl
XPath error : Unfinished literal
runtime error: file avt-bug.xsl line 4 element element
xsltAttrTemplateValueProcessNode: unmatched '}'
runtime error: file avt-bug.xsl line 4 element element
xsl:element: The effective name '', 1, 3)}' is not a valid QName.
no result for avt-bug.xsl
See the following patch for a fix:
http://github.com/nwellnhof/libxslt/commit/aba14c5280c265ae8f8e7f109354e0d16410fd8c.patch
Nick
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
[xslt] Git repository with patches
I put a git repository with my recent patches on github: http://github.com/nwellnhof/libxslt It contains two bug fixes that I already sent to the mailing list. Then two fixes for bugs 602515 and 602531, some small fixes to the locale code and some test cases. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Status of refactored code
On 03/12/09 00:28, Nick Wellnhofer wrote: exslt/functions/function.8 fails with the following error message: compilation error: file ./function.8.xsl line 22 element param Redefinition of variable or parameter 'in'. compilation error: file ./function.8.xsl line 30 element param Redefinition of variable or parameter 'in'. exslt/math/max.3 fails with a similar message This seems to be a problem in the refactored code wrt params of exslt functions. Parameters of a different functions with the same name are rejected as duplicate. With the attached patch all the exslt tests pass. diff --git a/libxslt/xslt.c b/libxslt/xslt.c index 55f505b..28c8c59 100644 --- a/libxslt/xslt.c +++ b/libxslt/xslt.c @@ -2432,13 +2432,13 @@ xsltCompilerNodePop(xsltCompilerCtxtPtr cctxt, xmlNodePtr node) xsltCompilerNodePop: Depth mismatch.\n); goto mismatch; } +cctxt-depth--; /* * Pop information of variables. */ if ((cctxt-ivar) (cctxt-ivar-depth cctxt-depth)) xsltCompilerVarInfoPop(cctxt); -cctxt-depth--; cctxt-inode = cctxt-inode-prev; if (cctxt-inode != NULL) cctxt-inode-curChildType = 0; ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Stack depth question...
On 03/12/09 04:04, Derick Winkworth wrote: I am also running this version, but the win32 version from http://www.zlatkovic.com/libxml.en.html hmm... Then your stack is probably overflowing. I think the default stack size on Windows is 1MB, on Linux it's 8MB. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
[xslt] Status of refactored code
I wonder what's the status of the refactored code in libxslt that can be enabled by defining XSLT_REFACTORED. It's been there for some years now and AFAICS it fixes some bugs that are hard to fix without the refactoring. I gave it a try about two years ago and I couldn't find any obvious problems. Nick ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
[xslt] [PATCH] Bug: xsltCompilePattern : failed to compile '@node()'
I have always used match=@* which works as expected.
But, being curious, I had a deeper look at xsltCompileStepPattern. The problem
is that @node(), attribute::node(), child::node() and node() are all
handled in different code paths and only the latter works.
Then, I noticed that the handling of match=child::name is wrong. It matches
the parents of name elements although it should be treated exactly like
match=name. So the whole XSLT_OP_CHILD stuff is unneeded.
I also found that xsltScanName behaves a bit strange with regard to ':'
characters. It doesn't parse an XML Name like the documentation says. It's
better to use xsltScanNCName instead.
Another minor issue is that the parser currently allows invalid expressions
like match=element* because of lines 1745-1747 in pattern.c in trunk.
Attached is a patch against trunk that fixes all these issues. It merges the
parsing of NodeTests in StepPatterns into a single code path keeping track of
the axis that has been specified previously. The patch also contains some test
cases.
Nick
--
aevum gmbh
rumfordstr. 4
80469 münchen
germany
tel: +49 89 3838 0653
http://aevum.de/
diff --git a/libxslt/pattern.c b/libxslt/pattern.c
index 815013b..d1064d6 100644
--- a/libxslt/pattern.c
+++ b/libxslt/pattern.c
@@ -46,7 +46,6 @@ typedef enum {
XSLT_OP_END=0,
XSLT_OP_ROOT,
XSLT_OP_ELEM,
-XSLT_OP_CHILD,
XSLT_OP_ATTR,
XSLT_OP_PARENT,
XSLT_OP_ANCESTOR,
@@ -61,6 +60,11 @@ typedef enum {
XSLT_OP_PREDICATE
} xsltOp;
+typedef enum {
+AXIS_CHILD=1,
+AXIS_ATTRIBUTE
+} xsltAxis;
+
typedef struct _xsltStepState xsltStepState;
typedef xsltStepState *xsltStepStatePtr;
struct _xsltStepState {
@@ -697,32 +701,6 @@ restart:
goto rollback;
}
continue;
-case XSLT_OP_CHILD: {
- xmlNodePtr lst;
-
- if ((node-type != XML_ELEMENT_NODE)
- (node-type != XML_DOCUMENT_NODE)
-#ifdef LIBXML_DOCB_ENABLED
- (node-type != XML_DOCB_DOCUMENT_NODE)
-#endif
- (node-type != XML_HTML_DOCUMENT_NODE))
- goto rollback;
-
- lst = node-children;
-
- if (step-value != NULL) {
- while (lst != NULL) {
- if ((lst-type == XML_ELEMENT_NODE)
- (step-value[0] == lst-name[0])
- (xmlStrEqual(step-value, lst-name)))
- break;
- lst = lst-next;
- }
- if (lst != NULL)
- continue;
- }
- goto rollback;
- }
case XSLT_OP_ATTR:
if (node-type != XML_ATTRIBUTE_NODE)
goto rollback;
@@ -1330,46 +1308,6 @@ xsltScanLiteral(xsltParserContextPtr ctxt) {
}
/**
- * xsltScanName:
- * @ctxt: the XPath Parser context
- *
- * [4] NameChar ::= Letter | Digit | '.' | '-' | '_' |
- * CombiningChar | Extender
- *
- * [5] Name ::= (Letter | '_' | ':') (NameChar)*
- *
- * [6] Names ::= Name (S Name)*
- *
- * Returns the Name parsed or NULL
- */
-
-static xmlChar *
-xsltScanName(xsltParserContextPtr ctxt) {
-const xmlChar *q, *cur;
-xmlChar *ret = NULL;
-int val, len;
-
-SKIP_BLANKS;
-
-cur = q = CUR_PTR;
-val = xmlStringCurrentChar(NULL, cur, len);
-if (!IS_LETTER(val) (val != '_') (val != ':'))
- return(NULL);
-
-while ((IS_LETTER(val)) || (IS_DIGIT(val)) ||
- (val == '.') || (val == '-') ||
- (val == '_') ||
- (IS_COMBINING(val)) ||
- (IS_EXTENDER(val))) {
- cur += len;
- val = xmlStringCurrentChar(NULL, cur, len);
-}
-ret = xmlStrndup(q, cur - q);
-CUR_PTR = cur;
-return(ret);
-}
-
-/**
* xsltScanNCName:
* @ctxt: the XPath Parser context
*
@@ -1404,30 +1342,6 @@ xsltScanNCName(xsltParserContextPtr ctxt) {
return(ret);
}
-/**
- * xsltScanQName:
- * @ctxt: the XPath Parser context
- * @prefix: the place to store the prefix
- *
- * Parse a qualified name
- *
- * Returns the Name parsed or NULL
- */
-
-static xmlChar *
-xsltScanQName(xsltParserContextPtr ctxt, xmlChar **prefix) {
-xmlChar *ret = NULL;
-
-*prefix = NULL;
-ret = xsltScanNCName(ctxt);
-if (CUR == ':') {
-*prefix = ret;
- NEXT;
- ret = xsltScanNCName(ctxt);
-}
-return(ret);
-}
-
/*
* xsltCompileIdKeyPattern:
* @ctxt: the compilation context
@@ -1447,7 +1361,7 @@ xsltScanQName(xsltParserContextPtr ctxt, xmlChar
**prefix) {
*/
static void
xsltCompileIdKeyPattern(xsltParserContextPtr ctxt, xmlChar *name,
- int aid, int novar) {
+ int aid, int novar, xsltAxis axis) {
xmlChar *lit = NULL;
xmlChar *lit2 = NULL;
@@ -1458,6 +1372,12 @@ xsltCompileIdKeyPattern(xsltParserContextPtr ctxt,
xmlChar *name,
return;
Re: [xslt] filenames containing spaces in xslt param
Viktor Štujber wrote: xsl:variable name=path select='file%20with%20space%20in%20name.xml' / xsl:copy-of select=document($path)/ Works... however, I thought string literals could contain spaces... why do spaces have to be escaped this way? I'm curious to know. Because the argument of the document function is a URI, not a filename. Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
[xslt] Git repo with my recent patches
I have some patches for libxslt that haven't been merged yet. - xsl:strip-space with namespace and wildcard http://mail.gnome.org/archives/xslt/2008-November/msg00023.html - Imported encoding not set on result document http://mail.gnome.org/archives/xslt/2008-November/msg00025.html - Sort items according to @lang xsl:sort attribute in Esperanto http://bugzilla.gnome.org/show_bug.cgi?id=573327 I put the fixes and test cases in a git repository at http://aevum.de/git/libxslt.git You should be able to pull them with $ git pull http://aevum.de/git/libxslt.git master Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Splitting a result into subtrees
I don't know about the PHP API. But with the Perl API this would be
really easy and doesn't even require XSLT. Assuming you have a parsed
HTML document in $doc, the code would look something like:
my $part1 = $doc-findnodes('xpath_for_subtree_1')-get_node(1)-toString();
my $part2 = $doc-findnodes('xpath_for_subtree_2')-get_node(1)-toString();
...
The PHP API should provide similar functions.
HTH,
Nick
Michael Ludwig wrote:
I have a PHP/XSLT web application. It currently emits whole HTML pages.
In order to plug it into the Drupal CMS, I need to get hold of about
five subtrees of this HTML and then pass those on to Drupal as strings.
What is the best way to achieve this?
Newer versions of Saxon allow the user to pass an initial mode or
initial template as a parameter to the transformation. I don't think
this is possible with LibXSLT, but maybe it helps to illustrate what I'd
like to achieve.
I'm currently thinking one way to achieve what I want is to create
new DOMDocument objects to receive subtrees using a recursive call to
importNode(), and then to serialize those new documents.
Can you think of a better way?
Michael Ludwig
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
--
aevum gmbh
rumfordstr. 4
80469 münchen
germany
tel: +49 89 3838 0653
http://aevum.de/
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Splitting a result into subtrees
I see, only the standard DOM functions are available. Then it's a bit
more complicated. Something like that:
$xpath = new DOMXpath($doc);
$node = $xpath-query(xpath_for_subtree_1)-item(0);
$subtree = new DOMDocument();
$subtree-appendChild($node-clone(TRUE));
$part1 = $subtree-saveXML();
But that's basic DOM manipulation and doesn't really belong on this list.
Nick
Michael Ludwig wrote:
Nick Wellnhofer schrieb:
[...] Perl API [...]
my $part1 =
$doc-findnodes('xpath_for_subtree_1')-get_node(1)-toString();
my $part2 =
$doc-findnodes('xpath_for_subtree_2')-get_node(1)-toString();
...
The PHP API should provide similar functions.
Unfortunately, it doesn't. I guess I'd have
to use DOMDocument::getElementsByTagName or
DOMDocument::getElementsByTagNameNS.
http://de.php.net/manual/en/book.dom.php
Michael Ludwig
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
--
aevum gmbh
rumfordstr. 4
80469 münchen
germany
tel: +49 89 3838 0653
http://aevum.de/
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] [PATCH] Imported encoding not set on result document
Roumen Petrov wrote:
What about to add a test case that show that issue is resolved ?
Here is a new patch including a test case. Note that the test only
covers the one symptom of the bug that I noticed.
Nick
--
aevum gmbh
rumfordstr. 4
80469 münchen
germany
tel: +49 89 3838 0653
http://aevum.de/
Index: libxslt/transform.c
===
--- libxslt/transform.c (revision 1493)
+++ libxslt/transform.c (working copy)
@@ -3217,6 +3217,7 @@
const xmlChar *doctypePublic;
const xmlChar *doctypeSystem;
const xmlChar *version;
+const xmlChar *encoding;
if ((ctxt == NULL) || (node == NULL) || (inst == NULL) || (comp == NULL))
return;
@@ -3506,6 +3507,7 @@
XSLT_GET_IMPORT_PTR(doctypePublic, style, doctypePublic)
XSLT_GET_IMPORT_PTR(doctypeSystem, style, doctypeSystem)
XSLT_GET_IMPORT_PTR(version, style, version)
+XSLT_GET_IMPORT_PTR(encoding, style, encoding)
if ((method != NULL)
(!xmlStrEqual(method, (const xmlChar *) xml))) {
@@ -3565,8 +3567,8 @@
#endif
}
res-charset = XML_CHAR_ENCODING_UTF8;
-if (style-encoding != NULL)
- res-encoding = xmlStrdup(style-encoding);
+if (encoding != NULL)
+ res-encoding = xmlStrdup(encoding);
ctxt-output = res;
ctxt-insert = (xmlNodePtr) res;
xsltApplySequenceConstructor(ctxt, node, inst-children, NULL);
@@ -5833,6 +5835,7 @@
const xmlChar *doctypePublic;
const xmlChar *doctypeSystem;
const xmlChar *version;
+const xmlChar *encoding;
xsltStackElemPtr variables;
xsltStackElemPtr vptr;
@@ -5904,6 +5907,7 @@
XSLT_GET_IMPORT_PTR(doctypePublic, style, doctypePublic)
XSLT_GET_IMPORT_PTR(doctypeSystem, style, doctypeSystem)
XSLT_GET_IMPORT_PTR(version, style, version)
+XSLT_GET_IMPORT_PTR(encoding, style, encoding)
if ((method != NULL)
(!xmlStrEqual(method, (const xmlChar *) xml)))
@@ -5992,8 +5996,8 @@
#endif
}
res-charset = XML_CHAR_ENCODING_UTF8;
-if (style-encoding != NULL)
-res-encoding = xmlStrdup(style-encoding);
+if (encoding != NULL)
+res-encoding = xmlStrdup(encoding);
variables = style-variables;
/*
Index: tests/docs/Makefile.am
===
--- tests/docs/Makefile.am (revision 1493)
+++ tests/docs/Makefile.am (working copy)
@@ -167,6 +167,7 @@
bug-166.xml \
bug-167.xml \
bug-168.xml \
+ bug-169.xml \
character.xml \
array.xml \
items.xml
Index: tests/docs/bug-169.xml
===
--- tests/docs/bug-169.xml (revision 0)
+++ tests/docs/bug-169.xml (revision 0)
@@ -0,0 +1 @@
+doc/
Index: tests/general/bug-169.imp
===
--- tests/general/bug-169.imp (revision 0)
+++ tests/general/bug-169.imp (revision 0)
@@ -0,0 +1,5 @@
+xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
+
+xsl:output encoding=iso-8859-1/
+
+/xsl:stylesheet
Index: tests/general/Makefile.am
===
--- tests/general/Makefile.am (revision 1493)
+++ tests/general/Makefile.am (working copy)
@@ -176,6 +176,7 @@
bug-166.out bug-166.xsl \
bug-167.out bug-167.xsl \
bug-168.out bug-168.xsl \
+bug-169.out bug-169.xsl bug-169.imp \
character.out character.xsl \
character2.out character2.xsl \
itemschoose.out itemschoose.xsl \
Index: tests/general/bug-169.xsl
===
--- tests/general/bug-169.xsl (revision 0)
+++ tests/general/bug-169.xsl (revision 0)
@@ -0,0 +1,11 @@
+?xml version=1.0 encoding=iso-8859-1?
+
+xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
+
+xsl:import href=bug-169.imp/
+
+xsl:template match=/
+result attr=Fahrvergnügen/
+/xsl:template
+
+/xsl:stylesheet
Index: tests/general/bug-169.out
===
--- tests/general/bug-169.out (revision 0)
+++ tests/general/bug-169.out (revision 0)
@@ -0,0 +1,2 @@
+?xml version=1.0 encoding=iso-8859-1?
+result attr=Fahrvergnügen/
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XML_DOCUMENT_NODE and boolean testing
Is it possible that this is not a bug and the current behavior is
correct? The spec says here:
http://www.w3.org/TR/xslt#section-Result-Tree-Fragments
A result tree fragment is treated equivalently to a node-set that
contains just a single root node.
So a RTF is always a non-empty node-set and should evaluate to true.
Nick
Phil Shafer wrote:
Daniel Veillard writes:
maybe it's a bug, yes.
This seems to fix it:
Index: libxml2/xpath.c
===
RCS file: /cvs/junos-2001/src/contrib/libxml2/xpath.c,v
retrieving revision 1.8
diff -u -p -r1.8 xpath.c
--- libxml2/xpath.c 3 Apr 2008 21:26:20 - 1.8
+++ libxml2/xpath.c 11 Jul 2008 13:33:51 -
@@ -5940,6 +5940,16 @@ int
xmlXPathCastNodeSetToBoolean (xmlNodeSetPtr ns) {
if ((ns == NULL) || (ns-nodeNr == 0))
return(0);
+/*
+ * If the only contents of the node-set are an
+ * XML_DOCUMENT_NODE, then we have a fake document
+ * returned by a template. If it's empty, the
+ * boolean value should be false.
+ */
+if ((ns-nodeNr == 1)
+(ns-nodeTab[0]-type == XML_DOCUMENT_NODE)
+(ns-nodeTab[0]-children == NULL))
+ return(0);
return(1);
}
I'll open a bug report with this patch.
Thanks,
Phil
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
--
aevum gmbh
rumfordstr. 4
80469 münchen
germany
tel: +49 89 3838 0653
http://aevum.de/
___
xslt mailing list, project page http://xmlsoft.org/XSLT/
xslt@gnome.org
http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XML_DOCUMENT_NODE and boolean testing
Phil Shafer wrote: Nick Wellnhofer writes: http://www.w3.org/TR/xslt#section-Result-Tree-Fragments A result tree fragment is treated equivalently to a node-set that contains just a single root node. This root node persists even after using ext:node-set(). Is that correct behavior? So a RTF is always a non-empty node-set and should evaluate to true. So my script should be saying 'test=$f/*' or 'count($f/*) 0'? No, I can't inspect an RTF, so I'd have to convert it to a node-set first and then test it. The node-set returned by exsl:node-set() always has that root node, so the test should be 'exsl:node-set($f)/*'. See here: http://www.google.com/search?q=exslt+node-set+%22root+node%22 It is certainly more convenient to test the variable directly, but if that's not what the spec says, I'll close the bug and use the above tests instead. You might try some other XSLT processors and see what they do. It seems that the XSLT Programmer's Reference says on this topic: http://www.cygwin.com/ml/xsl-list/2000-08/msg01106.html The result tree fragment is first converted to a string, and the string is then converted to a Boolean. The resulting boolean is true if the result tree fragment contains any non-empty text nodes, and is false otherwise. But I think that contradicts the spec and libxslt is correct. The spec clearly says: http://www.w3.org/TR/xslt#section-Result-Tree-Fragments When a permitted operation is performed on a result tree fragment, it is performed exactly as it would be on the equivalent node-set. So it shouldn't be converted to a string first. Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] XML_DOCUMENT_NODE and boolean testing
Nick Wellnhofer wrote: Phil Shafer wrote: Nick Wellnhofer writes: http://www.w3.org/TR/xslt#section-Result-Tree-Fragments A result tree fragment is treated equivalently to a node-set that contains just a single root node. This root node persists even after using ext:node-set(). Is that correct behavior? So a RTF is always a non-empty node-set and should evaluate to true. So my script should be saying 'test=$f/*' or 'count($f/*) 0'? No, I can't inspect an RTF, so I'd have to convert it to a node-set first and then test it. The node-set returned by exsl:node-set() always has that root node, so the test should be 'exsl:node-set($f)/*'. See here: http://www.google.com/search?q=exslt+node-set+%22root+node%22 It is certainly more convenient to test the variable directly, but if that's not what the spec says, I'll close the bug and use the above tests instead. You might try some other XSLT processors and see what they do. It seems that the XSLT Programmer's Reference says on this topic: http://www.cygwin.com/ml/xsl-list/2000-08/msg01106.html The result tree fragment is first converted to a string, and the string is then converted to a Boolean. The resulting boolean is true if the result tree fragment contains any non-empty text nodes, and is false otherwise. But I think that contradicts the spec and libxslt is correct. The spec clearly says: http://www.w3.org/TR/xslt#section-Result-Tree-Fragments When a permitted operation is performed on a result tree fragment, it is performed exactly as it would be on the equivalent node-set. So it shouldn't be converted to a string first. Nick See also here: http://mail-archives.apache.org/mod_mbox/xml-xalan-dev/29.mbox/[EMAIL PROTECTED] http://www.google.com/search?q=xslt+%22result+tree+fragment%22+boolean Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Patch for xsl:sort lang support
Daniel Veillard wrote: On Thu, May 15, 2008 at 02:46:17PM +0200, Nick Wellnhofer wrote: Okay, thanks ! I finally took the time to apply your patch (no I hadn't forgotten :-) it's now in SVN ! Just one thing, it would be nice to add a couple of simple example to test taht this is working correctly in the regression tests, if you have some that would be a good addition. Yes, I had a test case in the first patch I sent. But you need to have the required locales installed with locale-gen on some systems, otherwise the tests won't work. I don't know if this is a problem. Another thing I'm not sure about is the configure check. Maybe it would be better to use AC_TRY_COMPILE instead of AC_TRY_RUN here? Nick -- aevum gmbh rumfordstr. 4 80469 münchen germany tel: +49 89 3838 0653 http://aevum.de/ ___ xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt@gnome.org http://mail.gnome.org/mailman/listinfo/xslt
Re: [xslt] Patch for xsl:sort lang support
\
templates.c \
diff -purN -x Makefile.in -x '*.m4' -x 'config.h.in*' -x configure -x
'*config.h' -x '*.spec' -x NEWS -x namespaces.c -x transform.c -x tests
libxslt-1.1.24/libxslt/preproc.c libxslt-1.1.24-nik1/libxslt/preproc.c
--- libxslt-1.1.24/libxslt/preproc.c2007-01-03 16:11:57.0 +0100
+++ libxslt-1.1.24-nik1/libxslt/preproc.c 2008-05-15 13:18:55.0
+0200
@@ -391,6 +391,8 @@ xsltFreeStylePreComp(xsltStylePreCompPtr
break;
case XSLT_FUNC_SORT: {
xsltStyleItemSortPtr item = (xsltStyleItemSortPtr) comp;
+ if (item-locale != NULL)
+ xsltFreeLocale(item-locale);
if (item-comp != NULL)
xmlXPathFreeCompExpr(item-comp);
}
@@ -487,6 +489,8 @@ xsltFreeStylePreComp(xsltStylePreCompPtr
break;
}
#else
+if (comp-locale != NULL)
+ xsltFreeLocale(comp-locale);
if (comp-comp != NULL)
xmlXPathFreeCompExpr(comp-comp);
if (comp-nsList != NULL)
@@ -728,6 +732,12 @@ xsltSortComp(xsltStylesheetPtr style, xm
comp-lang = xsltEvalStaticAttrValueTemplate(style, inst,
(const xmlChar *)lang,
NULL, comp-has_lang);
+if (comp-lang != NULL) {
+ comp-locale = xsltNewLocale(comp-lang);
+}
+else {
+comp-locale = NULL;
+}
comp-select = xsltGetCNsProp(style, inst,(const xmlChar *)select,
XSLT_NAMESPACE);
if (comp-select == NULL) {
diff -purN -x Makefile.in -x '*.m4' -x 'config.h.in*' -x configure -x
'*config.h' -x '*.spec' -x NEWS -x namespaces.c -x transform.c -x tests
libxslt-1.1.24/libxslt/xsltInternals.h
libxslt-1.1.24-nik1/libxslt/xsltInternals.h
--- libxslt-1.1.24/libxslt/xsltInternals.h 2008-05-13 17:37:33.0
+0200
+++ libxslt-1.1.24-nik1/libxslt/xsltInternals.h 2008-05-15 13:18:55.0
+0200
@@ -21,6 +21,7 @@
#include libxml/xmlstring.h
#include libxslt/xslt.h
#include xsltexports.h
+#include xsltlocale.h
#include numbersInternals.h
#ifdef __cplusplus
@@ -1045,6 +1046,7 @@ struct _xsltStyleItemSort {
int descending; /* sort */
const xmlChar *lang; /* sort */
int has_lang; /* sort */
+xsltLocale locale; /* sort */
const xmlChar *case_order; /* sort */
int lower_first; /* sort */
@@ -1381,6 +1383,7 @@ struct _xsltStylePreComp {
int descending; /* sort */
const xmlChar *lang; /* sort */
int has_lang; /* sort */
+xsltLocale locale; /* sort */
const xmlChar *case_order; /* sort */
int lower_first; /* sort */
diff -purN -x Makefile.in -x '*.m4' -x 'config.h.in*' -x configure -x
'*config.h' -x '*.spec' -x NEWS -x namespaces.c -x transform.c -x tests
libxslt-1.1.24/libxslt/xsltlocale.c libxslt-1.1.24-nik1/libxslt/xsltlocale.c
--- libxslt-1.1.24/libxslt/xsltlocale.c 1970-01-01 01:00:00.0 +0100
+++ libxslt-1.1.24-nik1/libxslt/xsltlocale.c2008-05-15 13:18:55.0
+0200
@@ -0,0 +1,453 @@
+/*
+ * xsltlocale.c: locale handling
+ *
+ * Reference:
+ * RFC 3066: Tags for the Identification of Languages
+ * http://www.ietf.org/rfc/rfc3066.txt
+ * ISO 639-1, ISO 3166-1
+ *
+ * Author: Nick Wellnhofer
+ */
+
+#define IN_LIBXSLT
+#include libxslt.h
+
+#include string.h
+#include libxml/xmlmemory.h
+
+#include xsltlocale.h
+#include xsltutils.h
+
+#if defined(__GLIBC__) __GLIBC__ == 2 __GLIBC_MINOR__ = 2
+#define newlocale __newlocale
+#define freelocale __freelocale
+#define strxfrm_l __strxfrm_l
+#define LC_COLLATE_MASK (1 LC_COLLATE)
+#endif
+
+#define ISALPHA(c) ((c 0xc0) == 0x40 (unsigned)((c 0x1f) - 1) 26)
+#define TOUPPER(c) (c ~0x20)
+#define TOLOWER(c) (c | 0x20)
+
+/**
+ * xsltNewLocale:
+ * @languageTag: RFC 3066 language tag
+ *
+ * Creates a new locale of an opaque system dependent type based on the
+ * language tag. Three-letter language codes (ISO 639-2 Alpha-3) are not
+ * supported.
+ *
+ * Returns the locale or NULL on error or if no matching locale was found
+ */
+xsltLocale
+xsltNewLocale(const xmlChar *languageTag) {
+#ifdef XSLT_LOCALE_XLOCALE
+xsltLocale locale;
+char localeName[23]; /* 8*lang + - + 8*region + .utf8\0 */
+const xmlChar *p = languageTag;
+const char *region = NULL;
+char *q = localeName;
+int c, i, llen;
+
+/* Convert something like pt-br to pt_BR.utf8 */
+
+if (languageTag == NULL)
+ return(NULL);
+
+for (i=0; i8 ISALPHA(*p); ++i)
+ *q++ = TOLOWER(*p++);
+
+if (i == 0)
+ return(NULL);
+
+llen = i;
+*q++ = '_';
+
+if (*p) {
+ if (*p++ != '-')
+ return(NULL);
+
+ for (i=0; i8 ISALPHA(*p); ++i)
+ *q++ = TOUPPER(*p++);
+
+ if (i == 0 || *p)
+ return(NULL);
+
+memcpy(q, .utf8, 6);
+locale = newlocale(LC_COLLATE_MASK
[xslt] Patch for xsl:sort lang support
Makefile.in --exclude '*.m4' --exclude 'config.h.in*'
--exclude configure --exclude '*config.h' --exclude '*.spec' --exclude NEWS
libxslt-1.1.23/libxslt/preproc.c libxslt-1.1.23-nik2/libxslt/preproc.c
--- libxslt-1.1.23/libxslt/preproc.c2007-01-03 16:11:57.0 +0100
+++ libxslt-1.1.23-nik2/libxslt/preproc.c 2008-05-14 17:47:43.0
+0200
@@ -391,6 +391,8 @@ xsltFreeStylePreComp(xsltStylePreCompPtr
break;
case XSLT_FUNC_SORT: {
xsltStyleItemSortPtr item = (xsltStyleItemSortPtr) comp;
+ if (item-locale != NULL)
+ xsltFreeLocale(item-locale);
if (item-comp != NULL)
xmlXPathFreeCompExpr(item-comp);
}
@@ -487,6 +489,8 @@ xsltFreeStylePreComp(xsltStylePreCompPtr
break;
}
#else
+if (comp-locale != NULL)
+ xsltFreeLocale(comp-locale);
if (comp-comp != NULL)
xmlXPathFreeCompExpr(comp-comp);
if (comp-nsList != NULL)
@@ -728,6 +732,12 @@ xsltSortComp(xsltStylesheetPtr style, xm
comp-lang = xsltEvalStaticAttrValueTemplate(style, inst,
(const xmlChar *)lang,
NULL, comp-has_lang);
+if (comp-lang != NULL) {
+ comp-locale = xsltNewLocale(comp-lang);
+}
+else {
+comp-locale = NULL;
+}
comp-select = xsltGetCNsProp(style, inst,(const xmlChar *)select,
XSLT_NAMESPACE);
if (comp-select == NULL) {
diff -purN --exclude Makefile.in --exclude '*.m4' --exclude 'config.h.in*'
--exclude configure --exclude '*config.h' --exclude '*.spec' --exclude NEWS
libxslt-1.1.23/libxslt/transform.c libxslt-1.1.23-nik2/libxslt/transform.c
--- libxslt-1.1.23/libxslt/transform.c 2007-06-17 22:45:22.0 +0200
+++ libxslt-1.1.23-nik2/libxslt/transform.c 2008-05-14 17:47:43.0
+0200
@@ -1542,7 +1542,7 @@ xsltCopyTreeInternal(xsltTransformContex
* Search by namespace name.
* REVISIT TODO: Currently disabled.
*/
-#if 0
+#if 1
ns = xmlSearchNsByHref(insert-doc,
insert, (*curns)-href);
#endif
diff -purN --exclude Makefile.in --exclude '*.m4' --exclude 'config.h.in*'
--exclude configure --exclude '*config.h' --exclude '*.spec' --exclude NEWS
libxslt-1.1.23/libxslt/xsltInternals.h
libxslt-1.1.23-nik2/libxslt/xsltInternals.h
--- libxslt-1.1.23/libxslt/xsltInternals.h 2008-01-24 16:23:15.0
+0100
+++ libxslt-1.1.23-nik2/libxslt/xsltInternals.h 2008-05-14 17:47:43.0
+0200
@@ -21,6 +21,7 @@
#include libxml/xmlstring.h
#include libxslt/xslt.h
#include xsltexports.h
+#include xsltlocale.h
#include numbersInternals.h
#ifdef __cplusplus
@@ -1044,6 +1045,7 @@ struct _xsltStyleItemSort {
int descending; /* sort */
const xmlChar *lang; /* sort */
int has_lang; /* sort */
+xsltLocale locale; /* sort */
const xmlChar *case_order; /* sort */
int lower_first; /* sort */
@@ -1380,6 +1382,7 @@ struct _xsltStylePreComp {
int descending; /* sort */
const xmlChar *lang; /* sort */
int has_lang; /* sort */
+xsltLocale locale; /* sort */
const xmlChar *case_order; /* sort */
int lower_first; /* sort */
diff -purN --exclude Makefile.in --exclude '*.m4' --exclude 'config.h.in*'
--exclude configure --exclude '*config.h' --exclude '*.spec' --exclude NEWS
libxslt-1.1.23/libxslt/xsltlocale.c libxslt-1.1.23-nik2/libxslt/xsltlocale.c
--- libxslt-1.1.23/libxslt/xsltlocale.c 1970-01-01 01:00:00.0 +0100
+++ libxslt-1.1.23-nik2/libxslt/xsltlocale.c2008-05-14 18:08:15.0
+0200
@@ -0,0 +1,450 @@
+/*
+ * xsltlocale.c: locale handling
+ *
+ * Reference:
+ * RFC 3066: Tags for the Identification of Languages
+ * http://www.ietf.org/rfc/rfc3066.txt
+ * ISO 639-1, ISO 3166-1
+ *
+ * Author: Nick Wellnhofer
+ */
+
+#define IN_LIBXSLT
+#include libxslt.h
+
+#include ctype.h
+#include string.h
+#include libxml/xmlmemory.h
+
+#include xsltlocale.h
+#include xsltutils.h
+
+#if defined(__GLIBC__) __GLIBC__ == 2 __GLIBC_MINOR__ = 2
+#define newlocale __newlocale
+#define freelocale __freelocale
+#define strxfrm_l __strxfrm_l
+#define LC_COLLATE_MASK (1 LC_COLLATE)
+#endif
+
+/**
+ * xsltNewLocale:
+ * @languageTag: RFC 3066 language tag
+ *
+ * Creates a new locale of an opaque system dependent type based on the
+ * language tag. Three-letter language codes (ISO 639-2 Alpha-3) are not
+ * supported.
+ *
+ * Returns the locale or NULL on error or if no matching locale was found
+ */
+xsltLocale
+xsltNewLocale(const xmlChar *languageTag) {
+#ifdef XSLT_LOCALE_XLOCALE
+xsltLocale locale;
+char localeName[23]; /* 8*lang + - + 8*region + .utf8\0 */
+const xmlChar *p = languageTag;
+const char *region = NULL;
+char *q
