Attribute in xlink namespace not recognized (Firefox)
The following expression
#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="http://www.w3.org/2000/svg"> <use xlink:href="#_1474"/> </xsl:result-document>
#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" xmlns:svg="http://www.w3.org/2000/svg" xmlns:ixsl="http://saxonica.com/ns/interactiveXSLT" xmlns:prop="http://saxonica.com/ns/html-property" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xlink="http://www.w3.org/1999/xlink" extension-element-prefixes="ixsl" xmlns="http://www.w3.org/1999/xhtml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xpath-default-namespace="http://www.w3.org/1999/xhtml" > <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='<Raumtrennung>_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"/> </xsl:result-document> </xsl:template> </xsl:transform>
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
#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:
Are you still using Opera?
Have you explicitly cleared your browser's cache? - Opera tends to hang on to files a bit longer than other browsers
Is the reported URI for the svg file good?
Have you tried this in another browser - did it fail there also?
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
Browser cache is cleared.
The svg file is good.
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.
Please register to edit this issue