After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 519926 - please implement a systemId function
please implement a systemId function
Status: RESOLVED FIXED
Product: libxslt
Classification: Platform
Component: general
1.1.22
Other All
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-02 16:12 UTC by Mike Hommey
Modified: 2012-09-12 03:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch adding the systemId function (1021 bytes, patch)
2008-03-02 16:13 UTC, Mike Hommey
none Details | Review

Description Mike Hommey 2008-03-02 16:12:00 UTC
(This was reported as debian bug #448205 by brian m. carlson)

Both Xalan and Saxon have a systemId function (in their respective 
namespaces) to provide the URI of the file that is being transformed.  
It would be nice to have that function in libxslt1.1 as well, because 
then DocBook could use it[0].

I would normally provide a patch, but I briefly looked at the code, and 
it seems non-trivial to fix without breaking the ABI. But I suppose 
you're more familiar with libxml2 and libxslt1.1 than I.

[0] See line 250 et seq in 
/usr/share/xml/docbook/stylesheet/nwalsh/common/stripns.xsl
Comment 1 Mike Hommey 2008-03-02 16:13:44 UTC
Created attachment 106401 [details] [review]
patch adding the systemId function

(Patch created by brian m. carlson, with the following message)

I created a patch to implement the saxon:systemId function.  It has been 
tested and works with the DocBook stylesheets.  The patch is attached 
and should be applied to saxon.c in the libexslt directory.
Comment 2 Daniel Veillard 2008-03-03 08:54:20 UTC
Looks relatively sane, except some NULL pointer testing is in
order. I also wonder what Xalan/Saxon returns when run within
a Result Tree Fragment ... also IMHO it should check for the 
base, for example if you use Xinclude to create your input 
(and Xinclude + DocBook = libxslt is a really common use case).

This can probably be applied after checks of NULLs, but I'm afraid
like any hasty extra add-on it usually breaks in many corner cases.

Daniel 
Comment 3 Daniel Veillard 2012-09-12 03:10:23 UTC
Okay I had to dig in the Saxon doc to find out that it should not return
the base. So i just fixed to take care of the NULL. I have no idea
how Saxon translates a NULL String returned as the java layer to
the XSLT layer, as XSLT has no notion of NULL string, so I just
returned the empty string in those case. I commited the following:

  http://git.gnome.org/browse/libxslt/commit/?id=92bc8136311ed86d85f764cbfc82da77d90c0e29

  thanks !

Daniel