Bug #1503

Attribute in xlink namespace not recognized (Firefox)

Added by Manfred Staudinger over 8 years ago. Updated almost 8 years ago.

Start date:
Due date:
% Done:


Estimated time:


The following expression

svg-t5-011.xhtml (3.02 KB) svg-t5-011.xhtml Manfred Staudinger, 2012-04-26 23:15
svg-t5-011.svg (761 Bytes) svg-t5-011.svg Manfred Staudinger, 2012-04-26 23:15
svg-t5-browser-v2.xsl (855 Bytes) svg-t5-browser-v2.xsl Manfred Staudinger, 2012-04-26 23:15
console.txt (3.81 KB) console.txt Manfred Staudinger, 2012-04-30 22:47


#1 Updated by Philip Fearon over 8 years ago

Thanks for reporting this - beta 0.1 has a number of namespace issues on the HTML side (see #1455), but this was thought to be less marked with XHTML. I'll check out your test-case on our latest Saxon-CE build (where namespace handling has been re-worked) when I get into the office.

#2 Updated by Manfred Staudinger over 8 years ago

Not sure anymore the problem is namespace or use element related (it was a bit late when I wrote the issue). When you add

	<xsl:result-document href="#clip-path" method="ixsl:append-content" xmlns="">
		<use xlink:href="#_1474"/>

#3 Updated by Philip Fearon over 8 years ago

First, I'll address the namespace problem - because it was definitely an issue in beta 0.1 in certain use cases (though perhaps it's just a contributory factor here):

With the beta 0.2 (pre-release) I get this result in the log - this is, both xsl:message outputs are true:

For info, to achieve this in beta 0.2 I had to: 1) add the namespace declaration for xhtml 2) add the xpath-default-namespace attribute for xhtml and 3) add svg: prefixes for svg name-tests in the XPath. (These extra namespace declarations are what you would expect for a namespace-aware browser, but weren't necessary in beta 0.1). So, the final XSLT looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="2.0"
<xsl:variable name="svg" select="ixsl:page()/html/body/svg:svg" as="element()"/>
<xsl:variable name="g" select="$svg/svg:g/svg:g/svg:g" as="element()+"/>

<xsl:template match="/">
<xsl:message select="boolean($g/svg:g[@id='&lt;Raumtrennung&gt;_2'])"/>
<xsl:message select="boolean($g/svg:use[@xlink:href='#Ohne_Bezeichnung_1'])"/>
<xsl:result-document href="#title" method="ixsl:replace-content">
<xsl:value-of select="$svg/title"/>

I'll now check out the second part - writing the use element with an xlink:href attribute...

#4 Updated by Philip Fearon over 8 years ago

Testing (in beta 0.2 pre-release) your modified XSLT that replaces clip-path content with the use element is added fine. This case is similar to an SVG test-case I had created.

Note that SVG elements referenced in this way, with xlink:href, are technically outside the DOM, so user-events for these require special handling by Saxon-CE (see issue #1456). From the XSLT developer's perspective the behaviour is the same as if the referenced elements were within the DOM, so you can use ixsl:event handdling templates in the usual way.

#5 Updated by Philip Fearon over 8 years ago

  • Assignee set to Philip Fearon
  • Priority changed from Low to Normal
  • Sprint/Milestone set to Beta 0.2
  • Found in version set to Beta 0.1
  • Fixed in version set to Beta 0.2

I'm marking this issue as a consequence of a wider Beta 0.1 namespace issue that's now resolved for Beta 0.2

#6 Updated by Manfred Staudinger over 8 years ago

This is very good news! These are the last pieces I would need to implement dynamic clipping (I've checked it statically). Thank you!

#7 Updated by Philip Fearon over 8 years ago

  • Status changed from New to Resolved

#8 Updated by Manfred Staudinger over 8 years ago

When I try this with Beta 0.2 it seems not to start the transformation. I've appended the console log.

#9 Updated by Philip Fearon over 8 years ago

Thanks for sending in this log.

Firstly, the 'Failed Attribute' warnings that appear are not Saxon-CE issues they're just a browser complaint because we're using a script element in an unrecognised way - that the browser doesn't need to care about.

Here's the key part of the log:

SaxonCE.XSLT20Processor 00:19:32.375 FINE: Aynchronous GET for: file:/E:/saxon-ce/Plaene/test3/svg-t5-011.svg

SaxonCE.XSLT20Processor 00:19:34.272 FINE: Compiling Stylesheet...

SaxonCE.XSLT20Processor 00:19:36.939 FINE: Stylesheet compiled OK

The log appears to finish at this point, but Saxon-CE is still waiting on a response from the asynchronous get for svg-t5-011.svg - the next line should be a 'Response Received' line and then a 'Starting transform...' line.

No response was logged for the asynchronous get, and I don't know quite why - if there was an HTTP error, then this should appear in Saxon-CE's log, but the browser console should report the HTTP error independently also.

I will try this out also as soon as I can, but here are a few things to check:

  1. Are you still using Opera?

  2. Have you explicitly cleared your browser's cache? - Opera tends to hang on to files a bit longer than other browsers

  3. Is the reported URI for the svg file good?

  4. Have you tried this in another browser - did it fail there also?

  5. As reported earlier in this thread, there were breaking changes in beta 0.2 regarding namespaces, which would definitely require changes to your XSLT - have you updated your XSLT/XPaths for the XHTML and SVG namespaces? (I ask this last, because this won't yet be the main issue - even with namespace issues - we should still see 'Response Received' and 'Transform Started' log entries.)

#10 Updated by Philip Fearon over 8 years ago

I missed this earlier:

The URI for the SVG is a file-system URI: file:/E:/saxon-ce/Plaene/test3/svg-t5-011.svg

You are probably going to get strange behaviour with browsers on the file-system (instead of using HTTP) because of security issues, but also because I'm not sure (i.e. it's un-tested) how well XMLHTTPRequest behaves asynchronously in this scenario.

One further point, the timings in the log seem incredibly slow, you have intervals measured in seconds when they should be (at least, from my tests) in milliseconds, e.g. there's nearly a 2 second interval between the GET and the start of the compile. Is this a hardware issue, or were other tasks running in the 'background'?

#11 Updated by Manfred Staudinger over 8 years ago

First the good news: the test works fine on http! To your questions:

1., 4. The console log is from Opera 11.62 and Firfox 11.0

  1. Browser cache is cleared.

  2. The svg file is good.

  3. I simply copied the xsl you modified.

I don't think it's a security issue, as I have

Firefox, about:config security.fileuri.strict_origin_policy;false

Opera, opera:config#UserPrefs Allow File XMLHttpRequest

About the timings, it's only Firefox that slow, Opera is just fine.

#12 Updated by Philip Fearon over 8 years ago

Now we know this isn't a security issue, the most likely cause is that XMLHTTPRequest doesn't work properly with the 'file' protocol in asynchronous mode. I will try adding a patch that checks the URI for the protocol and switches to synchronous mode for this case.

#13 Updated by Philip Fearon over 8 years ago

I've opened a new issue for this, see #1507.

#14 Updated by O'Neil Delpratt almost 8 years ago

  • Status changed from Resolved to Closed
  • Fixed in version changed from Beta 0.2 to 1.0

Fixed in Saxon-CE version 1.0

#15 Updated by O'Neil Delpratt almost 8 years ago

  • Sprint/Milestone changed from Beta 0.2 to Release 1.0
  • % Done changed from 0 to 100

Please register to edit this issue

Also available in: Atom PDF